OpenSSH 8.5 kiadása

Öt hónap fejlesztés után megjelent az OpenSSH 8.5, a SSH 2.0 és SFTP protokollal működő kliens és szerver nyílt forráskódú implementációja.

Az OpenSSH fejlesztői emlékeztettek a közelgő átállásra az elavult algoritmusok kategóriájába, amelyek SHA-1 hash-eket használnak az egyre hatékonyabb ütközési támadások miatt (az ütközés keresésének költsége körülbelül 50 ezer dollárra tehető). A következő kiadásokban terveik szerint alapértelmezettként letiltják az "ssh-rsa" nyílt kulcsú digitális aláírás algoritmus használatát, amely az SSH protokoll eredeti RFC-jében szerepel, és a gyakorlatban széles körben elterjedt.

A ssh-rsa alkalmazásának ellenőrzéséhez a rendszereiben megpróbálhat csatlakozni ssh-val a -oHostKeyAlgorithms=-ssh-rsa opció megadásával. Az „ssh-rsa” digitális aláírások alapértelmezett letiltása nem jelenti a RSA kulcsok teljes lemondását, mivel a SHA-1 mellett az SSH protokoll más hash-algoritmusok alkalmazását is lehetővé teszi. Különösen az „ssh-rsa” mellett továbbra is használható a „rsa-sha2-256” (RSA/SHA256) és a „rsa-sha2-512” (RSA/SHA512) páros.

Az új algoritmusok használatára való zökkenőmentes átállás érdekében az OpenSSH 8.5 alapértelmezés szerint aktiválja az UpdateHostKeys beállítást, amely lehetővé teszi a kliensek automatikus átirányítását megbízhatóbb algoritmusokra. Ezzel a beállítással aktiválódik a "hostkeys@openssh.com" protokoll speciális kiterjesztése, amely lehetővé teszi a szerver számára, hogy az azonosítás után tájékoztassa a klienst az összes elérhető hosztkulcsról. A kliens ezeket a kulcsokat a ~/.ssh/known_hosts fájljában tárolhatja, lehetővé téve a hosztkulcsok frissítését és megkönnyítve a kulcsok cseréjét. szerveren.

Az UpdateHostKeys használata néhány feltételhez kötött, amelyek a jövőben visszavonhatók: a kulcsnak szerepelnie kell a UserKnownHostsFile- ban, és nem használható a GlobalKnownHostsFile- ban; a kulcsnak csak egy név alatt kell szerepelnie; nem alkalmazható hoszt kulcs tanúsítvány; a known_hosts- ban nem alkalmazhatók névmaszkok; ki kell kapcsolni a VerifyHostKeyDNS beállítást; a UserKnownHostsFile paraméternek aktívnak kell lennie.

A migrációra ajánlott algoritmusok között szerepel az rsa-sha2-256/512 az RFC8332 RSA SHA-2 alapjain (melyet az OpenSSH 7.2-től támogatnak és alapértelmezettként használnak), a ssh-ed25519 (melyet az OpenSSH 6.5-től támogatnak), és az ecdsa-sha2-nistp256/384/521 az RFC5656 ECDSA alapjain (melyet az OpenSSH 5.7-től támogatnak).

Egyéb változások:

• Biztonsággal kapcsolatos változások:
  • Az ssh-agentben megszüntették azt a sebezhetőséget, amely a már felszabadított memória kétszeri felszabadításából adódott (double-free). A probléma az OpenSSH 8.2 kiadásával jelentkezett, és potenciálisan kihasználható, ha a támadó hozzáfér a lokális rendszeren található ssh-agent socketjéhez. A kihasználást nehezíti, hogy a sockethez csak root és a kezdeti felhasználó férhet hozzá. A legvalószínűbb támadási forgatókönyv az, hogy az ügynököt egy olyan fiókhoz irányítják, amely a támadó ellenőrzése alatt áll, vagy egy olyan hoszthoz, ahol a támadónak root hozzáférése van.
  • Az sshd-ben védelmet vezettek be a túl nagy felhasználónév paraméterek PAM alrendszerbe történő átadásával szemben, amely lehetővé teszi a PAM (Pluggable Authentication Module) rendszer moduljaiban található sebezhetőségek blokkolását. Például a módosítás megakadályozza az sshd felhasználását mint vektort a nemrég felfedezett root sebezhetőség kihasználására a Solarisban (CVE-2020-14871).
