Négy hónapos fejlesztés után bemutatták az OpenSSH 8.7 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.
Nagy változások:
- A hagyományos SCP/RCP protokoll helyett az SFTP protokollt használó kísérleti adatátviteli mód került az scp-be. Az SFTP kiszámíthatóbb névkezelési módszereket használ, és nem használja a glob-minták shell-feldolgozását a másik gazdagép oldalán, ami biztonsági problémákat okoz. Az SFTP engedélyezéséhez az scp-ben a „-s” jelzőt javasolták, de a jövőben a tervek szerint alapértelmezés szerint erre a protokollra kell váltani.
- Az sftp-server kiterjeszti az SFTP protokollt a ~/ és ~user/ útvonalak kiterjesztésére, ami az scp-hez szükséges.
- Az scp segédprogram megváltoztatta a fájlok két távoli gazdagép közötti másolásának viselkedését (például „scp host-a:/path host-b:”), ami most alapértelmezés szerint egy köztes helyi gazdagépen keresztül történik, mint amikor a „ -3” zászló. Ez a megközelítés lehetővé teszi, hogy elkerülje a szükségtelen hitelesítő adatok átadását az első gazdagépnek és a fájlnevek hármas értelmezését a shellben (a forrás, a cél és a helyi rendszer oldalon), valamint az SFTP használatakor lehetővé teszi az összes hitelesítési módszer használatát távoli hozzáféréskor. gazdagépek, és nem csak a nem interaktív módszerek . A "-R" opció hozzáadva a régi viselkedés visszaállításához.
- Hozzáadtuk a ForkAfterAuthentication beállítást az ssh-hez a "-f" jelzőnek megfelelően.
- StdinNull beállítás hozzáadva az ssh-hez, ami megfelel az "-n" jelzőnek.
- Az ssh-hoz egy SessionType beállítás került, amelyen keresztül a „-N” (nincs munkamenet) és az „-s” (alrendszer) jelzőknek megfelelő módokat állíthatunk be.
- Az ssh-keygen lehetővé teszi egy kulcs érvényességi intervallumának megadását a kulcsfájlokban.
- "-Oprint-pubkey" jelző hozzáadva az ssh-keygenhez, hogy a teljes nyilvános kulcsot az sshsig aláírás részeként kinyomtassa.
- Az ssh-ban és az sshd-ben mind a kliens, mind a kiszolgáló egy szigorúbb konfigurációs fájlelemző használatára került, amely shell-szerű szabályokat használ az idézőjelek, szóközök és escape karakterek kezelésére. Az új elemző nem hagyja figyelmen kívül a korábban megfogalmazott feltételezéseket sem, mint például az argumentumok elhagyása az opciókból (például a DenyUsers direktíva már nem maradhat üresen), a be nem zárt idézőjelek és több = karakter megadása.
- Ha SSHFP DNS-rekordokat használ a kulcsok ellenőrzésekor, az ssh mostantól az összes egyező rekordot ellenőrzi, nem csak azokat, amelyek egy adott típusú digitális aláírást tartalmaznak.
- Az ssh-keygenben, amikor FIDO-kulcsot generál az -Ochallenge opcióval, a beépített réteget használja a kivonatoláshoz, nem pedig a libfido2-t, amely lehetővé teszi a 32 bájtnál nagyobb vagy kisebb kihívássorozatok használatát.
- Az sshd-ben a Environment="..." direktívák feldolgozása során az authorised_keys fájlokban az első egyezést a rendszer most elfogadja, és a környezeti változónév korlátja 1024.
Az OpenSSH fejlesztői az SHA-1 hasheket használó algoritmusok dekompozíciójára is figyelmeztettek az ütközési támadások fokozott hatékonysága miatt egy adott előtaggal (az ütközés kiválasztásának költségét körülbelül 50 ezer dollárra becsülik). A következő kiadásban azt tervezzük, hogy alapértelmezés szerint letiltjuk az „ssh-rsa” nyilvános kulcsú digitális aláírási algoritmus használatának lehetőségét, amelyet az eredeti RFC-ben említettek az SSH-protokollhoz, és a gyakorlatban továbbra is széles körben használják.
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 gördülékenyebbé tétele érdekében az OpenSSH-ban korábban alapértelmezés szerint engedélyezve volt az UpdateHostKeys beállítás, 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).
Forrás: opennet.ru