Lansarea OpenSSH 8.2 cu suport pentru jetoane de autentificare cu doi factori FIDO/U2F

După patru luni de dezvoltare prezentat eliberare OpenSSH 8.2, o implementare deschisă pentru client și server pentru lucrul prin protocoalele SSH 2.0 și SFTP.

O îmbunătățire cheie în lansarea OpenSSH 8.2 a fost capacitatea de a utiliza autentificarea cu doi factori folosind dispozitive care acceptă protocolul U2F, dezvoltat de alianță FIDO. U2F permite crearea de token-uri hardware low-cost pentru a verifica prezența fizică a utilizatorului, interacționând cu acestea prin USB, Bluetooth sau NFC. Astfel de dispozitive sunt promovate ca mijloc de autentificare cu doi factori pe site-uri web, sunt deja acceptate de browserele majore și sunt produse de diverși producători, inclusiv Yubico, Feitian, Thetis și Kensington.

Pentru a interacționa cu dispozitivele care confirmă prezența utilizatorului, noi tipuri de chei „ecdsa-sk” și „ed25519-sk” au fost adăugate la OpenSSH, care utilizează algoritmii de semnătură digitală ECDSA și Ed25519, combinați cu hash-ul SHA-256. Procedurile pentru interacțiunea cu jetoanele sunt plasate într-o bibliotecă intermediară, care este încărcată într-un mod similar cu biblioteca pentru suport PKCS#11 și este un înveliș deasupra bibliotecii libfido2, care oferă instrumente pentru comunicarea cu jetoane prin USB (protocoalele FIDO U2F/CTAP 1 și FIDO 2.0/CTAP 2 sunt acceptate). Biblioteca intermediară libsk-libfido2 pregătită de dezvoltatorii OpenSSH inclus în libfido2 de bază, precum și Driver HID pentru OpenBSD.

Pentru a autentifica și a genera o cheie, trebuie să specificați parametrul „SecurityKeyProvider” în setări sau să setați variabila de mediu SSH_SK_PROVIDER, indicând calea către biblioteca externă libsk-libfido2.so (export SSH_SK_PROVIDER=/path/to/libsk-libfido2. asa de). Este posibil să construiți openssh cu suport încorporat pentru biblioteca de straturi (--with-security-key-builtin), în acest caz trebuie să setați parametrul „SecurityKeyProvider=internal”.
Apoi, trebuie să rulați „ssh-keygen -t ecdsa-sk” sau, dacă cheile au fost deja create și configurate, conectați-vă la server folosind „ssh”. Când rulați ssh-keygen, perechea de chei generată va fi salvată în „~/.ssh/id_ecdsa_sk” și poate fi utilizată în mod similar cu alte chei.

Cheia publică (id_ecdsa_sk.pub) trebuie copiată pe server în fișierul authorized_keys. Pe partea de server, este verificată doar semnătura digitală, iar interacțiunea cu token-urile se realizează pe partea client (nu trebuie să instalați libsk-libfido2 pe server, dar serverul trebuie să accepte tipul de cheie „ecdsa-sk”). . Cheia privată generată (id_ecdsa_sk) este în esență un mâner de cheie, formând o cheie reală numai în combinație cu secvența secretă stocată pe partea jetonului U2F. Dacă cheia id_ecdsa_sk cade în mâinile unui atacator, pentru a trece autentificarea va trebui să obțină și acces la tokenul hardware, fără de care cheia privată stocată în fișierul id_ecdsa_sk este inutilă.

În plus, în mod implicit, la efectuarea oricăror operațiuni cu chei (atât în ​​timpul generării, cât și în timpul autentificării), este necesară confirmarea locală a prezenței fizice a utilizatorului, de exemplu, se propune atingerea senzorului de pe token, ceea ce face dificilă efectuați atacuri de la distanță asupra sistemelor cu un token conectat. Ca o altă linie de apărare, o parolă poate fi specificată și în timpul fazei de pornire a ssh-keygen pentru a accesa fișierul cheie.

Noua versiune a OpenSSH a anunțat, de asemenea, viitoarea depreciere a algoritmilor care utilizează hash-uri SHA-1 din cauza promovare eficacitatea atacurilor de coliziune cu un prefix dat (costul de selectare a unei coliziuni este estimat la aproximativ 45 de mii de dolari). Într-una dintre edițiile viitoare, aceștia intenționează să dezactiveze implicit capacitatea de a utiliza algoritmul de semnătură digitală cu cheie publică „ssh-rsa”, care este menționat în RFC original pentru protocolul SSH și rămâne larg răspândit în practică (pentru a testa utilizarea de ssh-rsa în sistemele dvs., puteți încerca să vă conectați prin ssh cu opțiunea „-oHostKeyAlgorithms=-ssh-rsa”).