• Változások, amelyek potenciálisan megsérthetik a kompatibilitást:
  • Az ssh és sshd bevezetett egy kísérleti kulcscsere-módszert, amely ellenáll a kvantumszámítógépek próbálkozásainak. A kvantumszámítógépek lényegesen gyorsabban oldják meg a természetes számok prímfaktorra bontásának feladatát, amely a modern aszimmetrikus titkosítási algoritmusok alapját képezi, és klasszikus processzorokon hatékonyan megoldhatatlan. A használt módszer az NTRU Prime algoritmuson alapul, amelyet posztkvantum kriptográfiai rendszerekhez fejlesztettek ki, és az X25519 elliptikus görbék alapú kulcscsere-módszere. A sntrup4591761x25519-sha512@tinyssh.org helyett a módszer most sntrup761x25519-sha512@openssh.com néven azonosítható (a sntrup4591761 algoritmust sntrup761-re cserélték).
  • Az ssh és sshd módosította a támogatott digitális aláírási algoritmusok bejelentési sorrendjét. Mostantól az ED25519 kerül elsőként ajánlásra az ECDSA helyett.
  • Az ssh és sshd esetében a TOS/DSCP minőségbiztosítási paraméterek beállítása interaktív ülésekhez mostantól a TCP-kapcsolat létrehozása előtt történik.
  • Az ssh és sshd leállította a rijndael-cbc@lysator.liu.se titkosító, amely az aes256-cbc-nek felel meg, támogatását, amelyet a RFC-4253 jóváhagyása előtt használtak.
  • Alapértelmezetten le van tiltva a CheckHostIP paraméter, amelynek haszna csekély, de a használata jelentősen megnehezíti a terheléselosztók mögötti hosztok kulcsainak rotálását.
• Az sshd-be bevezetésre kerültek a PerSourceMaxStartups és PerSourceNetBlockSize beállítások a klaszterekhez való kapcsolódó kliens címének intenzitásának korlátozása érdekében. Ezek a paraméterek finomabb irányítást tesznek lehetővé a folyamatindítási korlátok felett a MaxStartups globális beállításhoz képest.
• Az ssh és sshd a LogVerbose új beállítást vezette be, amely lehetővé teszi a naplózott hibakeresési információk szintjének kényszerített emelését minták, funkciók és fájlok szerinti szűrési lehetőséggel.
• Az ssh-ban, amikor új hoszt kulcsot fogadunk el, bemutatásra kerülnek az összes hoszt nevei és IP-címek, amelyek a kulcshoz kapcsolódnak.
• Az ssh-ban lehetőség van a UserKnownHostsFile=none opció megadására a known_hosts fájl használatának letiltására a hoszt kulcsok azonosítása során.
• Az ssh_config-ben az ssh számára hozzáadott a KnownHostsCommand beállítás, amely lehetővé teszi a known_hosts adatok megszerzését a megadott parancs kimenetéből.
• Az ssh_config-ben az ssh számára hozzáadott a PermitRemoteOpen opció, amely lehetővé teszi a célpont korlátozását a RemoteForward opció SOCKS használatakor.
• Az ssh-ben a FIDO kulcsok esetében újra kérik a PIN-t, ha a digitális aláírás művelete meghiúsul a helytelen PIN miatt, és a felhasználónál nem kérik a PIN-t (például ha nem sikerült helyes biometrikus adatokat kapni, és az eszköz visszaállt a PIN kézi bevitelére).
• Az sshd-hez a seccomp-bpf alapú folyamatizolációs mechanizmushoz Linux platformon új rendszerhívások támogatása került hozzáadásra.
• Frissült a contrib/ssh-copy-id segédprogram.

Forrás: opennet.ru