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 OpenSSH 8.2-release is 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 kunnen communiceren met apparaten die de aanwezigheid van de gebruiker bevestigen, heeft OpenSSH de nieuwe sleuteltypen 'ecdsa-sk' en 'ed25519-sk' toegevoegd. Deze gebruiken de digitale handtekeningalgoritmen ECDSA en Ed25519 in combinatie met de SHA-256-hash. De procedures voor de interactie met tokens zijn verplaatst naar een tussenliggende bibliotheek. Deze wordt op dezelfde manier geladen als de bibliotheek voor de ondersteuning van PKCS#11 en vormt een wrapper rond de bibliotheek. , 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 te authenticeren en een sleutel te genereren, moet u de parameter "SecurityKeyProvider" opgeven in de instellingen of de omgevingsvariabele SSH_SK_PROVIDER instellen, waarbij u het pad naar de externe bibliotheek libsk-libfido2.so opgeeft (export SSH_SK_PROVIDER=/pad/naar/libsk-libfido2.so). Het is mogelijk om openssh te bouwen met ingebouwde ondersteuning voor de intermediaire bibliotheek (—with-security-key-builtin). In dit geval is het nodig om de parameter “SecurityKeyProvider=internal” in te stellen.
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 net als andere sleutels worden gebruikt.
De openbare sleutel (id_ecdsa_sk.pub) moet naar de server worden gekopieerd in het bestand authorized_keys. Aan de serverzijde wordt alleen de digitale handtekening gecontroleerd en aan de clientzijde vindt de interactie met tokens plaats (de server hoeft libsk-libfido2 niet te installeren, maar de server moet wel het sleuteltype "ecdsa-sk" ondersteunen). De gegenereerde persoonlijke sleutel (id_ecdsa_sk) is in wezen een sleuteldescriptor die alleen een echte sleutel vormt wanneer deze wordt gecombineerd met de geheime sequentie die is opgeslagen aan de U2F-tokenzijde. Als de sleutel id_ecdsa_sk in handen valt van een aanvaller, heeft deze voor de authenticatie ook toegang nodig tot een hardwaretoken. Zonder deze hardwaretoken is de persoonlijke sleutel die is opgeslagen in het bestand id_ecdsa_sk nutteloos.
Bovendien vereisen alle belangrijke handelingen (zowel generatie als authenticatie) standaard een lokale bevestiging van de fysieke aanwezigheid van de gebruiker, zoals het aanraken van een sensor op een token. Dit maakt het lastig om op afstand aanvallen uit te voeren op systemen met een verbonden token. Als extra verdedigingslinie kan er ook bij het opstarten van ssh-keygen een wachtwoord voor toegang tot het sleutelbestand worden opgegeven.
De nieuwe versie van OpenSSH kondigde ook de aanstaande veroudering 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 soepel te laten verlopen, zal OpenSSH in een toekomstige release de instelling UpdateHostKeys standaard inschakelen. Hierdoor worden clients automatisch gemigreerd naar veiligere algoritmen. 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 het nog steeds mogelijk om verbinding te maken via "ssh-rsa", maar dit algoritme is verwijderd uit de lijst CASignatureAlgorithms. Deze lijst definieert de toegestane algoritmen voor het digitaal ondertekenen van nieuwe certificaten. Tevens is het diffie-hellman-group14-sha1-algoritme verwijderd uit de standaard ondersteunde sleuteluitwisselingsalgoritmen. Er wordt opgemerkt dat het gebruik van SHA-1 in certificaten gepaard gaat met extra risico's, aangezien de aanvaller onbeperkt de tijd heeft om een botsing voor een bestaand certificaat te vinden, terwijl de aanvalstijd op hostsleutels wordt beperkt door de verbindingstime-out (LoginGraceTime).
Bij het uitvoeren van ssh-keygen wordt nu standaard het algoritme rsa-sha2-512 gebruikt. Dit algoritme wordt ondersteund sinds OpenSSH 7.2. Hierdoor kunnen er compatibiliteitsproblemen ontstaan bij het verwerken van met OpenSSH 8.2 ondertekende certificaten op systemen met oudere versies van OpenSSH (u kunt dit probleem omzeilen door expliciet "ssh-keygen -t ssh-rsa" op te geven bij het genereren van de handtekening, of door de algoritmen ecdsa-sha2-nistp256/384/521 te gebruiken, die worden ondersteund sinds OpenSSH 5.7).
Andere wijzigingen:
- De Include-richtlijn is toegevoegd aan sshd_config, waardoor de inhoud van andere bestanden kan worden opgenomen in de huidige positie van het configuratiebestand (glob-maskers kunnen worden gebruikt bij het opgeven van de bestandsnaam).
- De optie 'no-touch-required' is toegevoegd aan ssh-keygen, waardoor er geen fysieke bevestiging van toegang tot het token meer nodig is bij het genereren van een sleutel;
- Er is een PubkeyAuthOptions-richtlijn toegevoegd aan sshd_config om verschillende opties met betrekking tot openbare sleutelauthenticatie te groeperen. Momenteel wordt alleen de vlag 'geen aanraking vereist' ondersteund. Hiermee wordt de fysieke aanwezigheidscontrole overgeslagen bij autorisatie met een token. Analoog hieraan is de optie “geen-aanraking-vereist” toegevoegd aan het bestand authorized_keys;
- Optie "-O write-attestation=/path" toegevoegd aan ssh-keygen om het schrijven van extra FIDO-attestatiecertificaten mogelijk te maken tijdens het genereren van sleutels. OpenSSH maakt momenteel geen gebruik van deze certificaten, maar ze kunnen in de toekomst worden gebruikt om te verifiëren of de sleutel is opgeslagen in een vertrouwde hardwareopslag;
- In ssh- en sshd-instellingen is het nu mogelijk om de verkeersprioriteringsmodus in te stellen via de IPQoS-richtlijn (Gedrag met lagere inspanning per sprong);
- In ssh wordt bij het instellen van "AddKeysToAgent=yes" een sleutel die geen opmerkingenveld bevat, toegevoegd aan ssh-agent, waarbij het pad naar de sleutel wordt opgegeven als een opmerking. IN
ssh-keygen en ssh-agent gebruiken nu ook PKCS#11-labels en X.509-onderwerpnaam als opmerkingen in de sleutel in plaats van het bibliotheekpad; - Mogelijkheid toegevoegd om PEM voor DSA- en ECDSA-sleutels te exporteren naar ssh-keygen;
- Nieuw uitvoerbaar bestand toegevoegd: ssh-sk-helper, gebruikt om de FIDO/U2F-tokentoegangsbibliotheek te isoleren;
- De bouwoptie "--with-zlib" is toegevoegd aan ssh en sshd om te compileren met ondersteuning voor de zlib-bibliotheek;
- In overeenstemming met RFC4253 bevat de banner die wordt weergegeven bij het maken van verbinding nu een waarschuwing over een toegang die wordt geblokkeerd vanwege overschrijding van de MaxStartups-limieten. Om de diagnose te vereenvoudigen, worden in de header van het sshd-proces, die zichtbaar is bij gebruik van het hulpprogramma ps, nu het aantal momenteel geauthenticeerde verbindingen en de MaxStartups-limietstatus weergegeven;
- In ssh en ssh-agent wordt bij het aanroepen van een programma om een prompt op het scherm weer te geven, opgegeven via $SSH_ASKPASS, nu ook een vlag met het prompttype doorgegeven: "confirm" - bevestigingsdialoog (ja/nee), "none" - informatief bericht, "blank" - wachtwoordverzoek;
- Er is een nieuwe digitale handtekeningbewerking "find-principals" toegevoegd aan ssh-keygen om in het bestand allowed-signers te zoeken naar de gebruiker die is gekoppeld aan de opgegeven digitale handtekening;
- Улучшена поддержка изоляции процесса sshd в Linux при помощи механизма seccomp: запрещены системные вызовы IPC, разрешены clock_gettime64(), clock_nanosleep_time64 и clock_nanosleep().
Bron: opennet.ru
