OpenSSH 8.2 väljalase koos FIDO/U2F kahefaktorilise autentimislubade toega

Pärast neljakuulist arengut esitatakse vabastama OpenSSH 8.2, avatud kliendi ja serveri juurutus SSH 2.0 ja SFTP protokollide kaudu töötamiseks.

OpenSSH 8.2 väljalaske peamine täiustus oli võimalus kasutada kahefaktorilist autentimist, kasutades protokolli toetavaid seadmeid U2F, mille on välja töötanud liit FIDO. U2F võimaldab luua odavaid riistvaramärke, et kontrollida kasutaja füüsilist kohalolekut, suheldes nendega USB, Bluetoothi ​​või NFC kaudu. Selliseid seadmeid reklaamitakse veebisaitidel kahefaktorilise autentimise vahendina, suuremad brauserid juba toetavad neid ja neid toodavad erinevad tootjad, sealhulgas Yubico, Feitian, Thetis ja Kensington.

Kasutaja kohalolekut kinnitavate seadmetega suhtlemiseks on OpenSSH-sse lisatud uued võtmetüübid “ecdsa-sk” ja “ed25519-sk”, mis kasutavad ECDSA ja Ed25519 digitaalallkirja algoritme koos SHA-256 räsiga. Tokenidega suhtlemise protseduurid paigutatakse vahepealsesse teeki, mis laaditakse sarnaselt PKCS#11 toe teegile ja on teegi peal olev ümbris libfido2, mis pakub tööriistu USB kaudu žetoonidega suhtlemiseks (toetatud on FIDO U2F/CTAP 1 ja FIDO 2.0/CTAP 2 protokollid). Vaheteek libsk-libfido2, mille on koostanud OpenSSH arendajad kaasa arvatud libfido2-sse, samuti HID juht OpenBSD jaoks.

Võtme autentimiseks ja genereerimiseks peate määrama seadetes parameetri "SecurityKeyProvider" või määrama keskkonnamuutuja SSH_SK_PROVIDER, mis näitab välise teegi libsk-libfido2.so teed (eksportige SSH_SK_PROVIDER=/path/to/libsk-libfido2. nii). Kihtteegi sisseehitatud toega on võimalik ehitada openssh (--with-security-key-builtin), sel juhul tuleb määrata parameeter “SecurityKeyProvider=internal”.
Järgmisena peate käivitama "ssh-keygen -t ecdsa-sk" või kui võtmed on juba loodud ja konfigureeritud, looge ühendus serveriga "ssh" abil. Kui käivitate käsu ssh-keygen, salvestatakse loodud võtmepaar kausta "~/.ssh/id_ecdsa_sk" ja seda saab kasutada sarnaselt teiste võtmetega.

Avalik võti (id_ecdsa_sk.pub) tuleks kopeerida faili authorised_keys serverisse. Serveri poolel kontrollitakse ainult digitaalset allkirja ja kliendi poolel toimub interaktsioon žetoonidega (te ei pea serverisse installima libsk-libfido2, kuid server peab toetama võtmetüüpi "ecdsa-sk") . Loodud privaatvõti (id_ecdsa_sk) on sisuliselt võtmekäepide, mis moodustab reaalse võtme ainult koos U2F-märgi poolele salvestatud salajadaga. Kui võti id_ecdsa_sk satub ründaja kätte, peab ta autentimise läbimiseks saama juurdepääsu ka riistvaramärgile, ilma milleta pole failis id_ecdsa_sk salvestatud privaatvõti kasutu.

Lisaks on vaikimisi võtmetega mis tahes toimingute tegemisel (nii genereerimisel kui ka autentimise ajal) vaja kohalikku kinnitust kasutaja füüsilise kohaloleku kohta, näiteks tehakse ettepanek puudutada tokenil olevat andurit, mis raskendab sooritada kaugrünnakuid ühendatud märgiga süsteemidele. Teise kaitseliinina saab võtmefailile juurdepääsuks määrata ka parooli ssh-keygeni käivitusfaasis.

OpenSSH uus versioon teatas ka SHA-1 räsi kasutavate algoritmide peatsest amortisatsioonist, kuna edendamine kokkupõrkerünnakute tõhusus antud eesliitega (kokkupõrke valimise maksumus on hinnanguliselt umbes 45 tuhat dollarit). Ühes tulevastest väljaannetest kavatsevad nad vaikimisi keelata avaliku võtme digitaalallkirja algoritmi “ssh-rsa”, mida mainitakse SSH-protokolli algses RFC-s ja mis on praktikas laialt levinud (kasutamise testimiseks). ssh-rsa-st oma süsteemides, võite proovida ühenduse luua ssh-i kaudu valikuga "-oHostKeyAlgorithms=-ssh-rsa").

OpenSSH-i uutele algoritmidele ülemineku sujuvamaks muutmiseks lubatakse tulevases versioonis vaikimisi säte UpdateHostKeys, mis migreerib kliendid automaatselt usaldusväärsematele algoritmidele. Soovitatavad migratsioonialgoritmid on rsa-sha2-256/512, mis põhineb RFC8332 RSA SHA-2-l (toetatud alates OpenSSH 7.2-st ja kasutatakse vaikimisi), ssh-ed25519 (toetatud alates OpenSSH 6.5-st) ja ecdsa-sha2-nistp256/384-põhine 521/5656/5.7 RFCXNUMX ECDSA-l (toetatud alates OpenSSH XNUMX-st).

