IBM kupuje společnost HashiCorp (Terraform, Packer, Vault, Boundary, Consul, Nomad, Waypoint, Vagrant, …) za 6,4 miliardy dolarů, tj. 35 dolarů za akcii.
Byl vydán TrueNAS SCALE 24.04 “Dragonfish”. Přehled novinek této open source storage platformy postavené na Debianu v poznámkách k vydání.
Oznámeny byly nové Raspberry Pi Compute Module 4S. Vedle původní 1 GB varianty jsou nově k dispozici také varianty s 2 GB, 4 GB a 8 GB paměti. Compute Modules 4S mají na rozdíl od Compute Module 4 tvar a velikost Compute Module 3+ a předchozích. Lze tak provést snadný upgrade.
Po roce vývoje od vydání verze 1.24.0 byla vydána nová stabilní verze 1.26.0 webového serveru a reverzní proxy nginx (Wikipedie). Nová verze přináší řadu novinek. Podrobný přehled v souboru CHANGES-1.26.
Byla vydána nová verze 6.2 živé linuxové distribuce Tails (The Amnesic Incognito Live System), jež klade důraz na ochranu soukromí uživatelů a anonymitu. Přehled změn v příslušném seznamu. Tor Browser byl povýšen na verzi 13.0.14.
Byla vydána nová verze 30.0.0 frameworku pro vývoj multiplatformních desktopových aplikací pomocí JavaScriptu, HTML a CSS Electron (Wikipedie, GitHub). Chromium bylo aktualizováno na verzi 124.0.6367.49, V8 na verzi 12.4 a Node.js na verzi 20.11.1. Electron byl původně vyvíjen pro editor Atom pod názvem Atom Shell. Dnes je na Electronu postavena celá řada dalších aplikací.
Byla vydána nová verze 9.0.0 otevřeného emulátoru procesorů a virtualizačního nástroje QEMU (Wikipedie). Přispělo 220 vývojářů. Provedeno bylo více než 2 700 commitů. Přehled úprav a nových vlastností v seznamu změn.
Evropský parlament dnes přijal směrnici týkající se tzv. práva spotřebitele na opravu. Poslanci ji podpořili 584 hlasy (3 bylo proti a 14 se zdrželo hlasování). Směrnice ujasňuje povinnosti výrobců opravovat zboží a motivovat spotřebitele k tomu, aby si výrobky nechávali opravit a prodloužili tak jejich životnost.
Bylo oznámeno (cs) vydání Fedora Linuxu 40. Přehled novinek ve Fedora Workstation 40 a Fedora KDE 40 na stránkách Fedora Magazinu. Současně byl oznámen notebook Slimbook Fedora 2.
ČTK (Česká tisková kancelář) upozorňuje (X), že na jejím zpravodajském webu České noviny byly dnes dopoledne neznámým útočníkem umístěny dva smyšlené texty, které nepocházejí z její produkce. Jde o text s titulkem „BIS zabránila pokusu o atentát na nově zvoleného slovenského prezidenta Petra Pelligriniho“ a o údajné mimořádné prohlášení ministra Lipavského k témuž. Tyto dezinformace byly útočníky zveřejněny i s příslušnými notifikacemi v mobilní aplikaci Českých novin. ČTK ve svém zpravodajském servisu žádnou informaci v tomto znění nevydala.
# Package generated configuration file
# See the sshd(8) manpage for details
# What ports, IPs and protocols we listen for
Port 22
# Use these options to restrict which interfaces/protocols sshd will bind to
#ListenAddress ::
#ListenAddress 0.0.0.0
Protocol 2
# HostKeys for protocol version 2
HostKey /etc/ssh/ssh_host_rsa_key
HostKey /etc/ssh/ssh_host_dsa_key
#Privilege Separation is turned on for security
UsePrivilegeSeparation yes
# Lifetime and size of ephemeral version 1 server key
KeyRegenerationInterval 3600
ServerKeyBits 768
# Logging
SyslogFacility AUTH
LogLevel INFO
# Authentication:
LoginGraceTime 120
PermitRootLogin yes
StrictModes yes
RSAAuthentication yes
PubkeyAuthentication yes
#AuthorizedKeysFile %h/.ssh/authorized_keys
# Don't read the user's ~/.rhosts and ~/.shosts files
IgnoreRhosts yes
# For this to work you will also need host keys in /etc/ssh_known_hosts
RhostsRSAAuthentication no
# similar for protocol version 2
HostbasedAuthentication no
# Uncomment if you don't trust ~/.ssh/known_hosts for RhostsRSAAuthentication
#IgnoreUserKnownHosts yes
# To enable empty passwords, change to yes (NOT RECOMMENDED)
PermitEmptyPasswords no
# Change to yes to enable challenge-response passwords (beware issues with
# some PAM modules and threads)
ChallengeResponseAuthentication no
# Change to no to disable tunnelled clear text passwords
#PasswordAuthentication yes
# Kerberos options
#KerberosAuthentication no
#KerberosGetAFSToken no
#KerberosOrLocalPasswd yes
#KerberosTicketCleanup yes
# GSSAPI options
#GSSAPIAuthentication no
#GSSAPICleanupCredentials yes
X11Forwarding yes
X11DisplayOffset 10
PrintMotd no
PrintLastLog yes
TCPKeepAlive yes
#UseLogin no
#MaxStartups 10:30:60
#Banner /etc/issue.net
# Allow client to pass locale environment variables
AcceptEnv LANG LC_*
Subsystem sftp /usr/lib/openssh/sftp-server
UsePAM yes
Vesměs asi skorem defaultní konfig, který se instaluje společně s balíčkem.
Další kroky, které dělám jsou následující:
-- spustím puttygen -- kliknu na Generate a jezdím v prázdném poli myší pro vygenerování klíče -- poté přejmenuji komentář klíče na git@********.cz -- poté kliknu na save public key, uložím jako git-public.key, a pak na save private key, uložím jako git-private.ppk -- určitě jste si všimli, že jsem nezadal heslo pro privátní klíč, předpokládám, že to není nutností, ani když jsem ho vyplnil, tak se změna nedostavila -- teď překopíruji text (klíč) který se zobrazil v puttygenu a vložím ho na serveru, do složky /home/git/.ssh do souboru authorized_keys (uživatele jsem vytvořil, bez hesla) a uložím. -- nyní spustím znovu Putty, vyplním adresu a přiložím klíč git-private.ppkA výsledek ?
login as: git
Server refused our key
git@********-server.pilsfree.czf's password:
Vygenerovaný klíč, který vkládám do authorized_keys vypadá zhruba takto:
ssh-rsa AAAAB3NzaC1yc2EAAAABIwAAAQEAlFcudIV3/Wgkefzo/n/xy9zsD/AVb1zXXocG5W32wW5qZdzxo/8sHd14467yx....blablablabla...BYW3ay1+xJKF5mqtVqqNmdnkEUQViH/KCdxB6WZjvsezq8XqxdZ2ms+G2h9ThvlsWtfSXYNVuBXtHGIR/EHYFPYLqh6tWrO46DJF5q2jOGyYtP0bAVg4v51lcCJW6oZruW9XiU+vtCIB5TLesnvhhIWOhwK9XSmTWSleBNgOfKr+tZvE9r0oTfFQIVKnLmTIsz6AtiFcn7VQBm56KOVIg5CxwKAKZzYGJ1Ezhi+Yl1rgsVzdv7NhmENWY7JraOZ8J1v8AQ== git@********.czNemáte někdo ponětí, co dělám zase špatně ? Bohužel se mi nepodařilo ani nic vyčmuchat v logu, co by mi pomohlo. Případně pokud potřebujete ještě soubor /etc/ssh/ssh_config, tak jej mohu dodatečně přiložit, ale myslím si, že v tom nehraje roli. Díky.
Řešení dotazu:
$ chmod 700 /home/git -R
a už je vše v pořádku. Můžete to tedy brát jako takový nový návod :D
/home/git - drwxr-xr-x /home/git/.ssh - drwxr-xr-x /home/git/.ssh/authorized_keys - -rw-r--r--
$ chmod 700 /home/git -R
Tohle bych jako bernou minci nebral, protože to nastaví 700 i na všech souborech v tom adresáři. Úplně stačí to použít bez toho -R.
Jinak je pravda že pokud sshd odmítá klíč a všechno se zdá býti v pořádku tak jsou za tím téměř vždy nesprávná práva na domovský adresář.
Jinak je pravda že pokud sshd odmítá klíč a všechno se zdá býti v pořádku tak jsou za tím téměř vždy nesprávná práva na domovský adresář.Ne na celý adresář, ale jen na soubor ~/.ssh/authorized_keys Jde o to, že kdyby tento soubor byl zapisovatelný pro skupinu, nebo dokonce pro svět, mohl by si tam kdokoli přidat klíč a následně se přihlásit jménem uživatele.
Ne na celý adresář, ale jen na soubor ~/.ssh/authorized_keys
Bohužel ve světe UNIXu tohle nestačí. Pokud nemáte právo zápisu k .ssh/authorized_keys
ale máte právo zápisu na adresáři .ssh
, můžete provést:
rm .ssh/authorized_keys cat mujkey >.ssh/authorized_keysPokud nemáte možnost zápisu do adresáře
.ssh
(ergo ke smazání toho souboru), ale máte zápis do /home/user
můžete provést zase jiný trik:
mv /home/user/.ssh /home/user/.ssh-nasrat mkdir /home/user/.ssh cat mujkey >.ssh/authorized_keysJo, UNIX je radost... Proto sshd kontroluje práva všech adresářů od toho souboru až nahoru a nejlepší, co můžete udělat je nechat si svůj home privátní.
chmod 700 $HOME
by vedly k vytvoření souboru/adresáře s jiným jménem vlastníka (za předpokladu, že na adresářích není SUID/SGID), takže to by sshd mělo stačit zkontrolovat, zda authorized_keys má odpovídající práva a zda je vlastněn majitelem účtu. Ale skutečně nestačí.rm .ssh/authorized_keys cat mujkey >.ssh/authorized_keys ... mv /home/user/.ssh /home/user/.ssh-nasrat mkdir /home/user/.ssh cat mujkey >.ssh/authorized_keys
Proto sshd kontroluje práva všech adresářů od toho souboru až nahoru a nejlepší, co můžete udělat je nechat si svůj home privátní.Až nahoru ne, práva na adresář /home mohou být libovolná (aspoň u mě).
by vedly k vytvoření souboru/adresáře s jiným jménem vlastníka (za předpokladu, že na adresářích není SUID/SGID), takže to by sshd mělo stačit zkontrolovat, zda authorized_keys má odpovídající práva a zda je vlastněn majitelem účtu.
Až nahoru ne, práva na adresář /home mohou být libovolná (aspoň u mě).Teoreticky máte pravdu, proč je to v opensshd zrovna takto je asi otázka do mail listu
Tiskni Sdílej: