{"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 vier Monaten Entwicklung wurde vorgestellt<\/a><\/noindex> Release OpenSSH 8.2<\/a><\/noindex>, einer Open-Source-Implementierung von Client und Server f\u00fcr die Protokolle SSH 2.0 und SFTP. <\/p>\n

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

F\u00fcr die Interaktion mit Ger\u00e4ten, die die Anwesenheit des Benutzers best\u00e4tigen, wurden in OpenSSH neue Schl\u00fcsseltypen \u201eecdsa-sk\u201c und \u201eed25519-sk\u201c eingef\u00fchrt, die die ECDSA- und Ed25519-Digital-Signaturalgorithmen in Kombination mit dem SHA-256-Hash verwenden. Die Interaktionsprozeduren mit den Tokens wurden in eine Zwischenbibliothek ausgelagert, die analog zur Bibliothek zur Unterst\u00fctzung von PKCS#11 geladen wird und eine Wrapper-Funktion \u00fcber die Bibliothek darstellt. 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 OpenSSH-Entwicklern bereitgestellte Zwischenbibliothek libsk-libfido2 wurde hinzugef\u00fcgt<\/a><\/noindex> wird in die Hauptbibliothek libfido2 integriert, ebenso wie HID-Treiber<\/a><\/noindex> f\u00fcr OpenBSD.<\/p>\n

F\u00fcr die Authentifizierung und Generierung des Schl\u00fcssels muss in den Einstellungen der Parameter \u201eSecurityKeyProvider\u201c angegeben oder die Umgebungsvariable SSH_SK_PROVIDER gesetzt werden, indem der Pfad zur externen Bibliothek libsk-libfido2.so angegeben wird (export SSH_SK_PROVIDER=\/path\/to\/libsk-libfido2.so). Es ist m\u00f6glich, OpenSSH mit integrierter Unterst\u00fctzung f\u00fcr die Layer-Bibliothek 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 man sich mit \u201essh\u201c mit dem Server verbinden. Bei der Ausf\u00fchrung von ssh-keygen wird das generierte 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) muss auf dem Server in die Datei authorized_keys kopiert werden. Auf der Serverseite wird nur die digitale Signatur \u00fcberpr\u00fcft, w\u00e4hrend die Interaktion mit den Tokens auf der Clientseite erfolgt (auf dem Server ist es nicht erforderlich, libsk-libfido2 zu installieren, aber der Server muss den Schl\u00fcsseltotyp \u201eecdsa-sk\u201c unterst\u00fctzen). Der generierte private Schl\u00fcssel (id_ecdsa_sk) ist im Wesentlichen ein Descriptor des Schl\u00fcssels, der nur in Kombination mit der geheimen Sequenz, die auf dem U2F-Token gespeichert ist, einen echten Schl\u00fcssel bildet. Sollte der Schl\u00fcssel id_ecdsa_sk in die H\u00e4nde eines Angreifers gelangen, ben\u00f6tigt dieser f\u00fcr die Authentifizierung auch Zugriff auf das Hardware-Token, ohne das der im Datei id_ecdsa_sk gespeicherte private Schl\u00fcssel nutzlos ist. <\/p>\n

Dar\u00fcber hinaus ist es standardm\u00e4\u00dfig erforderlich, bei allen Schl\u00fcsseloperationen (sowohl bei der Generierung als auch bei der Authentifizierung) eine lokale Best\u00e4tigung der physischen Anwesenheit des Benutzers, zum Beispiel durch Ber\u00fchrung des Sensors am Token, was entfernte Angriffe auf Systeme mit angeschlossenem Token erschwert. Als zus\u00e4tzliche Schutzma\u00dfnahme kann bei der Ausf\u00fchrung von ssh-keygen auch ein Passwort f\u00fcr den Zugriff auf die Schl\u00fcsseldatei festgelegt werden. <\/p>\n

In der neuen Version von OpenSSH wurde zudem angek\u00fcndigt, dass die Algorithmen, die SHA-1-Hashes verwenden, bald als veraltet eingestuft werden, da der Steigerung<\/a><\/noindex> Die Effektivit\u00e4t von Kollisionangriffen mit einem bestimmten Pr\u00e4fix wird auf etwa 45.000 Dollar gesch\u00e4tzt. In einer der n\u00e4chsten Versionen planen die Entwickler, die Verwendung des digitalen Signaturalgorithmus mit \u00f6ffentlichem Schl\u00fcssel \u201essh-rsa\u201c standardm\u00e4\u00dfig zu deaktivieren, der im urspr\u00fcnglichen RFC f\u00fcr das SSH-Protokoll erw\u00e4hnt wird und nach wie vor weit verbreitet ist (um zu \u00fcberpr\u00fcfen, ob ssh-rsa in Ihren Systemen verwendet wird, k\u00f6nnen Sie versuchen, sich per 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 kommenden 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 geh\u00f6ren 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 bleibt die M\u00f6glichkeit der Verbindung mit \u201essh-rsa\u201c zun\u00e4chst erhalten, aber dieser Algorithmus wurde aus der Liste der CASignatureAlgorithms entfernt, die die f\u00fcr die digitale Signatur neuer Zertifikate zul\u00e4ssigen Algorithmen festlegt. Ebenso wurde der Algorithmus diffie-hellman-group14-sha1 aus den standardm\u00e4\u00dfig unterst\u00fctzten Schl\u00fcsselwechselalgorithmen 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 finden, w\u00e4hrend die Zeit f\u00fcr Angriffe auf die Hostschl\u00fcssel durch das Verbindungszeitlimit (LoginGraceTime) beschr\u00e4nkt ist. <\/p>\n

Bei der Ausf\u00fchrung von ssh-keygen wird nun standardm\u00e4\u00dfig der Algorithmus rsa-sha2-512 verwendet, der ab OpenSSH 7.2 unterst\u00fctzt wird. Dies kann zu Kompatibilit\u00e4tsproblemen f\u00fchren, wenn versucht wird, mit in OpenSSH 8.2 signierten Zertifikaten auf Systemen mit \u00e4lteren Versionen von OpenSSH umzugehen. Um das Problem beim Signieren zu umgehen, kann man ausdr\u00fccklich \u201essh-keygen -t ssh-rsa\u201c angeben oder die Algorithmen ecdsa-sha2-nistp256\/384\/521 verwenden, die ab OpenSSH 5.7 unterst\u00fctzt werden.<\/p>\n

Weitere \u00c4nderungen:<\/p>\n