OpenSSH 8.2-s on ssh-rsa abil ühenduse loomise võimalus endiselt saadaval, kuid see algoritm on eemaldatud loendist CASignatureAlgorithms, mis määrab uute sertifikaatide digitaalseks allkirjastamiseks lubatud algoritmid. Samamoodi on toetatud võtmevahetuse vaikealgoritmidest eemaldatud algoritm diffie-hellman-group14-sha1. Märgitakse, et SHA-1 kasutamine sertifikaatides on seotud lisariskiga, kuna ründajal on piiramatu aeg otsida olemasoleva sertifikaadi kokkupõrget, samas kui hostivõtmete ründamise aega piirab ühenduse ajalõpp (LoginGraceTime ).

Funktsiooni ssh-keygen käitamisel kasutab nüüd vaikimisi algoritm rsa-sha2-512, mida toetatakse alates versioonist OpenSSH 7.2, mis võib tekitada ühilduvusprobleeme, kui proovite töödelda OpenSSH 8.2-ga allkirjastatud sertifikaate süsteemides, mis käitavad vanemaid OpenSSH-i versioone (et probleemist mööda minna, kui allkirja loomisel saate selgesõnaliselt määrata "ssh-keygen -t ssh-rsa" või kasutada algoritme ecdsa-sha2-nistp256/384/521, mida toetatakse alates versioonist OpenSSH 5.7).

Muud muudatused:

  • Lahtrisse sshd_config on lisatud käsk Include, mis võimaldab konfiguratsioonifaili praeguses asukohas kaasata teiste failide sisu (faili nime määramisel saab kasutada glob maske);
  • Ssh-keygenile on lisatud valik “no-touch-required”, mis keelab võtme genereerimisel juurdepääsu loale füüsiliselt kinnitamise vajaduse;
  • Dokumendile sshd_config on lisatud PubkeyAuthOptions direktiiv, mis ühendab erinevaid avaliku võtme autentimisega seotud valikuid. Praegu toetatakse ainult märgistust "no-touch-required", et jätta vahele loa autentimise füüsilise kohaloleku kontrollimine. Analoogia põhjal on failile authorised_keys lisatud valik "no-touch-required";
  • Lisatud ssh-keygenile suvand "-O write-attestation=/path", et võimaldada võtmete genereerimisel täiendavate FIDO atesteerimissertifikaatide kirjutamist. OpenSSH ei kasuta veel neid sertifikaate, kuid hiljem saab nende abil kontrollida, kas võti on paigutatud usaldusväärsesse riistvarapoodi;
  • Ssh ja sshd seadetes on nüüd võimalik IPQoS direktiivi kaudu määrata liikluse prioriseerimise režiimi LE DSCP (Madalama pingutusega hüppekäitumine);
  • Kui võti ei sisalda ssh-s väärtuse “AddKeysToAgent=yes” määramisel kommentaarivälja, lisatakse see ssh-agendile, mis näitab kommentaarina võtme teed. IN
    ssh-keygen ja ssh-agent kasutavad nüüd ka võtmes kommentaaridena teegi tee asemel PKCS#11 silte ja X.509 teema nime;

  • Lisatud võimalus eksportida DSA ja ECDSA võtmete PEM-i ssh-keygeni;
  • Lisatud uus käivitatav fail ssh-sk-helper, mida kasutatakse FIDO/U2F lubade juurdepääsuteegi isoleerimiseks;
  • Lisatud ssh-le ja sshd-le koostamisvalik „--with-zlib” zlib teegi toega kompileerimiseks;
  • Vastavalt RFC4253 nõudele kuvatakse ühenduse ajal kuvatavas bänneris hoiatus MaxStartupsi limiitide ületamise tõttu juurdepääsu blokeerimise kohta. Diagnostika lihtsustamiseks kuvab ps-utiliidi kasutamisel nähtav sshd protsessi päis praegu autentitud ühenduste arvu ja MaxStartupsi limiidi olekut;
  • Ssh- ja ssh-agentis, kui kutsute programmi $SSH_ASKPASS kaudu määratud kutse kuvamiseks ekraanile, edastatakse nüüd täiendavalt kutse tüübiga lipp: "kinnita" - kinnitusdialoog (jah/ei), "puudub ” - informatiivne teade, "tühi" - paroolinõue;
  • Lisati ssh-keygenile uus digitaalallkirjade operatsioon "find-principals", et otsida lubatud allkirjastajate failist määratud digitaalallkirjaga seotud kasutajat;
  • Täiustatud tugi sshd-protsesside eraldamisele Linuxis, kasutades seccomp-mehhanismi: IPC-süsteemi kõnede keelamine, clock_gettime64(), clock_nanosleep_time64 ja clock_nanosleep() lubamine.

Allikas: opennet.ru

Lisa kommentaar