Binarly REsearch před týdnem informoval o kritických zranitelnostech UEFI souhrnně pojmenovaných LogoFAIL. Tento týden doplnil podrobnosti. Útočník může nahradit logo zobrazováno při bootování vlastním speciálně upraveným obrázkem, jehož "zobrazení" při bootování spustí připravený kód. Pětiminutové povídání o LogoFAIL a ukázka útoku na YouTube.
Byla vydána listopadová aktualizace aneb nová verze 1.85 editoru zdrojových kódů Visual Studio Code (Wikipedie). Přehled novinek i s náhledy a animovanými gify v poznámkách k vydání. Ve verzi 1.85 vyjde také VSCodium, tj. komunitní sestavení Visual Studia Code bez telemetrie a licenčních podmínek Microsoftu.
git.kernel.org je nově oficiálně také v tmavém vzhledu.
Richard Hughes na svém blogu oznámil, že počet aktualizací firmwarů pomocí služby LVFS (Linux Vendor Firmware Service) přesáhl 100 milionů. Přehled podporovaných zařízení, nejnovějších firmwarů nebo zapojených výrobců na stránkách LVFS.
Byla vydána nová stabilní verze 3.19.0, tj. první z nové řady 3.19, minimalistické linuxové distribuce zaměřené na bezpečnost Alpine Linux (Wikipedie) postavené na standardní knihovně jazyka C musl libc a BusyBoxu. Z novinek lze vypíchnou podporu Raspberry Pi 5.
Altap Salamander (Wikipedie), dvoupanelový správce souborů pro Windows, byl uvolněn jako open source pod názvem Open Salamander. Zdrojové kódy jsou k dispozici na GitHubu pod licencí GPLv2.
Společnost JetBrains představila (YouTube) svou umělou inteligenci JetBrains AI a nástroj AI Assistant v IDE.
Byla vydána nová verze 255 správce systému a služeb systemd (GitHub, NEWS). Z novinek lze vypíchnout například novou službu systemd-bsod.service.
Google představil Gemini, svůj největší a nejschopnější model umělé inteligence.
openSUSE komunita vybírá nová loga. Jedním z cílů je odlišit se od SUSE. Aktuálně probíhá hlasování o logu openSUSE a čtyř distribucí Tumbleweed, Leap, Slowroll a Kalpa.
# 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: