Öt hónapos fejlesztés után bemutatják az OpenSSH 8.5 kiadását, amely az SSH 2.0 és SFTP protokollok feletti munkavégzéshez egy kliens és szerver nyílt megvalósítása.
Az OpenSSH fejlesztői emlékeztettek az SHA-1 hasheket használó algoritmusok közelgő leállítására, ami az ütközési támadások hatékonyságának növekedését magyarázza egy adott előtaggal (az ütközés kiválasztásának költsége körülbelül 50 ezer dollárra becsülhető). Az egyik közelgő kiadásban azt tervezik, hogy alapértelmezés szerint letiltják az „ssh-rsa” nyilvános kulcsú digitális aláírási algoritmus használatát, amely az eredeti RFC-ben szerepel az SSH-protokollhoz, és a gyakorlatban továbbra is elterjedt.
Az ssh-rsa használatának teszteléséhez próbáljon meg ssh-n keresztül csatlakozni a „-oHostKeyAlgorithms=-ssh-rsa” opcióval. Ugyanakkor az „ssh-rsa” digitális aláírások alapértelmezés szerinti letiltása nem jelenti az RSA kulcsok használatának teljes elhagyását, mivel az SSH-protokoll az SHA-1 mellett más hash-számítási algoritmusok használatát is lehetővé teszi. Az „ssh-rsa” mellett továbbra is lehetséges marad az „rsa-sha2-256” (RSA/SHA256) és az „rsa-sha2-512” (RSA/SHA512) csomagok használata.
Az új algoritmusokra való átállás zökkenőmentessége érdekében az OpenSSH 8.5 alapértelmezés szerint engedélyezve van az UpdateHostKeys beállítással, amely lehetővé teszi az ügyfelek számára, hogy automatikusan megbízhatóbb algoritmusokra váltsanak. Ezzel a beállítással engedélyezve van egy speciális protokollbővítmény "[e-mail védett]", amely lehetővé teszi a szerver számára, hogy a hitelesítés után tájékoztassa az ügyfelet az összes elérhető gazdagépkulcsról. A kliens ezeket a kulcsokat megjelenítheti a ~/.ssh/known_hosts fájljában, amely lehetővé teszi a gazdagép kulcsainak frissítését, és megkönnyíti a kulcsok megváltoztatását a kiszolgálón.
Az UpdateHostKeys használatát számos figyelmeztetés korlátozza, amelyek a jövőben eltávolíthatók: a kulcsra hivatkozni kell a UserKnownHostsFile fájlban, és nem szabad használni a GlobalKnownHostsFile fájlban; a kulcsnak csak egy név alatt kell lennie; gazdakulcs tanúsítványt nem szabad használni; az ismert_gazdagépekben a gazdagépnév szerinti maszkokat nem szabad használni; a VerifyHostKeyDNS beállítást le kell tiltani; A UserKnownHostsFile paraméternek aktívnak kell lennie.
A migrációhoz javasolt algoritmusok közé tartozik az RFC2 RSA SHA-256 alapú rsa-sha512-8332/2 (az OpenSSH 7.2 óta támogatott és alapértelmezés szerint használatos), az ssh-ed25519 (az OpenSSH 6.5 óta támogatott) és az ecdsa-sha2-nistp256/384 alapú 521/5656/5.7. RFCXNUMX ECDSA-n (az OpenSSH XNUMX óta támogatott).
Egyéb változások:
- Biztonsági változások:
- Az ssh-agentben kijavították a már felszabadult (kettős mentes) memóriaterület újbóli felszabadítása által okozott sebezhetőséget. A probléma az OpenSSH 8.2 kiadása óta fennáll, és potenciálisan kihasználható, ha egy támadó hozzáfér az ssh-agent sockethez a helyi rendszeren. A kiaknázást megnehezíti, hogy csak a root és az eredeti felhasználó férhet hozzá a sockethez. A legvalószínűbb támadási forgatókönyv az, hogy az ügynököt a támadó által felügyelt fiókhoz vagy egy olyan gazdagéphez irányítják át, ahol a támadó root hozzáféréssel rendelkezik.
- Az sshd védelmet nyújtott az ellen, hogy nagyon nagy paramétereket adjon át a felhasználónévvel a PAM alrendszernek, ami lehetővé teszi a PAM (Pluggable Authentication Module) rendszermodulok sebezhetőségeinek blokkolását. A változtatás például megakadályozza, hogy az sshd-t vektorként használják a Solaris nemrég felfedezett gyökérsebezhetőségének (CVE-2020-14871) kihasználására.
- Lehetséges kompatibilitási változások:
- Az ssh-ban és az sshd-ben egy kísérleti kulcscsere-módszert alakítottak át, amely ellenáll a kvantumszámítógépen történő találgatásoknak. A kvantumszámítógépek radikálisan gyorsabban oldják meg a természetes számok prímtényezőkre bontásának problémáját, amely a modern aszimmetrikus titkosítási algoritmusok hátterében áll, és nem oldható meg hatékonyan a klasszikus processzorokon. Az alkalmazott módszer a posztkvantum kriptorendszerekhez kifejlesztett NTRU Prime algoritmuson és az X25519 elliptikus görbe kulcscsere módszerén alapul. Ahelyett [e-mail védett] a módszert most a következőképpen azonosítják [e-mail védett] (az sntrup4591761 algoritmust az sntrup761 váltotta fel).
- Az ssh és az sshd esetében megváltozott a támogatott digitális aláírási algoritmusok bejelentési sorrendje. Az ECDSA helyett most először az ED25519-et kínálják.
- Az ssh-ben és az sshd-ben a TOS/DSCP szolgáltatásminőség-paraméterek beállítása az interaktív szekciókhoz most már a TCP-kapcsolat létrehozása előtt megtörténik.
- A titkosítás támogatása megszűnt az ssh-ban és az sshd-ben [e-mail védett], amely megegyezik az aes256-cbc-vel, és az RFC-4253 jóváhagyása előtt használták.
- Alapértelmezés szerint a CheckHostIP paraméter le van tiltva, aminek az előnye elhanyagolható, de használata jelentősen megnehezíti a kulcsrotációt a terheléselosztók mögötti gazdagépeknél.
- A PerSourceMaxStartups és a PerSourceNetBlockSize beállításokat hozzáadták az sshd-hez, hogy korlátozzák a kezelők indításának intenzitását az ügyfél címe alapján. Ezek a paraméterek lehetővé teszik a folyamatindítások korlátjának pontosabb szabályozását az általános MaxStartups beállításhoz képest.
- Új LogVerbose-beállítás került az ssh-ba és az sshd-be, amely lehetővé teszi a naplóba beírt hibakeresési információk erőteljes emelését, és lehetővé teszi a sablonok, funkciók és fájlok szerinti szűrést.
- Az ssh-ban új gazdakulcs elfogadásakor megjelenik a kulcshoz tartozó összes gazdagépnév és IP-cím.
- Az ssh lehetővé teszi, hogy a UserKnownHostsFile=none beállítás letiltja az ismert_hosts fájl használatát a gazdagép kulcsok azonosításakor.
- A KnownHostsCommand beállítás hozzáadásra került az ssh_config for ssh-hez, amely lehetővé teszi az ismert_hosts adatok lekérését a megadott parancs kimenetéből.
- Hozzáadott egy PermitRemoteOpen beállítást az ssh_config for ssh fájlhoz, amely lehetővé teszi a cél korlátozását, amikor a RemoteForward opciót SOCKS-szal használja.
- A FIDO-kulcsokhoz tartozó ssh-ben ismételt PIN-kérés történik, ha a digitális aláírás művelete hibás PIN-kód miatt meghiúsul, és a felhasználó nem kéri meg a PIN-kódot (például ha nem sikerült beszerezni a megfelelő biometrikus adatokat, és a az eszköz visszaesett a kézi PIN-bevitelre).
- Az sshd támogatja a további rendszerhívásokat a seccomp-bpf alapú folyamatleválasztó mechanizmushoz Linuxon.
- A contrib/ssh-copy-id segédprogram frissítve lett.
Forrás: opennet.ru