Release av OpenSSH 8.2 med stöd för FIDO/U2F tvåfaktorsautentiseringstoken

Efter fyra månaders utveckling presenteras släpp OpenSSH 8.2, en öppen klient- och serverimplementering för att arbeta via SSH 2.0- och SFTP-protokollen.

En viktig förbättring i OpenSSH 8.2-versionen är möjligheten att använda tvåfaktorsautentisering med enheter som stöder protokollet. U2F, utvecklad av alliansen FIDO. U2F möjliggör skapandet av billiga hårdvarutokens för att verifiera den fysiska närvaron av en användare, som interagerar med vilken utförs via USB, Bluetooth eller NFC. Sådana enheter marknadsförs som ett sätt för tvåfaktorsautentisering på webbplatser, stöds redan av stora webbläsare och är tillgängliga från en mängd olika tillverkare, inklusive Yubico, Feitian, Thetis och Kensington.

För att interagera med enheter som bekräftar användarens närvaro har OpenSSH lagt till nya nyckeltyper "ecdsa-sk" och "ed25519-sk" som använder ECDSA och Ed25519 digitala signaturalgoritmer, kombinerat med SHA-256 hash. Procedurerna för att interagera med tokens flyttas till ett mellanliggande bibliotek, som laddas på samma sätt som biblioteket för att stödja PKCS#11 och är ett omslag runt biblioteket. libfido2, som ger möjlighet att kommunicera med tokens via USB (protokollen FIDO U2F/CTAP 1 och FIDO 2.0/CTAP 2 stöds). Det mellanliggande biblioteket libsk-libfido2 framställt av OpenSSH-utvecklarna ingår in i kärnan libfido2-kompositionen, samt HID-drivrutin för OpenBSD.

För att autentisera och generera en nyckel måste du ange parametern "SecurityKeyProvider" i inställningarna eller ställa in miljövariabeln SSH_SK_PROVIDER och ange sökvägen till det externa biblioteket libsk-libfido2.so (exportera SSH_SK_PROVIDER=/path/to/libsk-libfido2.so). Det är möjligt att bygga openssh med inbyggt stöd för mellanbiblioteket (—with-security-key-builtin), i det här fallet är det nödvändigt att ställa in parametern "SecurityKeyProvider=internal".
Därefter måste du köra "ssh-keygen -t ecdsa-sk" eller, om nycklarna redan har skapats och konfigurerats, ansluta till servern med "ssh". När du kör ssh-keygen kommer det genererade nyckelparet att sparas i "~/.ssh/id_ecdsa_sk" och kan användas som andra nycklar.

Den publika nyckeln (id_ecdsa_sk.pub) ska kopieras till servern i filen authorized_keys. På serversidan kontrolleras endast den digitala signaturen och interaktion med tokens utförs på klientsidan (servern behöver inte installera libsk-libfido2, men servern måste stödja nyckeltypen "ecdsa-sk"). Den genererade privata nyckeln (id_ecdsa_sk) är i huvudsak en nyckelbeskrivning som bildar en riktig nyckel endast när den kombineras med den hemliga sekvensen lagrad på U2F-tokensidan. Om id_ecdsa_sk-nyckeln hamnar i händerna på en angripare, för att passera autentisering, måste han också få tillgång till en hårdvarutoken, utan vilken den privata nyckeln som sparats i filen id_ecdsa_sk är värdelös.

Dessutom, som standard, kräver alla nyckeloperationer (både generering och autentisering) lokal bekräftelse av användarens fysiska närvaro, som att röra en sensor på en token, vilket gör det svårt att utföra fjärrattacker på system med en ansluten token. Som en annan försvarslinje kan ett lösenord för att komma åt nyckelfilen också anges vid ssh-keygen-startstadiet.

Den nya versionen av OpenSSH meddelade också den kommande utfasningen av algoritmer som använder SHA-1-hashar p.g.a. befordran effektiviteten av kollisionsattacker med ett givet prefix (kostnaden för att välja en kollision uppskattas till cirka 45 tusen dollar). I en av de kommande utgåvorna planerar de att som standard inaktivera möjligheten att använda den digitala signaturalgoritmen för publik nyckel "ssh-rsa", som nämns i den ursprungliga RFC för SSH-protokollet och som fortfarande är utbredd i praktiken (för att testa användningen av ssh-rsa i dina system, kan du försöka ansluta via ssh med alternativet "-oHostKeyAlgorithms=-ssh-rsa").

