Nei fjouwer moannen fan ûntwikkeling frijlitte , in iepen client- en server-ymplemintaasje foar wurkjen fia de SSH 2.0- en SFTP-protokollen.
In wichtige ferbettering yn 'e frijlitting fan OpenSSH 8.2 wie de mooglikheid om twa-faktor-autentikaasje te brûken mei apparaten dy't it protokol stypje , ûntwikkele troch it alliânsje . U2F lit it oanmeitsjen fan goedkeape hardware-tokens om de fysike oanwêzigens fan 'e brûker te ferifiearjen, ynteraksje mei har fia USB, Bluetooth of NFC. Sokke apparaten wurde befoardere as in middel fan twa-faktor autentikaasje op websiden, wurde al stipe troch grutte browsers en wurde produsearre troch ferskate fabrikanten, ynklusyf Yubico, Feitian, Thetis en Kensington.
Om ynteraksje mei apparaten dy't de oanwêzigens fan 'e brûker befêstigje, binne nije kaaitypen "ecdsa-sk" en "ed25519-sk" tafoege oan OpenSSH, dy't de ECDSA en Ed25519 digitale hantekeningalgoritmen brûke, kombineare mei de SHA-256-hash. Prosedueres foar ynteraksje mei tokens wurde pleatst yn in tuskenlizzende bibleteek, dat wurdt laden op in fergelykbere wize oan de bibleteek foar PKCS # 11 stipe en is in wrapper boppe op 'e bibleteek , dy't ark biedt foar kommunikaasje mei tokens oer USB (FIDO U2F / CTAP 1 en FIDO 2.0 / CTAP 2-protokollen wurde stipe). Intermediate bibleteek libsk-libfido2 taret troch OpenSSH-ûntwikkelders yn 'e kearn libfido2, lykas foar OpenBSD.
Om in kaai te ferifiearjen en te generearjen, moatte jo de parameter "SecurityKeyProvider" yn 'e ynstellings opjaan of de omjouwingsfariabele SSH_SK_PROVIDER ynstelle, it paad oanjout nei de eksterne bibleteek libsk-libfido2.so (eksportearje SSH_SK_PROVIDER=/path/to/libsk-libfido2. sa). It is mooglik om openssh te bouwen mei ynboude stipe foar de laachbibleteek (--with-security-key-builtin), yn dit gefal moatte jo de parameter "SecurityKeyProvider = ynterne" ynstelle.
Folgjende moatte jo "ssh-keygen -t ecdsa-sk" útfiere of, as de kaaien al binne oanmakke en konfigureare, ferbine mei de tsjinner mei "ssh". As jo ssh-keygen útfiere, sil it generearre kaaipaar bewarre wurde yn "~/.ssh/id_ecdsa_sk" en kin op deselde manier brûkt wurde as oare kaaien.
De iepenbiere kaai (id_ecdsa_sk.pub) moat kopiearre wurde nei de tsjinner yn it autorisearre_keys-bestân. Oan 'e serverkant wurdt allinich de digitale hantekening ferifiearre, en ynteraksje mei tokens wurdt útfierd op' e kliïntside (jo moatte libsk-libfido2 net op 'e server ynstallearje, mar de server moat it toetstype "ecdsa-sk" stypje) . De oanmakke privee kaai (id_ecdsa_sk) is yn wêzen in kaai handgreep, foarmje in echte kaai allinnich yn kombinaasje mei de geheime folchoarder opslein op de U2F token kant. As de id_ecdsa_sk-kaai yn 'e hannen fan in oanfaller falt, om autentikaasje troch te jaan, sil hy ek tagong moatte krije ta it hardware-token, sûnder dat de priveekaai opslein yn 'e id_ecdsa_sk-bestân nutteloos is.
Derneist is standert by it útfieren fan alle operaasjes mei toetsen (sawol tidens generaasje as tidens ferifikaasje) lokale befêstiging fan 'e fysike oanwêzigens fan' e brûker fereaske, bygelyks wurdt it foarsteld om de sensor op 'e token te berikken, wat it dreech makket útfiere oanfallen op ôfstân op systemen mei in ferbûn token. As in oare line fan definsje kin in wachtwurd ek opjûn wurde yn 'e opstartfaze fan ssh-keygen om tagong te krijen ta it kaaibestân.
De nije ferzje fan OpenSSH kundige ek de kommende ôfskriuwing fan algoritmen oan mei SHA-1-hashes fanwegen de effektiviteit fan botsingsoanfallen mei in opjûn foarheaksel (de kosten foar it selektearjen fan in botsing wurde rûsd op likernôch 45 tûzen dollar). Yn ien fan 'e kommende releases binne se fan plan om standert de mooglikheid út te skeakeljen om it digitale hantekeningalgoritme fan iepenbiere kaai "ssh-rsa" te brûken, dat wurdt neamd yn 'e orizjinele RFC foar it SSH-protokol en bliuwt wiidferspraat yn 'e praktyk (om it gebrûk te testen fan ssh-rsa yn jo systemen, kinne jo besykje te ferbinen fia ssh mei de opsje "-oHostKeyAlgorithms=-ssh-rsa").
Om de oergong nei nije algoritmen yn OpenSSH glêd te meitsjen, sil yn in takomstige release de UpdateHostKeys-ynstelling standert ynskeakele wurde, dy't kliïnten automatysk migrearje nei betrouberere algoritmen. Oanrikkemandearre algoritmen foar migraasje omfetsje rsa-sha2-256/512 basearre op RFC8332 RSA SHA-2 (stipe sûnt OpenSSH 7.2 en standert brûkt), ssh-ed25519 (stipe sûnt OpenSSH 6.5) en ecdsa-sha2-nistp256/384 basearre op RFC521 ECDSA (stipe sûnt OpenSSH 5656).
Yn OpenSSH 8.2 is de mooglikheid om te ferbinen mei "ssh-rsa" noch altyd beskikber, mar dit algoritme is fuortsmiten fan 'e list CASignatureAlgorithms, dy't de algoritmen definieart dy't tastien binne foar digitaal ûndertekenjen fan nije sertifikaten. Likemin is it diffie-hellman-group14-sha1-algoritme fuortsmiten fan 'e standert stipe algoritmen foar kaai-útwikseling. It wurdt opmurken dat it brûken fan SHA-1 yn sertifikaten is assosjearre mei ekstra risiko, sûnt de oanfaller hat ûnbeheinde tiid om te sykjen nei in botsing foar in besteande sertifikaat, wylst de tiid fan oanfal op host kaaien wurdt beheind troch de ferbining timeout (LoginGraceTime ).
It útfieren fan ssh-keygen is no standert op it rsa-sha2-512-algoritme, dat wurdt stipe sûnt OpenSSH 7.2, wat kompatibiliteitsproblemen kin meitsje as jo besykje sertifikaten te ferwurkjen ûndertekene yn OpenSSH 8.2 op systemen dy't âldere OpenSSH-releases draaie (om it probleem om te wurkjen as wannear in hantekening generearje, kinne jo "ssh-keygen -t ssh-rsa" eksplisyt oantsjutte of de ecdsa-sha2-nistp256/384/521-algoritmen brûke, stipe sûnt OpenSSH 5.7).
Oare feroarings:
- In Include-rjochtline is tafoege oan sshd_config, wêrtroch jo de ynhâld fan oare bestannen op 'e aktuele posysje fan it konfiguraasjetriem kinne opnimme (globmaskers kinne brûkt wurde by it opjaan fan de triemnamme);
- De opsje "no-touch-required" is tafoege oan ssh-keygen, dy't de needsaak útskeakelje om fysike tagong ta it token te befestigjen by it generearjen fan de kaai;
- In PubkeyAuthOptions-rjochtline is tafoege oan sshd_config, dy't ferskate opsjes kombinearret yn ferbân mei publike kaai-autentikaasje. Op it stuit wurdt allinich de "no-touch-required" flagge stipe om fysike oanwêzigenskontrôles oer te slaan foar token-autentikaasje. Troch analogy is de opsje "no-touch-required" tafoege oan it authorized_keys-bestân;
- Added "-O write-attestation=/path" opsje oan ssh-keygen om ekstra FIDO attestationsertifikaten te skriuwen by it generearjen fan kaaien. OpenSSH brûkt noch net dizze sertifikaten, mar se kinne letter brûkt wurde om te kontrolearjen dat de kaai is pleatst yn in fertroude hardware winkel;
- Yn 'e ssh- en sshd-ynstellingen is it no mooglik om de ferkearsprioritearingsmodus yn te stellen fia de IPQoS-rjochtline (Leger-Effort Per-Hop Gedrach);
- Yn ssh, by it ynstellen fan de wearde "AddKeysToAgent = ja", as de kaai gjin opmerkingsfjild befettet, sil it tafoege wurde oan ssh-agent dy't it paad nei de kaai as kommentaar oanjout. YN
ssh-keygen en ssh-agent brûke no ek PKCS#11-labels en de X.509-ûnderwerpnamme ynstee fan it bibleteekpaad as opmerkings yn 'e kaai; - De mooglikheid tafoege om PEM te eksportearjen foar DSA- en ECDSA-kaaien nei ssh-keygen;
- In nije útfierbere tafoege, ssh-sk-helper, brûkt om de FIDO/U2F token tagongsbibleteek te isolearjen;
- Added "--with-zlib" bouwopsje oan ssh en sshd foar kompilaasje mei zlib-bibleteek-stipe;
- Yn oerienstimming mei de eask fan RFC4253 wurdt in warskôging oer tagongsblokkering fanwege it oersjen fan MaxStartups-grinzen oanbean yn 'e banner dy't werjûn wurdt by ferbining. Om de diagnoaze te ferienfâldigjen, toant de sshd-proseskop, sichtber by it brûken fan it ps-hulpprogramma, no it oantal op it stuit authentisearre ferbiningen en de status fan 'e MaxStartups-limyt;
- Yn ssh en ssh-agent, by it oproppen fan in programma om in útnoeging op it skerm te werjaan, spesifisearre fia $SSH_ASKPASS, wurdt no ek in flagge mei it type útnoeging oerbrocht: "befêstigje" - befêstigingsdialooch (ja/nee), "gjin" " - ynformatyf berjocht, "blank" - wachtwurd fersyk;
- In nije operaasje foar digitale hantekeningen "find-principals" tafoege oan ssh-keygen om it bestân mei tastiene ûndertekeners te sykjen foar de brûker dy't ferbûn is mei in spesifisearre digitale hantekening;
- Ferbettere stipe foar sshd proses isolaasje op Linux mei help fan de seccomp meganisme: útskeakelje IPC systeem calls, wêrtroch clock_gettime64 (), clock_nanosleep_time64 en clock_nanosleep ().
Boarne: opennet.ru