Po pěti měsících vývoje je představeno vydání OpenSSH 8.5, otevřené implementace klienta a serveru pro práci nad protokoly SSH 2.0 a SFTP.
Vývojáři OpenSSH připomněli chystané vyřazení algoritmů využívajících SHA-1 hashe z důvodu zvýšení efektivity kolizních útoků s daným prefixem (náklady na výběr kolize se odhadují na přibližně 50 tisíc dolarů). V jedné z nadcházejících verzí plánují ve výchozím nastavení zakázat možnost používat algoritmus digitálního podpisu veřejného klíče „ssh-rsa“, který je zmíněn v původním RFC pro protokol SSH a v praxi zůstává rozšířený.
Chcete-li otestovat použití ssh-rsa na vašich systémech, můžete se zkusit připojit přes ssh s volbou „-oHostKeyAlgorithms=-ssh-rsa“. Zakázání digitálních podpisů „ssh-rsa“ ve výchozím nastavení zároveň neznamená úplné opuštění používání klíčů RSA, protože protokol SSH kromě SHA-1 umožňuje použití dalších algoritmů výpočtu hash. Zejména kromě „ssh-rsa“ bude nadále možné používat balíčky „rsa-sha2-256“ (RSA/SHA256) a „rsa-sha2-512“ (RSA/SHA512).
Pro hladký přechod na nové algoritmy má OpenSSH 8.5 ve výchozím nastavení povoleno nastavení UpdateHostKeys, které klientům umožňuje automaticky přepínat na spolehlivější algoritmy. Pomocí tohoto nastavení je povoleno speciální rozšíření protokolu “[chráněno e-mailem]", což umožňuje serveru po ověření informovat klienta o všech dostupných klíčích hostitele. Klient může tyto klíče odrážet ve svém souboru ~/.ssh/known_hosts, který umožňuje aktualizaci klíčů hostitele a usnadňuje změnu klíčů na serveru.
Použití UpdateHostKeys je omezeno několika upozorněními, která mohou být v budoucnu odstraněna: klíč musí být odkazován v UserKnownHostsFile a nesmí být použit v GlobalKnownHostsFile; klíč musí být přítomen pouze pod jedním jménem; certifikát hostitelského klíče by neměl být používán; ve známých_hostitelích by se neměly používat masky podle názvu hostitele; musí být zakázáno nastavení VerifyHostKeyDNS; Parametr UserKnownHostsFile musí být aktivní.
Doporučené algoritmy pro migraci zahrnují rsa-sha2-256/512 založené na RFC8332 RSA SHA-2 (podporované od OpenSSH 7.2 a používané ve výchozím nastavení), ssh-ed25519 (podporované od OpenSSH 6.5) a ecdsa-sha2-nistp256/384/521 na RFC5656 ECDSA (podporováno od OpenSSH 5.7).
Další změny:
- Změny zabezpečení:
- Chyba zabezpečení způsobená opětovným uvolněním již uvolněné oblasti paměti (double-free) byla opravena v ssh-agent. Problém se vyskytuje od vydání OpenSSH 8.2 a může být potenciálně zneužit, pokud má útočník přístup k soketu ssh-agent na místním systému. Využívání je obtížnější, protože k soketu má přístup pouze root a původní uživatel. Nejpravděpodobnějším scénářem útoku je, že agent je přesměrován na účet, který je řízen útočníkem, nebo na hostitele, kde má útočník přístup root.
- sshd přidal ochranu proti předání velmi velkých parametrů s uživatelským jménem do subsystému PAM, což umožňuje blokovat zranitelnosti v modulech systému PAM (Pluggable Authentication Module). Tato změna například brání použití sshd jako vektoru pro zneužití nedávno objevené kořenové zranitelnosti v Solaris (CVE-2020-14871).
- Potenciálně narušené změny kompatibility:
- В ssh и sshd переработан экспериментальный метод обмена ключами, стойкий к подбору на квантовом компьютере. Квантовые компьютеры кардинально быстрее решают задачу разложения натурального числа на простые множители, которая лежит в основе современных асимметричных алгоритмов шифрования и эффективно не решаема на классических процессорах. Используемый метод основан на алгоритме NTRU Prime, разработанном для постквантумных криптосистем, и методе обмена ключами на базе эллиптических кривых X25519. Вместо [chráněno e-mailem] метод теперь идентифицируется как [chráněno e-mailem] (algoritmus sntrup4591761 byl nahrazen algoritmem sntrup761).
- V ssh a sshd bylo změněno pořadí, ve kterém jsou oznamovány podporované algoritmy digitálního podpisu. ED25519 je nyní nabízen jako první místo ECDSA.
- V ssh a sshd se nyní nastavení parametrů kvality služeb TOS/DSCP pro interaktivní relace provádí před navázáním TCP spojení.
- Podpora šifrování byla ukončena v ssh a sshd [chráněno e-mailem], který je identický s aes256-cbc a byl používán před schválením RFC-4253.
- Ve výchozím nastavení je zakázán parametr CheckHostIP, jehož přínos je zanedbatelný, ale jeho použití výrazně komplikuje rotaci klíčů pro hostitele za load balancery.
- Do sshd byla přidána nastavení PerSourceMaxStartups a PerSourceNetBlockSize, která omezují intenzitu spouštění obslužných programů na základě adresy klienta. Tyto parametry umožňují ve srovnání s obecným nastavením MaxStartups přesněji řídit limit spouštění procesů.
- Do ssh a sshd bylo přidáno nové nastavení LogVerbose, které vám umožňuje násilně zvýšit úroveň ladicích informací uložených do protokolu s možností filtrování podle šablon, funkcí a souborů.
- V ssh se při přijetí nového hostitelského klíče zobrazí všechny názvy hostitelů a IP adresy spojené s klíčem.
- ssh umožňuje volbu UserKnownHostsFile=none zakázat použití souboruknown_hosts při identifikaci klíčů hostitele.
- Do ssh_config pro ssh bylo přidáno nastavení KnownHostsCommand, které vám umožňuje získat dataknown_hosts z výstupu zadaného příkazu.
- Do ssh_config pro ssh byla přidána možnost PermitRemoteOpen, která vám umožní omezit cíl při použití možnosti RemoteForward s SOCKS.
- V ssh pro klíče FIDO je poskytován opakovaný požadavek na PIN v případě selhání operace digitálního podpisu kvůli nesprávnému PIN a uživatel není vyzván k zadání PIN (například když nebylo možné získat správné biometrické údaje a zařízení se vrátilo k ručnímu zadávání PIN).
- sshd přidává podporu pro další systémová volání do mechanismu izolace procesů založeného na seccomp-bpf v Linuxu.
- Obslužný program contrib/ssh-copy-id byl aktualizován.
Zdroj: opennet.ru