Négy hónapos fejlesztés után kiadás , nyílt forrású ügyfél- és szervermegoldás az SSH 2.0 és SFTP protokollok használatához.
Az OpenSSH 8.2 kiadásának kulcsfontosságú fejlesztése a kétfaktoros hitelesítés használatának lehetősége olyan eszközökkel, amelyek támogatják a , a szövetség által kifejlesztett. Az U2F lehetővé teszi, hogy olcsó hardvertokeneket hozzunk létre a felhasználó fizikai jelenlétének megerősítésére, amelyek USB, Bluetooth vagy NFC interfészen keresztül kommunikálnak. Ezeket az eszközöket a kétfaktoros hitelesítési megoldások részeként népszerűsítik, a főbb böngészők már támogatják őket, és különböző gyártók, például Yubico, Feitian, Thetis és Kensington kínálják.
Az OpenSSH-ban új kulcstípusok, az «ecdsa-sk» és «ed25519-sk» is hozzá lettek adva, amelyek ECDSA és Ed25519 digitális aláírási algoritmusokat használnak, kombinálva a SHA-256 hash algoritmussal. A tokenekkel való interakció eljárásait egy köztes könyvtárba helyezték, amely hasonlóan betöltődik, mint a PKCS#11 támogatásához használt könyvtár, és az , amely eszközöket biztosít USB-n keresztül történő kommunikációhoz (támogatja a FIDO U2F/CTAP 1 és FIDO 2.0/CTAP 2 protokollokat). Az OpenSSH fejlesztői által készített libsk-libfido2 köztes könyvtár a libfido2 fő összetevője, akárcsak a az OpenBSD-hez.
A hitelesítéshez és a kulcs generálásához a beállításokban meg kell adni a «SecurityKeyProvider» paramétert, vagy be kell állítani az SSH_SK_PROVIDER környezeti változót a libsk-libfido2.so külső könyvtár elérési útjával (export SSH_SK_PROVIDER=/path/to/libsk-libfido2.so). Lehetséges a openssh összeállítása beépített rétegkönyvtárral (—with-security-key-builtin), ebben az esetben a «SecurityKeyProvider=internal» paramétert kell megadni.
Ezután el kell indítani az «ssh-keygen -t ecdsa-sk» parancsot, vagy ha a kulcsok már létrejöttek és be vannak állítva, a «ssh» parancs segítségével csatlakozni a szerverhez. Az ssh-keygen futtatásakor a létrehozott kulcspár a «~/.ssh/id_ecdsa_sk» fájlba 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 szerverre az authorized_keys fájlba. A szerver oldalán csak a digitális aláírást ellenőrzik, míg az interakció a tokeneivel az ügyfél oldalán történik (a szerveren nem szükséges a libsk-libfido2 telepítése, de a szervernek támogatnia kell az 'ecdsa-sk' kulcstípusokat). A generált privát kulcs (id_ecdsa_sk) lényegében a kulcs leírója, amely valós kulcsot képez csak a U2F tokenen tárolt titkos sorozattal együtt. Ha az id_ecdsa_sk kulcs egy támadó kezébe kerül, az azonosításhoz szükség van a hardver tokenhez való hozzáférésre is, anélkül, hogy a fájlban tárolt id_ecdsa_sk privát kulcs haszontalan.
Ezen kívül alapértelmezés szerint bárminemű kulcsokkal kapcsolatos művelet (mind generálás, mind azonosítás során) helyi megerősítést igényel a felhasználó fizikai jelenlétéről, például a token érzékelőjének megérintése, ami megnehezíti a távoli támadást a csatlakoztatott tokennel rendelkező rendszerek ellen. További védelmi vonalként az ssh-keygen indításakor megadható jelszó a kulcsfájlhoz való hozzáféréshez.
Az OpenSSH új verziójában bejelentették, hogy a SHA-1 hasheket használó algoritmusokat múltbeli állapotba sorolják. a megadott prefixumú ütközési támadások hatékonyságának (a kollekció költsége körülbelül 45 ezer dollárra becsülhető). Az egyik következő kiadásban tervezik letiltani az ssh-rsa nyilvános aláírás algoritmus alapértelmezett engedélyezésének lehetőségét, amely a SSH protokoll eredeti RFC-jében szerepel, és széles körben elterjedt a gyakorlatban (az ssh-rsa alkalmazásának ellenőrzésére a rendszereikben megpróbálhatnak csatlakozni ssh-val a „-oHostKeyAlgorithms=-ssh-rsa” opcióval).
A zökkenőmentes átállás érdekében az OpenSSH következő verzióiban alapértelmezés szerint aktiválva lesz az UpdateHostKeys beállítás, amely lehetővé teszi a kliensek automatikus áttérését megbízhatóbb algoritmusokra. A migrációra javasolt algoritmusok között említve van az rsa-sha2-256/512 az RFC8332 RSA SHA-2 alapján (amelyet az OpenSSH 7.2 óta támogatnak és alapértelmezésként használnak), az ssh-ed25519 (amelyet az OpenSSH 6.5 óta támogatnak) és az ecdsa-sha2-nistp256/384/521 az RFC5656 ECDSA alapján (amelyet az OpenSSH 5.7 óta támogatnak).
Az OpenSSH 8.2-es verzióban a «ssh-rsa» használatával való csatlakozás lehetősége még mindig elérhető, de ez az algoritmus eltávolításra került 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, az alapértelmezés szerint támogatott kulcscserélési algoritmusok közül eltávolították a diffie-hellman-group14-sha1 algoritmust is. Megjegyzendő, hogy a SHA-1 használata a tanúsítványokban kiegészítő kockázattal jár, mivel a támadónak korlátlan ideje van ütközések keresésére egy létező tanúsítvány esetén, míg a házigazdai kulcsok támadásának idejét a kapcsolati időkorlát (LoginGraceTime) korlátozza.
Az ssh-keygen végrehajtásakor mostantól alapértelmezettként az rsa-sha2-512 algoritmus alkalmazandó, amely az OpenSSH 7.2-től kezdődően támogatott, ami kompatibilitási problémákat okozhat, amikor megpróbálják feldolgozni az OpenSSH 8.2-t aláíró tanúsítványokat régebbi OpenSSH verziókat használó rendszereken (a probléma megkerülése érdekében a aláírás létrehozásakor kifejezetten megadható az «ssh-keygen -t ssh-rsa» vagy használhatók az OpenSSH 5.7-től támogatott ecdsa-sha2-nistp256/384/521 algoritmusok).
Egyéb változások:
- Az sshd_config fájlba hozzáadva a Include direktíva lehetővé teszi más fájlok tartalmának beillesztését a konfigurációs fájl aktuális pozíciójába (a fájlnév megadása során glob-maszkok is megengedettek);
- Az ssh-keygen-hez hozzáadva az «no-touch-required» opció, amely kikapcsolja a fizikai hozzáférés megerősítésének szükségességét a kulcs generálásakor;
- Az sshd_config fájlba hozzáadva a PubkeyAuthOptions direktíva, amely különböző opciókat egyesít, amelyek a nyilvános kulcsokkal való hitelesítéssel kapcsolatosak. Jelenleg csak a «no-touch-required» jelző támogatott, amely lehetővé teszi a token használatával történő hitelesítés során a fizikai jelenlét ellenőrzésének kihagyását. Hasonlóképpen, az authorized_keys fájlba is hozzáadva a «no-touch-required» opció;
- Az ssh-keygen-hez hozzáadva a «-O write-attestation=/path» opció, amely lehetővé teszi a FIDO további tanúsítványok rögzítését a kulcsok generálásakor. Az OpenSSH egyelőre nem használja ezeket a tanúsítványokat, de azok a jövőben felhasználhatók a kulcs megbízható hardver tárolóhelyen való elhelyezésének ellenőrzésére;
- Az ssh és sshd beállításokban az IPQoS direktívával mostantól a forgalompriorizálás módja is beállítható (Lower-Effort Per-Hop Behavior);
- Az ssh beállításaiban az «AddKeysToAgent=yes» érték beállítása esetén, ha a kulcs nem tartalmaz megjegyzés mezőt, akkor a kulcsot a ssh-agentbe a kulcs útvonalának megadásával kerül hozzáadásra megjegyzésként.
Az ssh-keygen és ssh-agent mostantól PKCS#11 címkéket és X.509 alanyneveket használnak a kulcsok megjegyzéseként a könyvtár útvonala helyett; - Az ssh-keygen-ben lehetővé vált a PEM exportálása DSA és ECDSA kulcsokhoz;
- Új futtatható fájlt adtak hozzá, az ssh-sk-helper-t, amely a FIDO/U2F token hozzáférési könyvtárának elkülönítésére használatos;
- Az ssh és sshd rendszerbeállításához hozzáadódott a "--with-zlib" opció, amely a zlib könyvtár támogatásával való fordítást teszi lehetővé;
- Az RFC4253 követelményeivel összhangban a csatlakozás során megjelenített bannerben figyelmeztetést adtak hozzá a hozzáférési korlátok túllépés miatti letiltásról a MaxStartups limitek miatt. A diagnosztika egyszerűsítése érdekében az sshd folyamat fejlécében, amely a ps eszköz használatakor látható, megjelenik az éppen hitelesített kapcsolatok száma és a MaxStartups limit állapota;
- Az ssh és ssh-agent programban, amikor a képernyő meghívásához hívják meg a $SSH_ASKPASS rendszerparancsot, mostantól egy kiegészítő zászlót kérnek le a meghívás típusával: "confirm" — megerősítő párbeszéd (igen/nem), "none" — információs üzenet, "blank" — jelszó kérés;
- Az ssh-keygen-ben egy új digitális aláírási művelet, a "find-principals" került bevezetésre, amely a megadott digitális aláíráshoz kapcsolódó felhasználó allowed-signers fájljában keres;
- Javították a folyamat elkülönítésének támogatását Linux alatt a seccomp mechanizmus használatával: megtiltották az IPC rendszerhívásokat, engedélyezték a clock_gettime64(), clock_nanosleep_time64 és clock_nanosleep() hívásokat.
Forrás: opennet.ru
