{"id":42941,"date":"2020-02-17T14:41:56","date_gmt":"2020-02-17T11:41:56","guid":{"rendered":"https:\/\/prohoster.info\/blog\/blog_prohoster\/reliz-openssh-8-2-c-podderzhkoj-tokenov-dvuhfaktornoj-autentifikaczii-fido-u2f"},"modified":"2020-02-17T14:41:56","modified_gmt":"2020-02-17T11:41:56","slug":"reliz-openssh-8-2-c-podderzhkoj-tokenov-dvuhfaktornoj-autentifikaczii-fido-u2f","status":"publish","type":"post","link":"https:\/\/prohoster.info\/nl\/blog\/reliz-openssh-8-2-c-podderzhkoj-tokenov-dvuhfaktornoj-autentifikaczii-fido-u2f","title":{"rendered":"Release van OpenSSH 8.2 met ondersteuning voor FIDO\/U2F two-factor authenticatietokens","gt_translate_keys":[{"key":"rendered","format":"text"}]},"content":{"rendered":"

Na vier maanden ontwikkeling is gepresenteerd<\/a><\/noindex> release OpenSSH 8.2<\/a><\/noindex>, een open implementatie van een client en server voor communicatie via de SSH 2.0- en SFTP-protocollen. <\/p>\n

Een belangrijke verbetering in de release van OpenSSH 8.2 is de mogelijkheid om two-factor authenticatie te gebruiken met apparaten die het protocol ondersteunen U2F<\/a><\/noindex>, ontwikkeld door de alliantie FIDO<\/a><\/noindex>. U2F maakt het mogelijk om goedkope hardwaretokens te cre\u00ebren voor het bevestigen van fysieke aanwezigheid van de gebruiker, waarbij interactie plaatsvindt via USB, Bluetooth of NFC. Dergelijke apparaten worden gepromoot als een middel voor tweefactorauthenticatie op sites, worden al ondersteund door de belangrijkste browsers en worden geproduceerd door verschillende fabrikanten, waaronder Yubico, Feitian, Thetis en Kensington.<\/p>\n

Om te interageren met apparaten die de aanwezigheid van de gebruiker bevestigen, zijn in OpenSSH nieuwe types sleutels toegevoegd: \"ecdsa-sk\" en \"ed25519-sk\", die gebruik maken van de digitale handtekenalgoritmes ECDSA en Ed25519 in combinatie met de hash SHA-256. De procedures voor interactie met tokens zijn verplaatst naar een tussenliggende bibliotheek, die wordt geladen op dezelfde manier als de bibliotheek ter ondersteuning van PKCS#11 en dient als een koppeling naar de bibliotheek. libfido2<\/a><\/noindex>, die middelen biedt voor communicatie met tokens via USB (de protocollen FIDO U2F\/CTAP 1 en FIDO 2.0\/CTAP 2 worden ondersteund). De tussenbibliotheek libsk-libfido2, ontwikkeld door de ontwikkelaars van OpenSSH, is ge\u00efntegreerd in de hoofdbibliotheek libfido2, net zoals is ingeschakeld<\/a><\/noindex> de HID-driver voor OpenBSD.<\/a><\/noindex> Om U2F in te schakelen, kan een recente snapshot van de codebase worden gebruikt uit<\/p>\n

Voor authenticatie en sleutelgeneratie moet in de instellingen de parameter \"SecurityKeyProvider\" worden opgegeven of de omgevingsvariabele SSH_SK_PROVIDER worden ingesteld, met het pad naar de externe bibliotheek libsk-libfido2.so (export SSH_SK_PROVIDER=\/path\/to\/libsk-libfido2.so). Het is mogelijk om openssh te bouwen met ingebouwde ondersteuning voor de tussenbibliotheek (-with-security-key-builtin); in dat geval moet de parameter \"SecurityKeyProvider=internal\" worden ingesteld.
\nVervolgens moet je \"ssh-keygen -t ecdsa-sk\" uitvoeren of, als de sleutels al zijn aangemaakt en geconfigureerd, verbinding maken met de server via \"ssh\". Bij het uitvoeren van ssh-keygen wordt het aangemaakte sleutelpaar opgeslagen in \"~\/.ssh\/id_ecdsa_sk\" en kan het net als andere sleutels worden gebruikt. <\/p>\n

De openbare sleutel (id_ecdsa_sk.pub) moet op de server worden gekopieerd naar het bestand authorized_keys. Aan de serverzijde wordt alleen de digitale handtekening gecontroleerd, terwijl de interactie met tokens aan de cli\u00ebntzijde plaatsvindt (op de server hoeft libsk-libfido2 niet te worden ge\u00efnstalleerd, maar de server moet het type sleutel \"ecdsa-sk\" ondersteunen). De gegenereerde priv\u00e9sleutel (id_ecdsa_sk) is in wezen een descriptor van de sleutel, die de werkelijke sleutel pas vormt in combinatie met de geheime reeks die op de U2F-token wordt opgeslagen. In het geval dat de sleutel id_ecdsa_sk in handen van een aanvaller valt, heeft hij ook toegang nodig tot de hardwaretoken om de authenticatie te doorlopen, zonder welke de in het bestand id_ecdsa_sk opgeslagen priv\u00e9sleutel nutteloos is. <\/p>\n

Daarnaast is het standaard vereist dat een lokale bevestiging van de fysieke aanwezigheid van de gebruiker plaatsvindt bij het uitvoeren van enige sleuteloperaties (zoals generatie en authenticatie), bijvoorbeeld door te vragen om een sensor op de token aan te raken, wat het moeilijker maakt om op afstand aanvallen uit te voeren op systemen met een aangesloten token. Als een extra beveiligingsmaatregel kan ook een wachtwoord voor toegang tot het sleutelbestand worden ingesteld tijdens het opstarten van ssh-keygen. <\/p>\n

In de nieuwe versie van OpenSSH is ook aangekondigd dat er binnenkort algoritmes die gebruikmaken van SHA-1-hashes als verouderd zullen worden geclassificeerd, vanwege de toename<\/a><\/noindex> effectiviteit van collision attacks with a given prefix (the cost of finding a collision is estimated at around 45 thousand dollars). In one of the upcoming releases, the ability to use the public key signature algorithm \u2018ssh-rsa\u2019 will be disabled by default, which is mentioned in the original RFC for the SSH protocol and remains widely used in practice (to check for the implementation of ssh-rsa in your systems, you can try to connect via ssh with the option \u2018-oHostKeyAlgorithms=-ssh-rsa\u2019).<\/p>\n

Om de overgang naar nieuwe algoritmes in OpenSSH te vergemakkelijken, zal in een van de volgende versies standaard de instelling UpdateHostKeys worden ingeschakeld, die klanten automatisch naar betrouwbaardere algoritmes zal overzetten. Onder de aanbevolen algoritmes voor migratie worden rsa-sha2-256\/512 op basis van 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 op basis van RFC5656 ECDSA (ondersteund sinds OpenSSH 5.7) vermeld.<\/p>\n

In OpenSSH 8.2 blijft de mogelijkheid om verbinding te maken met behulp van «ssh-rsa» voorlopig behouden, maar dit algoritme is verwijderd uit de lijst van CASignatureAlgorithms, die de algoritmen definieert die zijn toegestaan voor de digitale handtekening van nieuwe certificaten. Evenzo is het algoritme diffie-hellman-group14-sha1 verwijderd uit de standaardondersteunde algoritmen voor sleuteluitwisseling. Het wordt opgemerkt dat het gebruik van SHA-1 in certificaten gepaard gaat met extra risico, aangezien een aanvaller onbeperkte tijd heeft om een botsing te zoeken voor een bestaand certificaat, terwijl de tijd voor aanvallen op hostsleutels beperkt is door de verbindings timeout (LoginGraceTime). <\/p>\n

Bij het uitvoeren van ssh-keygen wordt nu standaard het algoritme rsa-sha2-512 toegepast, dat wordt ondersteund sinds OpenSSH 7.2, wat compatibiliteitsproblemen kan veroorzaken bij het proberen te verwerken van certificaten die zijn ondertekend in OpenSSH 8.2 op systemen met oudere versies van OpenSSH (om dit probleem te omzeilen bij het genereren van de handtekening kan «ssh-keygen -t ssh-rsa» expliciet worden opgegeven of de algoritmen ecdsa-sha2-nistp256\/384\/521 worden gebruikt, die worden ondersteund sinds OpenSSH 5.7).<\/p>\n

Andere wijzigingen:<\/p>\n