Négy hónapos fejlesztés után kiadás , egy nyílt kliens és kiszolgáló megvalósítás az SSH 2.0 és SFTP protokollokon keresztül történő munkához.
Az OpenSSH 8.2 kiadásának kulcsfontosságú fejlesztése a kétfaktoros hitelesítés lehetősége volt a protokollt támogató eszközökön , amelyet a szövetség fejlesztett ki . Az U2F lehetővé teszi az olcsó hardveres tokenek létrehozását a felhasználó fizikai jelenlétének ellenőrzésére, interakcióba lépve velük USB-n, Bluetooth-on vagy NFC-n keresztül. Az ilyen eszközöket a webhelyeken a kétfaktoros hitelesítés eszközeként reklámozzák, a nagyobb böngészők már támogatják őket, és különféle gyártók, köztük a Yubico, a Feitian, a Thetis és a Kensington gyártják.
A felhasználó jelenlétét megerősítő eszközökkel való interakció érdekében az OpenSSH-hoz új kulcstípusok, „ecdsa-sk” és „ed25519-sk” kerültek, amelyek az ECDSA és az Ed25519 digitális aláírási algoritmusokat használják, kombinálva az SHA-256 hash-sel. A tokenekkel való interakciós eljárások egy köztes könyvtárban vannak elhelyezve, amely a PKCS#11 támogatási könyvtárhoz hasonló módon töltődik be, és egy burkoló a könyvtár tetején. , amely eszközöket biztosít a tokenekkel való USB-n keresztüli kommunikációhoz (a FIDO U2F/CTAP 1 és FIDO 2.0/CTAP 2 protokollok támogatottak). Köztes könyvtár libsk-libfido2, OpenSSH fejlesztők által készített a libfido2 magba, valamint OpenBSD-hez.
A hitelesítéshez és a kulcs generálásához meg kell adnia a „SecurityKeyProvider” paramétert a beállításokban, vagy be kell állítania az SSH_SK_PROVIDER környezeti változót, amely jelzi a külső könyvtár elérési útját libsk-libfido2.so (export SSH_SK_PROVIDER=/path/to/libsk-libfido2. így). Lehetőség van openssh létrehozására a rétegkönyvtár beépített támogatásával (--with-security-key-builtin), ebben az esetben be kell állítani a „SecurityKeyProvider=internal” paramétert.
Ezután futtassa az „ssh-keygen -t ecdsa-sk” parancsot, vagy ha a kulcsokat már létrehozta és beállította, csatlakozzon a szerverhez az „ssh” használatával. Az ssh-keygen futtatásakor a generált kulcspár a „~/.ssh/id_ecdsa_sk” mappába kerül mentésre, és más kulcsokhoz hasonlóan használható.
A nyilvános kulcsot (id_ecdsa_sk.pub) át kell másolni a kiszolgálóra az Author_keys fájlban. Szerver oldalon csak a digitális aláírás ellenőrzése történik meg, a kliens oldalon a tokenekkel való interakció (nem kell telepítenie a libsk-libfido2-t a szerverre, de a szervernek támogatnia kell az „ecdsa-sk” kulcstípust) . A generált privát kulcs (id_ecdsa_sk) lényegében egy kulcsleíró, amely csak az U2F token oldalán tárolt titkos szekvenciával együtt alkot valódi kulcsot. Ha az id_ecdsa_sk kulcs a támadó kezébe kerül, a hitelesítés átadásához hozzá kell férnie a hardveres tokenhez is, amely nélkül az id_ecdsa_sk fájlban tárolt privát kulcs használhatatlan.
Ezenkívül alapértelmezés szerint a kulcsokkal végzett műveletek végrehajtása során (mind a generálás, mind a hitelesítés során) a felhasználó fizikai jelenlétének helyi megerősítése szükséges, például javasolt a tokenen lévő érzékelő megérintése, ami megnehezíti a távoli támadásokat hajthat végre csatlakoztatott tokennel rendelkező rendszerek ellen. Egy másik védelmi vonalként az ssh-keygen indítási fázisában jelszó is megadható a kulcsfájl eléréséhez.
Az OpenSSH új verziója bejelentette az SHA-1 hasheket használó algoritmusok közelgő megszüntetését is az ütközési támadások hatékonysága adott előtaggal (az ütközés kiválasztásának költségét körülbelül 45 ezer dollárra becsülik). 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 széles körben elterjedt (a használat tesztelése érdekében ssh-rsa a rendszereiben, megpróbálhat csatlakozni az ssh-n keresztül a „-oHostKeyAlgorithms=-ssh-rsa” opcióval.
Az OpenSSH új algoritmusaira való átállás zökkenőmentessége érdekében egy jövőbeli kiadásban alapértelmezés szerint engedélyezve lesz az UpdateHostKeys beállítás, amely automatikusan áttelepíti az ügyfeleket megbízhatóbb algoritmusokra. 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).
Az OpenSSH 8.2-ben továbbra is elérhető az „ssh-rsa” használatával történő csatlakozás, de ezt az algoritmust eltávolították a CASignatureAlgorithms listáról, amely meghatározza az új tanúsítványok digitális aláírására engedélyezett algoritmusokat. Hasonlóképpen, a diffie-hellman-group14-sha1 algoritmust eltávolítottuk a támogatott alapértelmezett kulcscsere-algoritmusok közül. Megjegyzendő, hogy az SHA-1 használata a tanúsítványokban további kockázattal jár, mivel a támadónak korlátlan ideje áll rendelkezésére, hogy ütközést keressen egy meglévő tanúsítványnál, míg a gazdagép kulcsok elleni támadás idejét a csatlakozási időtúllépés korlátozza (LoginGraceTime ).
Az ssh-keygen futtatása alapértelmezés szerint az rsa-sha2-512 algoritmust használja, amely az OpenSSH 7.2 óta támogatott, ami kompatibilitási problémákat okozhat az OpenSSH 8.2 aláírt tanúsítványok feldolgozása során régebbi OpenSSH-kiadásokat futtató rendszereken (a probléma megkerülése érdekében Az aláírás generálásakor kifejezetten megadhatja az „ssh-keygen -t ssh-rsa” paramétert, vagy használhatja az OpenSSH 2 óta támogatott ecdsa-sha256-nistp384/521/5.7 algoritmusokat.
Egyéb változások:
- Az sshd_config-hoz egy Include direktíva került, amely lehetővé teszi más fájlok tartalmának a konfigurációs fájl aktuális pozíciójában való szerepeltetését (a fájlnév megadásakor glob maszkok használhatók);
- A „no-touch-required” opció hozzáadásra került az ssh-keygenhez, amely letiltja a tokenhez való hozzáférés fizikai megerősítésének szükségességét a kulcs generálásakor;
- A PubkeyAuthOptions direktíva hozzáadásra került az sshd_config fájlhoz, amely a nyilvános kulcsú hitelesítéshez kapcsolódó különféle lehetőségeket egyesíti. Jelenleg csak a „no-touch-required” jelző támogatott a fizikai jelenlét ellenőrzésének kihagyásához a token hitelesítéshez. Hasonló módon a „no-touch-required” opció hozzáadásra került az Author_keys fájlhoz;
- A "-O write-attestation=/path" opció hozzáadva az ssh-keygenhez, hogy lehetővé tegye további FIDO tanúsítványok írását a kulcsok generálásakor. Az OpenSSH még nem használja ezeket a tanúsítványokat, de később felhasználhatók annak ellenőrzésére, hogy a kulcs megbízható hardverboltban van-e elhelyezve;
- Az ssh és sshd beállításokban most már lehetőség van a forgalom prioritási mód beállítására az IPQoS direktíván keresztül (Kisebb ugrásonkénti erőfeszítés);
- Az ssh-ban az „AddKeysToAgent=yes” érték beállításakor, ha a kulcs nem tartalmaz megjegyzésmezőt, akkor hozzáadódik az ssh-agenthez, és megjegyzésként jelzi a kulcs elérési útját. BAN BEN
Az ssh-keygen és az ssh-agent mostantól a PKCS#11 címkéket és az X.509 tárgynevet is használja a könyvtár elérési útja helyett megjegyzésként a kulcsban; - Hozzáadtuk a DSA és ECDSA kulcsok PEM exportálásának lehetőségét az ssh-keygenbe;
- Hozzáadott egy új végrehajtható fájlt, az ssh-sk-helpert, amely a FIDO/U2F token hozzáférési könyvtár elkülönítésére szolgál;
- A „--with-zlib” build opció hozzáadva az ssh-hez és az sshd-hez a zlib könyvtár támogatásával történő fordításhoz;
- Az RFC4253 követelményének megfelelően a MaxStartups korlátok túllépése miatti hozzáférés blokkolására vonatkozó figyelmeztetés a csatlakozás során megjelenő bannerben jelenik meg. A diagnosztika egyszerűsítése érdekében az sshd folyamatfejléc, amely a ps segédprogram használatakor látható, mostantól megjeleníti az aktuálisan hitelesített kapcsolatok számát és a MaxStartups korlát állapotát;
- Az ssh-ban és az ssh-agentben, amikor meghív egy programot, hogy megjelenítse a képernyőn a $SSH_ASKPASS-ban megadott meghívót, a rendszer ezentúl egy zászlót küld a meghívó típusával: „confirm” - megerősítési párbeszédpanel (igen/nem), „nincs ” - tájékoztató üzenet, „üres” – jelszókérés;
- Az ssh-keygenhez hozzáadtunk egy új "find-principals" digitális aláírási műveletet, amellyel az engedélyezett aláíró fájlban megkeresheti a megadott digitális aláíráshoz társított felhasználót;
- Továbbfejlesztett támogatás az sshd folyamatok elkülönítéséhez Linuxon a seccomp mechanizmus segítségével: az IPC rendszerhívások letiltása, a clock_gettime64(), a clock_nanosleep_time64 és a clock_nanosleep() engedélyezése.
Forrás: opennet.ru