Na vier maande se ontwikkeling vrylating , 'n oop implementering van die kliënt en bediener om oor die SSH 2.0- en SFTP-protokolle te werk.
'n Sleutelverbetering in die vrystelling van OpenSSH 8.2 is die vermoë om tweefaktor-verifikasie te gebruik met toestelle wat die protokol ondersteun , ontwikkel deur die alliansie . U2F laat jou toe om laekoste hardeware tokens te skep om die fisiese teenwoordigheid van die gebruiker te bevestig, waarmee interaksie via USB, Bluetooth of NFC gemaak word. Hierdie toestelle word bevorder as 'n middel van twee-faktor-verifikasie op webwerwe, word reeds deur groot blaaiers ondersteun, en is beskikbaar by verskeie vervaardigers, insluitend Yubico, Feitian, Thetis en Kensington.
Om interaksie te hê met toestelle wat die gebruiker se teenwoordigheid bevestig, het OpenSSH nuwe sleuteltipes "ecdsa-sk" en "ed25519-sk" bygevoeg, wat die digitale handtekeningalgoritmes ECDSA en Ed25519 gebruik, in kombinasie met 'n SHA-256-hash. Die prosedures vir interaksie met tokens word na 'n intermediêre biblioteek geskuif, wat soortgelyk aan die biblioteek vir PKCS # 11-ondersteuning gelaai word en 'n binding oor die biblioteek is , wat middele bied om met tokens oor USB te kommunikeer (ondersteun FIDO U2F/CTAP 1- en FIDO 2.0/CTAP 2-protokolle). Voorberei deur die OpenSSH-ontwikkelaars, die intermediêre biblioteek libsk-libfido2 in die hoofsamestelling van libfido2, soos vir OpenBSD.
Vir verifikasie en sleutelgenerering moet jy die "SecurityKeyProvider" parameter in die instellings spesifiseer of die SSH_SK_PROVIDER omgewingsveranderlike stel, wat die pad na die eksterne biblioteek libsk-libfido2.so spesifiseer (uitvoer SSH_SK_PROVIDER=/path/to/libsk-libfido2.so ). Dit is moontlik om openssh te bou met ingeboude ondersteuning vir die tussenlaagbiblioteek (--with-security-key-builtin), in welke geval jy die "SecurityKeyProvider=internal" parameter moet stel.
Vervolgens moet jy "ssh-keygen -t ecdsa-sk" laat loop of, as die sleutels reeds geskep en gekonfigureer is, koppel aan die bediener met "ssh". Wanneer ssh-keygen uitgevoer word, sal die gegenereerde sleutelpaar in "~/.ssh/id_ecdsa_sk" gestoor word en kan dit op dieselfde manier as ander sleutels gebruik word.
Die publieke sleutel (id_ecdsa_sk.pub) moet na die bediener in die authorized_keys-lêer gekopieer word. Aan die bedienerkant word slegs die digitale handtekening nagegaan, en interaksie met tokens word aan die kliëntkant gedoen (libsk-libfido2 hoef nie op die bediener geïnstalleer te word nie, maar die bediener moet die "ecdsa-sk" sleuteltipe ondersteun) . Die gegenereerde private sleutel (id_ecdsa_sk) is in wese 'n sleutelbeskrywer wat slegs 'n regte sleutel vorm in kombinasie met die geheime volgorde wat aan die kant van die U2F-token gestoor is. As die id_ecdsa_sk-sleutel in die hande van 'n aanvaller val, sal hy ook toegang tot 'n hardeware-token moet kry om stawing deur te gee, waarsonder die private sleutel wat in die id_ecdsa_sk-lêer gestoor is nutteloos is.
Daarbenewens, by verstek, wanneer enige bewerkings met sleutels uitgevoer word (beide tydens generering en tydens stawing), word plaaslike bevestiging van die gebruiker se fisiese teenwoordigheid vereis, byvoorbeeld, word voorgestel om die sensor op die teken aan te raak, wat dit moeilik maak om voer afstandaanvalle uit op stelsels met 'n gekoppelde teken. As 'n ander verdedigingslinie, kan die ssh-keygen-opstartstap ook 'n wagwoord gegee word om toegang tot die sleutellêer te kry.
Die nuwe weergawe van OpenSSH het ook die komende afskaffing van algoritmes aangekondig wat SHA-1 hashes gebruik a.g.v. die doeltreffendheid van botsingsaanvalle met 'n gegewe voorvoegsel (die koste van die keuse van 'n botsing word op ongeveer 45 duisend dollar geraam). In een van die komende vrystellings beplan hulle om by verstek die vermoë om die ssh-rsa publieke sleutel digitale handtekeningalgoritme te gebruik, wat in die oorspronklike RFC vir die SSH-protokol genoem word en wydverspreid in die praktyk bly (om die gebruik van ssh na te gaan) deaktiveer -rsa in jou stelsels, kan jy probeer om via ssh te koppel met "-oHostKeyAlgorithms=-ssh-rsa" opsie).
Om die oorgang na nuwe algoritmes in OpenSSH glad te maak, in een van die volgende vrystellings, sal die UpdateHostKeys-instelling by verstek geaktiveer word, wat kliënte outomaties na meer betroubare algoritmes sal migreer. Aanbevole algoritmes vir migrasie sluit in rsa-sha2-256/512 gebaseer op RFC8332 RSA SHA-2 (ondersteun sedert OpenSSH 7.2 en word by verstek gebruik), ssh-ed25519 (ondersteun sedert OpenSSH 6.5) en ecdsa-sha2-nistp256/384 gebaseer op RFC521 ECDSA (ondersteun sedert OpenSSH 5656).
In OpenSSH 8.2 is die vermoë om met "ssh-rsa" te koppel steeds beskikbaar, maar hierdie algoritme is verwyder van die CASignatureAlgorithms-lys, wat die algoritmes definieer wat toegelaat word om nuwe sertifikate digitaal te onderteken. Net so is die diffie-hellman-group14-sha1-algoritme verwyder van die versteksleuteluitruilalgoritmes. Daar word kennis geneem dat die gebruik van SHA-1 in sertifikate met addisionele risiko geassosieer word, aangesien die aanvaller onbeperkte tyd het om na 'n botsing vir 'n bestaande sertifikaat te soek, terwyl die aanvaltyd op gasheersleutels beperk word deur die verbinding-time-out (LoginGraceTime) .
ssh-keygen is nou verstek na die rsa-sha2-512-algoritme wat sedert OpenSSH 7.2 ondersteun word, wat versoenbaarheidskwessies kan skep wanneer probeer word om OpenSSH 8.2-getekende sertifikate te verwerk op stelsels met ouer vrystellings van OpenSSH (om te werk te gaan wanneer ondertekening uitdruklik gespesifiseer kan word "ssh" -keygen -t ssh-rsa" of gebruik die ecdsa-sha2-nistp256/384/521 algoritmes wat sedert OpenSSH 5.7 ondersteun word).
Ander veranderinge:
- Die Insluit-instruksie is by sshd_config gevoeg, wat jou toelaat om die inhoud van ander lêers in die huidige posisie van die konfigurasielêer in te sluit (globmaskers word toegelaat wanneer 'n lêernaam gespesifiseer word);
- Bygevoeg "no-touch-required" opsie by ssh-keygen, wat die behoefte om fisies toegang tot die token te bevestig wanneer 'n sleutel gegenereer word, deaktiveer;
- Bygevoeg PubkeyAuthOptions-aanwysing by sshd_config om verskeie opsies wat verband hou met publieke sleutel-verifikasie te kombineer. Tans word slegs die "no-touch-required"-vlag ondersteun om die fisiese teenwoordigheidkontrole oor te slaan wanneer met 'n token gemagtig word. Na analogie is die "no-touch-required"-opsie by die authorized_keys-lêer gevoeg;
- Bygevoeg "-O write-attestation=/path" opsie by ssh-keygen om bykomende FIDO attestasie sertifikate te skryf wanneer sleutels gegenereer word. OpenSSH gebruik nog nie hierdie sertifikate nie, maar hulle kan later gebruik word om te verifieer dat die sleutel in 'n betroubare hardewarewinkel geplaas is;
- In die instellings van ssh en sshd deur die IPQoS-richtlijn, is dit nou moontlik om die verkeersprioritiseringsmodus in te stel (Laer-poging per-hop-gedrag);
- In ssh, wanneer die waarde "AddKeysToAgent=yes" gestel word, as die sleutel nie 'n veld met 'n opmerking bevat nie, sal dit by ssh-agent gevoeg word met die pad na die sleutel as 'n opmerking. IN
ssh-keygen en ssh-agent gebruik ook nou PKCS#11-merkers en 'n X.509-vaknaam in plaas van 'n biblioteekpad as kommentaar in die sleutel; - Bygevoeg die vermoë om PEM uit te voer vir DSA en ECDSA sleutels na ssh-keygen;
- Bygevoeg 'n nuwe uitvoerbare ssh-sk-helper wat gebruik word om die FIDO/U2F token toegang biblioteek te isoleer;
- Bygevoeg "--met-zlib" bou opsie by ssh en sshd om saam te stel met zlib biblioteek ondersteuning;
- In ooreenstemming met die vereiste van RFC4253, word die banier wat tydens verbinding vertoon word, voorsien van 'n waarskuwing oor die blokkering van toegang as gevolg van die oorskryding van die MaxStartups-limiete. Om diagnostiek te vereenvoudig, vertoon die sshd-prosesopskrif, sigbaar wanneer die ps-hulpprogram gebruik word, die aantal tans geverifieerde verbindings en die toestand van die MaxStartups-limiet;
- In ssh en ssh-agent, wanneer 'n program geroep word om 'n promptstel via $SSH_ASKPASS te vertoon, word 'n vlag met die prompttipe nou addisioneel versend: "bevestig" - bevestigingsdialoog (ja / nee), "geen" - inligtingsboodskap, "leeg" - wagwoordversoek;
- Het 'n nuwe digitale handtekeningbewerking "find-principals" by ssh-keygen gevoeg om die toegelate ondertekenaars-lêer te soek vir die gebruiker wat met die gespesifiseerde digitale handtekening geassosieer word;
- Verbeterde ondersteuning vir die isolering van die sshd-proses op Linux met behulp van die seccomp-meganisme: deaktiveer IPC-stelseloproepe, laat clock_gettime64(), clock_nanosleep_time64 en clock_nanosleep() toe.
Bron: opennet.ru