För att smidiga övergången till nya algoritmer i OpenSSH, i en framtida version kommer UpdateHostKeys-inställningen att vara aktiverad som standard, vilket automatiskt kommer att migrera klienter till mer pålitliga algoritmer. Rekommenderade algoritmer för migrering inkluderar rsa-sha2-256/512 baserad på RFC8332 RSA SHA-2 (stöds sedan OpenSSH 7.2 och används som standard), ssh-ed25519 (stöds sedan OpenSSH 6.5) och ecdsa-sha2-nistp256/384 baserat på RFC521 ECDSA (stöds sedan OpenSSH 5656).

I OpenSSH 8.2 är möjligheten att ansluta med "ssh-rsa" fortfarande tillgänglig, men denna algoritm har tagits bort från CASignatureAlgorithms-listan, som definierar de algoritmer som är tillåtna för digital signering av nya certifikat. På liknande sätt har diffie-hellman-group14-sha1-algoritmen tagits bort från de standardstödda nyckelutbytesalgoritmerna. Det noteras att användning av SHA-1 i certifikat är förknippad med ytterligare risk, eftersom angriparen har obegränsad tid på sig att hitta en kollision för ett befintligt certifikat, medan attacktiden på värdnycklar begränsas av anslutningstiden (LoginGraceTime).

När du kör ssh-keygen används rsa-sha2-512-algoritmen, som stöds sedan OpenSSH 7.2, nu som standard, vilket kan skapa kompatibilitetsproblem när du försöker bearbeta OpenSSH 8.2-signerade certifikat på system med äldre OpenSSH-utgåvor (för att komma runt problemet kan du uttryckligen ange "ssh-keygen" eller använd signaturen -sa. ecdsa-sha2-nistp256/384/521 algoritmer som stöds sedan OpenSSH 5.7).

Andra ändringar:

• Inkludera-direktivet har lagts till i sshd_config, vilket gör att innehållet i andra filer kan inkluderas i den aktuella positionen för konfigurationsfilen (globmasker kan användas när filnamnet specificeras);
• Alternativet 'no-touch-required' har lagts till i ssh-keygen, vilket inaktiverar behovet av fysisk bekräftelse av åtkomst till token när en nyckel genereras;
• Ett PubkeyAuthOptions-direktiv har lagts till i sshd_config för att gruppera olika alternativ relaterade till autentisering med publik nyckel. För närvarande stöds endast flaggan "no-touch-required" för att hoppa över den fysiska närvarokontrollen vid auktorisering med en token. I analogi har alternativet "no-touch-required" lagts till i filen authorized_keys;
• Lade till alternativet "-O write-attestation=/path" till ssh-keygen för att tillåta skrivning av ytterligare FIDO-attestationscertifikat vid generering av nycklar. OpenSSH använder för närvarande inte dessa certifikat, men de kan användas i framtiden för att verifiera att nyckeln är lagrad i en betrodd hårdvarulagring;
• I ssh- och sshd-inställningarna är det nu möjligt att ställa in trafikprioriteringsläget via IPQoS-direktivet LE DSCP (Lägre ansträngning per hop-beteende);
• I ssh, när du ställer in "AddKeysToAgent=yes", om en nyckel inte innehåller ett kommentarsfält, kommer den att läggas till i ssh-agent med sökvägen till nyckeln specificerad som en kommentar. I
  ssh-keygen och ssh-agent använder nu också PKCS#11-etiketter och X.509-ämnesnamn som kommentarer i nyckeln istället för bibliotekssökvägen;
• Lagt till möjlighet att exportera PEM för DSA- och ECDSA-nycklar till ssh-keygen;
• Lade till ny körbar ssh-sk-helper som används för att isolera FIDO/U2F-tokenåtkomstbiblioteket;
• Lade till "--with-zlib" byggalternativ till ssh och sshd för att kompilera med zlib-biblioteksstöd;
• I enlighet med RFC4253 visar bannern som visas vid anslutning nu en varning om att åtkomst blockeras på grund av att MaxStartups-gränserna överskrids. För att förenkla diagnostiken visar sshd-processhuvudet, som är synligt när du använder ps-verktyget, nu antalet för närvarande autentiserade anslutningar och MaxStartups gränsstatus;
• I ssh och ssh-agent, när ett program anropas för att visa en prompt på skärmen, specificerad via $SSH_ASKPASS, skickas nu dessutom en flagga med prompttypen: "confirm" - bekräftelsedialogruta (ja/nej), "ingen" - informationsmeddelande, "tom" - lösenordsbegäran;
• En ny digital signaturoperation "find-principals" har lagts till i ssh-keygen för att söka i filen för tillåtna undertecknare efter användaren som är associerad med den specificerade digitala signaturen;
• Förbättrat stöd för isolering av sshd-processer i Linux med hjälp av seccomp-mekanismen: IPC-systemanrop är inaktiverade, clock_gettime64(), clock_nanosleep_time64 och clock_nanosleep() är tillåtna.

Källa: opennet.ru