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 lanseringen av OpenSSH 8.2 var möjligheten att använda tvåfaktorsautentisering med hjälp av enheter som stöder protokollet U2F, utvecklad av alliansen FIDO. U2F tillåter skapandet av billiga hårdvarutokens för att verifiera användarens fysiska närvaro, interagera med dem 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 produceras av olika tillverkare, inklusive Yubico, Feitian, Thetis och Kensington.

För att interagera med enheter som bekräftar användarens närvaro har nya nyckeltyper "ecdsa-sk" och "ed25519-sk" lagts till i OpenSSH, som använder ECDSA och Ed25519 digitala signaturalgoritmer, kombinerat med SHA-256 hash. Procedurer för att interagera med tokens placeras i ett mellanliggande bibliotek, som laddas på liknande sätt som biblioteket för PKCS#11-stöd och är ett omslag ovanpå biblioteket libfido2, som tillhandahåller verktyg för att kommunicera med tokens via USB (protokollen FIDO U2F/CTAP 1 och FIDO 2.0/CTAP 2 stöds). Mellanbibliotek libsk-libfido2 framställt av OpenSSH-utvecklare ingår in i kärnan libfido2, liksom 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, som anger sökvägen till det externa biblioteket libsk-libfido2.so (exportera SSH_SK_PROVIDER=/path/to/libsk-libfido2. så). Det är möjligt att bygga openssh med inbyggt stöd för lagerbiblioteket (--with-security-key-builtin), i det här fallet måste du 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 på samma sätt som andra nycklar.

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

Som standard krävs dessutom lokal bekräftelse av användarens fysiska närvaro när man utför några operationer med nycklar (både under generering och under autentisering, till exempel föreslås att man rör vid sensorn på 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 också anges under startfasen av ssh-keygen för att komma åt nyckelfilen.

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 standardnyckelutbytesalgoritmer som stöds. Det noteras att användningen av SHA-1 i certifikat är förknippad med ytterligare risk, eftersom angriparen har obegränsad tid på sig att söka efter en kollision för ett befintligt certifikat, medan tiden för attack mot värdnycklar begränsas av anslutningens timeout (LoginGraceTime ).

Att köra ssh-keygen har nu som standard algoritmen rsa-sha2-512, som stöds sedan OpenSSH 7.2, vilket kan skapa kompatibilitetsproblem när man försöker bearbeta certifikat som är signerade i OpenSSH 8.2 på system som kör äldre OpenSSH-versioner (för att kringgå problemet när När du genererar en signatur kan du uttryckligen ange "ssh-keygen -t ssh-rsa" eller använda ecdsa-sha2-nistp256/384/521-algoritmerna, som stöds sedan OpenSSH 5.7).

Andra ändringar:

• Ett Include-direktiv har lagts till i sshd_config, vilket gör att du kan inkludera innehållet i andra filer på den aktuella positionen för konfigurationsfilen (globmasker kan användas när du anger filnamnet);
• Alternativet "no-touch-required" har lagts till i ssh-keygen, vilket inaktiverar behovet av att fysiskt bekräfta åtkomst till token när nyckeln genereras;
• Ett PubkeyAuthOptions-direktiv har lagts till i sshd_config, som kombinerar olika alternativ relaterade till autentisering av publik nyckel. För närvarande stöds endast flaggan "no-touch-required" för att hoppa över fysiska närvarokontroller för tokenautentisering. 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 ytterligare FIDO-attestationscertifikat att skrivas vid generering av nycklar. OpenSSH använder ännu inte dessa certifikat, men de kan senare användas för att verifiera att nyckeln är placerad i en betrodd hårdvarubutik;
• I inställningarna ssh och sshd ä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 värdet "AddKeysToAgent=yes", om nyckeln inte innehåller ett kommentarsfält, kommer den att läggas till i ssh-agent som anger sökvägen till nyckeln som en kommentar. I
  ssh-keygen och ssh-agent använder nu också PKCS#11-etiketter och X.509-ämnesnamnet istället för bibliotekssökvägen som kommentarer i nyckeln;

• Lade till möjligheten att exportera PEM för DSA- och ECDSA-nycklar till ssh-keygen;
• Lade till en 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 kompilering med zlib-biblioteksstöd;
• I enlighet med kravet i RFC4253 finns en varning om åtkomstblockering på grund av att MaxStartups gränser överskrids i bannern som visas under anslutningen. 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 statusen för MaxStartups-gränsen;
• I ssh och ssh-agent, när ett program anropas för att visa en inbjudan på skärmen, specificerad via $SSH_ASKPASS, sänds nu dessutom en flagga med typen av inbjudan: "bekräfta" - bekräftelsedialogruta (ja/nej), "ingen " - informationsmeddelande, "tom" — lösenordsbegäran;
• Lade till en ny digital signaturoperation "find-principals" till ssh-keygen för att söka i filen med tillåtna undertecknare efter användaren som är associerad med en specificerad digital signatur;
• Förbättrat stöd för sshd-processisolering på Linux med hjälp av seccomp-mekanismen: inaktivera IPC-systemanrop, tillåta clock_gettime64(), clock_nanosleep_time64 och clock_nanosleep().

Källa: opennet.ru