{"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\/de\/blog\/reliz-openssh-8-2-c-podderzhkoj-tokenov-dvuhfaktornoj-autentifikaczii-fido-u2f","title":{"rendered":"Release von OpenSSH 8.2 mit Unterst\u00fctzung f\u00fcr FIDO\/U2F Zwei-Faktor-Authentifizierungstokens.","gt_translate_keys":[{"key":"rendered","format":"text"}]},"content":{"rendered":"

Nach viermonatiger Entwicklung vorgestellt<\/a><\/noindex> Release OpenSSH 8.2<\/a><\/noindex>, einer offenen Implementierung von Client und Server f\u00fcr die Protokolle SSH 2.0 und SFTP. <\/p>\n

Ein wesentlicher Fortschritt in der Ver\u00f6ffentlichung von OpenSSH 8.2 ist die M\u00f6glichkeit, die Zwei-Faktor-Authentifizierung mithilfe von Ger\u00e4ten zu nutzen, die das Protokoll U2F<\/a><\/noindex>, entwickelt von der Allianz FIDO<\/a><\/noindex>. U2F erm\u00f6glicht die Erstellung kosteng\u00fcnstiger Hardware-Tokens zur Best\u00e4tigung der physischen Pr\u00e4senz des Benutzers, die \u00fcber USB, Bluetooth oder NFC interagieren. Solche Ger\u00e4te werden als Mittel zur Zwei-Faktor-Authentifizierung auf Webseiten gef\u00f6rdert, werden bereits von den g\u00e4ngigsten Browsern unterst\u00fctzt und von verschiedenen Herstellern wie Yubico, Feitian, Thetis und Kensington angeboten.<\/p>\n

Um mit Ger\u00e4ten zu interagieren, die die Anwesenheit des Benutzers best\u00e4tigen, wurden in OpenSSH neue Schl\u00fcsseltypen \u201eecdsa-sk\u201c und \u201eed25519-sk\u201c eingef\u00fchrt, die die digitalen Signaturalgorithmen ECDSA und Ed25519 in Kombination mit dem SHA-256-Hash verwenden. Die Interaktionsprozeduren mit den Token wurden in eine Zwischenspeicherbibliothek ausgelagert, die analog zur Bibliothek f\u00fcr die Unterst\u00fctzung von PKCS#11 geladen wird und eine Wrapper-\u00dcberbibliothek ist. libfido2<\/a><\/noindex>, die Mittel zur Kommunikation mit Tokens \u00fcber USB bereitstellt (unterst\u00fctzt die Protokolle FIDO U2F\/CTAP 1 und FIDO 2.0\/CTAP 2). Die von den Entwicklern von OpenSSH vorbereitete Zwischenbibliothek libsk-libfido2 eingeschlossen<\/a><\/noindex> ist Teil von libfido2, ebenso wie HID-Treiber<\/a><\/noindex> f\u00fcr OpenBSD.<\/p>\n

F\u00fcr die Authentifizierung und Generierung des Schl\u00fcssels muss die Einstellung \u201eSecurityKeyProvider\u201c oder die Umgebungsvariable SSH_SK_PROVIDER festgelegt werden, um den Pfad zur externen Bibliothek libsk-libfido2.so anzugeben (export SSH_SK_PROVIDER=\/path\/to\/libsk-libfido2.so). Es ist m\u00f6glich, OpenSSH mit integrierter Unterst\u00fctzung f\u00fcr die Zwischenschichtbibliothek zu kompilieren (\u2014with-security-key-builtin); in diesem Fall muss der Parameter \u201eSecurityKeyProvider=internal\u201c gesetzt werden.
\nAnschlie\u00dfend muss \u201essh-keygen -t ecdsa-sk\u201c ausgef\u00fchrt werden oder, falls die Schl\u00fcssel bereits erstellt und konfiguriert sind, muss eine Verbindung zum Server mit \u201essh\u201c hergestellt werden. Bei der Ausf\u00fchrung von ssh-keygen wird das erstellte Schl\u00fcsselpaar in \u201e~\/.ssh\/id_ecdsa_sk\u201c gespeichert und kann wie andere Schl\u00fcssel verwendet werden. <\/p>\n

Der \u00f6ffentliche Schl\u00fcssel (id_ecdsa_sk.pub) sollte auf den Server in die Datei authorized_keys kopiert werden. Auf der Serverseite wird nur die digitale Signatur \u00fcberpr\u00fcft, w\u00e4hrend die Interaktion mit den Token auf der Clientseite erfolgt (es ist nicht notwendig, libsk-libfido2 auf dem Server zu installieren, aber der Server muss den Schl\u00fcsseltyp \u201eecdsa-sk\u201c unterst\u00fctzen). Der generierte private Schl\u00fcssel (id_ecdsa_sk) ist im Wesentlichen ein Schl\u00fcsselhalter, der den tats\u00e4chlichen Schl\u00fcssel nur in Kombination mit der geheimen Sequenz bildet, die auf dem U2F-Token gespeichert ist. Wenn der Schl\u00fcssel id_ecdsa_sk in die H\u00e4nde eines Angreifers gelangt, ben\u00f6tigt er auch Zugriff auf das Hardware-Token, ohne das der gespeicherte private Schl\u00fcssel in der Datei id_ecdsa_sk nutzlos ist. <\/p>\n

Dar\u00fcber hinaus ist standardm\u00e4\u00dfig bei der Ausf\u00fchrung von Schl\u00fcsseloperationen (sowohl bei der Generierung als auch bei der Authentifizierung) eine lokale Best\u00e4tigung der physischen Anwesenheit des Benutzers erforderlich, beispielsweise indem der Benutzer aufgefordert wird, den Sensor des Tokens zu ber\u00fchren, was die Durchf\u00fchrung von Remote-Angriffen auf Systeme mit angeschlossenem Token erschwert. Zudem kann w\u00e4hrend des Starts von ssh-keygen ein Passwort f\u00fcr den Zugriff auf die Schl\u00fcsseldatei festgelegt werden. <\/p>\n

In der neuen Version von OpenSSH wurde auch die bevorstehende Einstufung von Algorithmen, die SHA-1-Hashes verwenden, als veraltet angek\u00fcndigt, in Bezug auf einer Erh\u00f6hung<\/a><\/noindex> die Effektivit\u00e4t von Kollisionsangriffen mit einem vorgegebenen Pr\u00e4fix (die Kosten f\u00fcr die Suche nach einer Kollision werden auf etwa 45.000 Dollar gesch\u00e4tzt). In einer der n\u00e4chsten Versionen ist geplant, die Verwendung des Public-Key-Signaturalgorithmus \u201essh-rsa\u201c standardm\u00e4\u00dfig zu deaktivieren, der im urspr\u00fcnglichen RFC f\u00fcr das SSH-Protokoll erw\u00e4hnt wird und weiterhin weit verbreitet ist (um die Verwendung von ssh-rsa in seinen Systemen zu \u00fcberpr\u00fcfen, kann man versuchen, sich \u00fcber ssh mit der Option \u201e-oHostKeyAlgorithms=-ssh-rsa\u201c zu verbinden).<\/p>\n

Um den \u00dcbergang zu neuen Algorithmen in OpenSSH zu erleichtern, wird in einer der n\u00e4chsten Versionen standardm\u00e4\u00dfig die Einstellung UpdateHostKeys aktiviert, die es erm\u00f6glicht, Clients automatisch auf sicherere Algorithmen umzustellen. Zu den empfohlenen Algorithmen f\u00fcr die Migration z\u00e4hlen rsa-sha2-256\/512 basierend auf RFC8332 RSA SHA-2 (unterst\u00fctzt seit OpenSSH 7.2 und standardm\u00e4\u00dfig verwendet), ssh-ed25519 (unterst\u00fctzt seit OpenSSH 6.5) und ecdsa-sha2-nistp256\/384\/521 basierend auf RFC5656 ECDSA (unterst\u00fctzt seit OpenSSH 5.7).<\/p>\n

In der Version OpenSSH 8.2 wurde die M\u00f6glichkeit der Verbindung mit \u201essh-rsa\u201c vorerst beibehalten, aber dieser Algorithmus wurde aus der Liste der CASignatureAlgorithms entfernt, die die Algorithmen definieren, die f\u00fcr die digitale Signatur neuer Zertifikate zul\u00e4ssig sind. \u00c4hnlich wurde der Algorithmus diffie-hellman-group14-sha1 aus den standardm\u00e4\u00dfig unterst\u00fctzten Schl\u00fcssel-Austausch-Algorithmen entfernt. Es wird darauf hingewiesen, dass die Verwendung von SHA-1 in Zertifikaten mit zus\u00e4tzlichen Risiken verbunden ist, da ein Angreifer unbegrenzte Zeit hat, um eine Kollision f\u00fcr ein bestehendes Zertifikat zu suchen, w\u00e4hrend die Zeit f\u00fcr einen Angriff auf Host-Schl\u00fcssel durch die Verbindungszeit\u00fcberschreitung (LoginGraceTime) begrenzt ist. <\/p>\n

Beim Ausf\u00fchren von ssh-keygen wird nun standardm\u00e4\u00dfig der Algorithmus rsa-sha2-512 verwendet, der seit OpenSSH 7.2 unterst\u00fctzt wird, was zu Kompatibilit\u00e4tsproblemen f\u00fchren kann, wenn versucht wird, Zertifikate, die in OpenSSH 8.2 signiert wurden, auf Systemen mit \u00e4lteren Versionen von OpenSSH zu verarbeiten (um das Problem beim Signieren zu umgehen, kann man explizit \u201essh-keygen -t ssh-rsa\u201c angeben oder die Algorithmen ecdsa-sha2-nistp256\/384\/521 verwenden, die seit OpenSSH 5.7 unterst\u00fctzt werden).<\/p>\n

Weitere \u00c4nderungen:<\/p>\n