Na vier maanden ontwikkeling релиз , een open client- en serverimplementatie voor het werken via de SSH 2.0- en SFTP-protocollen.
Een belangrijke verbetering in de release van OpenSSH 8.2 was de mogelijkheid om tweefactorauthenticatie te gebruiken met apparaten die het protocol ondersteunen , ontwikkeld door de alliantie . Met U2F kunnen goedkope hardwaretokens worden gemaakt om de fysieke aanwezigheid van de gebruiker te verifiëren en ermee te communiceren via USB, Bluetooth of NFC. Dergelijke apparaten worden gepromoot als middel voor tweefactorauthenticatie op websites, worden al ondersteund door grote browsers en worden geproduceerd door verschillende fabrikanten, waaronder Yubico, Feitian, Thetis en Kensington.
Om te communiceren met apparaten die de aanwezigheid van de gebruiker bevestigen, zijn nieuwe sleuteltypen “ecdsa-sk” en “ed25519-sk” toegevoegd aan OpenSSH, die de digitale handtekeningalgoritmen ECDSA en Ed25519 gebruiken, gecombineerd met de SHA-256-hash. Procedures voor interactie met tokens worden in een tussenliggende bibliotheek geplaatst, die op een vergelijkbare manier wordt geladen als de bibliotheek voor PKCS#11-ondersteuning en een wrapper bovenop de bibliotheek is , dat hulpmiddelen biedt voor communicatie met tokens via USB (FIDO U2F/CTAP 1- en FIDO 2.0/CTAP 2-protocollen worden ondersteund). Tussenliggende bibliotheek libsk-libfido2 opgesteld door OpenSSH-ontwikkelaars in de kern libfido2, evenals voor OpenBSD.
Om een sleutel te authenticeren en te genereren, moet u de parameter “SecurityKeyProvider” opgeven in de instellingen of de omgevingsvariabele SSH_SK_PROVIDER instellen, die het pad naar de externe bibliotheek libsk-libfido2.so aangeeft (exporteer SSH_SK_PROVIDER=/path/to/libsk-libfido2. Dus). Het is mogelijk om openssh te bouwen met ingebouwde ondersteuning voor de lagenbibliotheek (--with-security-key-builtin), in dit geval moet u de parameter “SecurityKeyProvider=internal” instellen.
Vervolgens moet u “ssh-keygen -t ecdsa-sk” uitvoeren of, als de sleutels al zijn aangemaakt en geconfigureerd, verbinding maken met de server via “ssh”. Wanneer u ssh-keygen uitvoert, wordt het gegenereerde sleutelpaar opgeslagen in “~/.ssh/id_ecdsa_sk” en kan het op dezelfde manier worden gebruikt als andere sleutels.
De openbare sleutel (id_ecdsa_sk.pub) moet naar de server worden gekopieerd in het bestand geautoriseerde_sleutels. Aan de serverzijde wordt alleen de digitale handtekening geverifieerd en wordt interactie met tokens uitgevoerd aan de clientzijde (u hoeft libsk-libfido2 niet op de server te installeren, maar de server moet het sleuteltype “ecdsa-sk” ondersteunen) . De gegenereerde privésleutel (id_ecdsa_sk) is in wezen een sleutelhandvat en vormt alleen een echte sleutel in combinatie met de geheime reeks die is opgeslagen aan de U2F-tokenzijde. Als de id_ecdsa_sk-sleutel in handen van een aanvaller valt, zal hij, om de authenticatie door te geven, ook toegang moeten krijgen tot het hardwaretoken, zonder welke de privésleutel die is opgeslagen in het id_ecdsa_sk-bestand nutteloos is.
Bovendien is bij het uitvoeren van handelingen met sleutels (zowel tijdens het genereren als tijdens authenticatie) standaard lokale bevestiging van de fysieke aanwezigheid van de gebruiker vereist. Er wordt bijvoorbeeld voorgesteld om de sensor op het token aan te raken, wat het moeilijk maakt om aanvallen op afstand uitvoeren op systemen met een aangesloten token. Als extra verdedigingslinie kan tijdens de opstartfase van ssh-keygen ook een wachtwoord worden opgegeven om toegang te krijgen tot het sleutelbestand.
De nieuwe versie van OpenSSH kondigde ook de aanstaande beëindiging aan van algoritmen die SHA-1-hashes gebruiken vanwege de effectiviteit van botsingsaanvallen met een bepaald voorvoegsel (de kosten voor het selecteren van een botsing worden geschat op ongeveer 45 duizend dollar). In een van de komende releases zijn ze van plan om standaard de mogelijkheid uit te schakelen om het algoritme voor digitale handtekeningen met openbare sleutels “ssh-rsa” te gebruiken, dat wordt genoemd in de oorspronkelijke RFC voor het SSH-protocol en in de praktijk wijdverbreid blijft (om het gebruik te testen van ssh-rsa in uw systemen, kunt u proberen verbinding te maken via ssh met de optie “-oHostKeyAlgorithms=-ssh-rsa”).
Om de overgang naar nieuwe algoritmen in OpenSSH te vergemakkelijken, zal in een toekomstige release de UpdateHostKeys-instelling standaard worden ingeschakeld, waardoor clients automatisch naar betrouwbaardere algoritmen worden gemigreerd. Aanbevolen algoritmen voor migratie zijn onder meer rsa-sha2-256/512 gebaseerd op RFC8332 RSA SHA-2 (ondersteund sinds OpenSSH 7.2 en standaard gebruikt), ssh-ed25519 (ondersteund sinds OpenSSH 6.5) en ecdsa-sha2-nistp256/384/521 gebaseerd op RFC5656 ECDSA (ondersteund sinds OpenSSH 5.7).
In OpenSSH 8.2 is de mogelijkheid om verbinding te maken via “ssh-rsa” nog steeds beschikbaar, maar dit algoritme is verwijderd uit de CASignatureAlgorithms-lijst, die de algoritmen definieert die zijn toegestaan voor het digitaal ondertekenen van nieuwe certificaten. Op dezelfde manier is het diffie-helman-group14-sha1-algoritme verwijderd uit de standaard ondersteunde sleuteluitwisselingsalgoritmen. Opgemerkt wordt dat het gebruik van SHA-1 in certificaten gepaard gaat met extra risico's, omdat de aanvaller onbeperkte tijd heeft om te zoeken naar een botsing voor een bestaand certificaat, terwijl de tijd van de aanval op hostsleutels wordt beperkt door de verbindingstime-out (LoginGraceTime ).
Het uitvoeren van ssh-keygen gebruikt nu standaard het rsa-sha2-512-algoritme, dat wordt ondersteund sinds OpenSSH 7.2, wat compatibiliteitsproblemen kan veroorzaken bij pogingen om certificaten ondertekend in OpenSSH 8.2 te verwerken op systemen met oudere OpenSSH-releases (om het probleem te omzeilen wanneer When Als u een handtekening wilt genereren, kunt u expliciet “ssh-keygen -t ssh-rsa” specificeren of de ecdsa-sha2-nistp256/384/521-algoritmen gebruiken, ondersteund sinds OpenSSH 5.7).
Andere wijzigingen:
- Er is een Include-richtlijn toegevoegd aan sshd_config, waarmee u de inhoud van andere bestanden op de huidige positie van het configuratiebestand kunt opnemen (glob-maskers kunnen worden gebruikt bij het opgeven van de bestandsnaam);
- De optie “no-touch-required” is toegevoegd aan ssh-keygen, waardoor het niet meer nodig is om de toegang tot het token fysiek te bevestigen bij het genereren van de sleutel;
- Er is een PubkeyAuthOptions-instructie toegevoegd aan sshd_config, die verschillende opties combineert met betrekking tot authenticatie met openbare sleutels. Momenteel wordt alleen de vlag 'geen aanraking vereist' ondersteund om fysieke aanwezigheidscontroles voor tokenauthenticatie over te slaan. Naar analogie is de optie “geen aanraking vereist” toegevoegd aan het bestand geautoriseerde_sleutels;
- Optie "-O write-attestation=/path" toegevoegd aan ssh-keygen om het mogelijk te maken dat extra FIDO-attestationcertificaten worden geschreven bij het genereren van sleutels. OpenSSH maakt nog geen gebruik van deze certificaten, maar ze kunnen later worden gebruikt om te verifiëren dat de sleutel in een vertrouwde hardware-opslag is geplaatst;
- In de ssh- en sshd-instellingen is het nu mogelijk om de verkeersprioriteringsmodus in te stellen via de IPQoS-richtlijn (Gedrag met lagere inspanning per hop);
- Als in ssh de waarde “AddKeysToAgent=yes” wordt ingesteld en de sleutel geen commentaarveld bevat, wordt deze toegevoegd aan ssh-agent, waarbij het pad naar de sleutel als commentaar wordt aangegeven. IN
ssh-keygen en ssh-agent gebruiken nu ook PKCS#11-labels en de X.509-onderwerpnaam in plaats van het bibliotheekpad als commentaar in de sleutel; - De mogelijkheid toegevoegd om PEM voor DSA- en ECDSA-sleutels naar ssh-keygen te exporteren;
- Een nieuw uitvoerbaar bestand toegevoegd, ssh-sk-helper, gebruikt om de FIDO/U2F tokentoegangsbibliotheek te isoleren;
- “--with-zlib” build-optie toegevoegd aan ssh en sshd voor compilatie met ondersteuning voor zlib-bibliotheken;
- In overeenstemming met de vereisten van RFC4253 wordt een waarschuwing over toegangsblokkering als gevolg van het overschrijden van de MaxStartups-limieten weergegeven in de banner die wordt weergegeven tijdens de verbinding. Om de diagnostiek te vereenvoudigen, geeft de sshd-procesheader, zichtbaar bij gebruik van het ps-hulpprogramma, nu het aantal momenteel geverifieerde verbindingen en de status van de MaxStartups-limiet weer;
- In ssh en ssh-agent wordt nu bij het oproepen van een programma om een uitnodiging op het scherm weer te geven, gespecificeerd via $SSH_ASKPASS, nu bovendien een vlag met het type uitnodiging verzonden: "bevestigen" - bevestigingsdialoog (ja/nee), "geen ” - informatief bericht, “leeg” – wachtwoordverzoek;
- Een nieuwe bewerking voor digitale handtekeningen "find-principals" toegevoegd aan ssh-keygen om in het bestand met toegestane ondertekenaars te zoeken naar de gebruiker die is gekoppeld aan een opgegeven digitale handtekening;
- Verbeterde ondersteuning voor sshd-procesisolatie op Linux met behulp van het seccomp-mechanisme: IPC-systeemaanroepen uitschakelen, clock_gettime64(), clock_nanosleep_time64 en clock_nanosleep() toestaan.
Bron: opennet.ru