Pentru a ușura tranziția la noi algoritmi în OpenSSH, într-o versiune viitoare setarea UpdateHostKeys va fi activată implicit, ceea ce va migra automat clienții către algoritmi mai fiabili. Algoritmii recomandați pentru migrare includ rsa-sha2-256/512 bazat pe RFC8332 RSA SHA-2 (acceptat începând cu OpenSSH 7.2 și utilizat implicit), ssh-ed25519 (acceptat începând cu OpenSSH 6.5) și ecdsa-sha2-nistp256/384 based pe RFC521 ECDSA (acceptat începând cu OpenSSH 5656).

În OpenSSH 8.2, capacitatea de a vă conecta folosind „ssh-rsa” este încă disponibilă, dar acest algoritm a fost eliminat din lista CASignatureAlgorithms, care definește algoritmii permisi pentru semnarea digitală a noilor certificate. În mod similar, algoritmul diffie-hellman-group14-sha1 a fost eliminat din algoritmii impliciti de schimb de chei acceptați. Se remarcă faptul că utilizarea SHA-1 în certificate este asociată cu un risc suplimentar, deoarece atacatorul are timp nelimitat pentru a căuta o coliziune pentru un certificat existent, în timp ce timpul de atac asupra cheilor gazdei este limitat de expirarea conexiunii (LoginGraceTime ).

Rularea ssh-keygen este acum implicită la algoritmul rsa-sha2-512, care este acceptat începând cu OpenSSH 7.2, care poate crea probleme de compatibilitate atunci când se încearcă procesarea certificatelor semnate în OpenSSH 8.2 pe sisteme care rulează versiuni mai vechi OpenSSH (pentru a rezolva problema când generând o semnătură, puteți specifica în mod explicit „ssh-keygen -t ssh-rsa” sau puteți utiliza algoritmii ecdsa-sha2-nistp256/384/521, acceptați începând cu OpenSSH 5.7).

Alte modificari:

  • La sshd_config a fost adăugată o directivă Include, care vă permite să includeți conținutul altor fișiere în poziția curentă a fișierului de configurare (măștile glob pot fi folosite când specificați numele fișierului);
  • Opțiunea „no-touch-required” a fost adăugată la ssh-keygen, care dezactivează necesitatea confirmării fizice a accesului la token la generarea cheii;
  • La sshd_config a fost adăugată o directivă PubkeyAuthOptions, care combină diverse opțiuni legate de autentificarea cu cheie publică. În prezent, este acceptat doar semnalizarea „fără atingere necesară” pentru a omite verificările prezenței fizice pentru autentificarea cu simbol. Prin analogie, opțiunea „no-touch-required” a fost adăugată la fișierul authorized_keys;
  • S-a adăugat opțiunea „-O write-attestation=/path” la ssh-keygen pentru a permite ca certificate de atestare FIDO suplimentare să fie scrise la generarea cheilor. OpenSSH nu utilizează încă aceste certificate, dar ele pot fi utilizate ulterior pentru a verifica dacă cheia este plasată într-un magazin hardware de încredere;
  • În setările ssh și sshd, acum este posibil să setați modul de prioritizare a traficului prin directiva IPQoS LE DSCP (Comportament cu efort redus per hop);
  • În ssh, când setați valoarea „AddKeysToAgent=yes”, dacă cheia nu conține un câmp de comentariu, aceasta va fi adăugată la ssh-agent indicând calea către cheie ca comentariu. ÎN
    ssh-keygen și ssh-agent folosesc acum etichetele PKCS#11 și numele subiectului X.509 în loc de calea bibliotecii ca comentarii în cheie;

  • S-a adăugat posibilitatea de a exporta PEM pentru cheile DSA și ECDSA în ssh-keygen;
  • S-a adăugat un nou executabil, ssh-sk-helper, folosit pentru a izola biblioteca de acces la token FIDO/U2F;
  • S-a adăugat opțiunea de compilare „--with-zlib” la ssh și sshd pentru compilare cu suport pentru bibliotecă zlib;
  • În conformitate cu cerința RFC4253, un avertisment despre blocarea accesului din cauza depășirii limitelor MaxStartups este furnizat în bannerul afișat în timpul conexiunii. Pentru a simplifica diagnosticarea, antetul procesului sshd, vizibil atunci când utilizați utilitarul ps, afișează acum numărul de conexiuni autentificate în prezent și starea limitei MaxStartups;
  • În ssh și ssh-agent, la apelarea unui program pentru a afișa o invitație pe ecran, specificată prin $SSH_ASKPASS, acum este transmis suplimentar un steag cu tipul de invitație: „confirmare” - dialog de confirmare (da/nu), „niciunul” ” - mesaj informativ, „blank” - cerere de parolă;
  • S-a adăugat o nouă operațiune de semnătură digitală „find-principals” la ssh-keygen pentru a căuta în fișierul de semnături permise utilizatorul asociat cu o semnătură digitală specificată;
  • Suport îmbunătățit pentru izolarea procesului sshd pe Linux folosind mecanismul seccomp: dezactivarea apelurilor de sistem IPC, permițând clock_gettime64(), clock_nanosleep_time64 și clock_nanosleep().

Sursa: opennet.ru

Adauga un comentariu