Release von OpenSSH 8.2 mit Unterstützung für FIDO/U2F Zwei-Faktor-Authentifizierungstokens

Nach vier Monaten Entwicklung wurde vorgestellt Release OpenSSH 8.2, einer Open-Source-Implementierung von Client und Server für die Protokolle SSH 2.0 und SFTP.

Ein zentrales Verbesserungselement in der Veröffentlichung von OpenSSH 8.2 ist die Möglichkeit, Zwei-Faktor-Authentifizierung mithilfe von Geräten, die das Protokoll unterstützen, zu verwenden U2F, entwickelt von der Allianz FIDO. U2F ermöglicht die Erstellung kostengünstiger Hardware-Tokens zur Bestätigung der physischen Anwesenheit des Benutzers, die über USB, Bluetooth oder NFC kommuniziert werden. Solche Geräte werden als Mittel zur Zwei-Faktor-Authentifizierung auf Websites gefördert, werden bereits von den gängigen Browsern unterstützt und werden von verschiedenen Herstellern wie Yubico, Feitian, Thetis und Kensington angeboten.

Zur Interaktion mit Geräten, die die Anwesenheit des Benutzers bestätigen, hat OpenSSH neue Schlüsseltypen "ecdsa-sk" und "ed25519-sk" hinzugefügt, die ECDSA- und Ed25519-Signaturalgorithmen zusammen mit dem SHA-256-Hash verwenden. Die Interaktionsverfahren mit den Tokens wurden in eine Zwischenbibliothek ausgelagert, die analog zur Bibliothek zur Unterstützung von PKCS#11 geladen wird und eine Schnittstelle zur libfido2, die Mittel zur Kommunikation mit Tokens über USB bereitstellt (unterstützt die Protokolle FIDO U2F/CTAP 1 und FIDO 2.0/CTAP 2). Die von OpenSSH-Entwicklern bereitgestellte Zwischenbibliothek libsk-libfido2 wurde hinzugefügt wird in die Hauptbibliothek libfido2 integriert, ebenso wie HID-Treiber für OpenBSD.

Für die Authentifizierung und Generierung des Schlüssels ist es erforderlich, in den Einstellungen den Parameter „SecurityKeyProvider“ anzugeben oder die Umgebungsvariable SSH_SK_PROVIDER mit dem Pfad zur externen Bibliothek libsk-libfido2.so festzulegen (export SSH_SK_PROVIDER=/path/to/libsk-libfido2.so). Es ist auch möglich, OpenSSH mit integriertem Support für die Zwischenbibliothek zu bauen (—with-security-key-builtin), in diesem Fall muss der Parameter „SecurityKeyProvider=internal“ gesetzt werden.
Anschließend muss „ssh-keygen -t ecdsa-sk“ ausgeführt werden oder, wenn die Schlüssel bereits erstellt und konfiguriert sind, kann man sich mit „ssh“ am Server anmelden. Beim Ausführen von ssh-keygen wird das erstellte Schlüsselpaar in „~/.ssh/id_ecdsa_sk“ gespeichert und kann ähnlichen wie andere Schlüssel verwendet werden.

Der öffentliche Schlüssel (id_ecdsa_sk.pub) sollte auf den Server in die Datei authorized_keys kopiert werden. Auf der Serverseite wird nur die digitale Signatur überprüft, während die Interaktion mit den Tokens auf der Clientseite erfolgt (es ist nicht notwendig, libsk-libfido2 auf dem Server zu installieren, jedoch muss der Server den Schlüsseltyp „ecdsa-sk“ unterstützen). Der generierte private Schlüssel (id_ecdsa_sk) dient im Wesentlichen als Schlüssel-Descriptor und bildet den tatsächlichen Schlüssel nur in Kombination mit der geheimen Sequenz, die auf dem U2F-Token gespeichert ist. Falls der Schlüssel id_ecdsa_sk in die Hände eines Angreifers gelangt, benötigt dieser für die Authentifizierung zudem Zugriff auf das Hardware-Token, ohne das der im Datei id_ecdsa_sk gespeicherte private Schlüssel wertlos ist.

Darüber hinaus ist es standardmäßig erforderlich, bei allen Schlüsseloperationen (sowohl bei der Generierung als auch bei der Authentifizierung) eine lokale Bestätigung der physischen Anwesenheit des Benutzers, zum Beispiel durch Berührung des Sensors am Token, was entfernte Angriffe auf Systeme mit angeschlossenem Token erschwert. Als zusätzliche Schutzmaßnahme kann bei der Ausführung von ssh-keygen auch ein Passwort für den Zugriff auf die Schlüsseldatei festgelegt werden.

In der neuen Version von OpenSSH wurde zudem angekündigt, dass die Algorithmen, die SHA-1-Hashes verwenden, bald als veraltet eingestuft werden, da der Steigerung der Effizienz von Kollisionen mit festgelegtem Präfix (die Kosten für die Kollisionserstellung werden auf etwa 45.000 Dollar geschätzt). In einer der nächsten Versionen planen sie, die Verwendung des Algorithmus für digitale Signaturen auf der Grundlage des öffentlichen Schlüssels „ssh-rsa“, der im ursprünglichen RFC für das SSH-Protokoll erwähnt wird und in der Praxis weiterhin weit verbreitet ist, standardmäßig zu deaktivieren (um zu überprüfen, ob ssh-rsa in Ihren Systemen verwendet wird, können Sie versuchen, sich mit der SSH-Option „-oHostKeyAlgorithms=-ssh-rsa“ zu verbinden).

Um den Übergang zu neuen Algorithmen in OpenSSH zu erleichtern, wird in einer der kommenden Versionen standardmäßig die Einstellung UpdateHostKeys aktiviert, die es ermöglicht, Clients automatisch auf sicherere Algorithmen umzustellen. Zu den empfohlenen Algorithmen für die Migration gehören rsa-sha2-256/512 basierend auf RFC8332 RSA SHA-2 (unterstützt seit OpenSSH 7.2 und standardmäßig verwendet), ssh-ed25519 (unterstützt seit OpenSSH 6.5) und ecdsa-sha2-nistp256/384/521 basierend auf RFC5656 ECDSA (unterstützt seit OpenSSH 5.7).

In der Version OpenSSH 8.2 ist die Verbindung mit "ssh-rsa" weiterhin möglich, jedoch wurde dieser Algorithmus aus der Liste der CASignatureAlgorithms entfernt, die die für digitale Signaturen neuer Zertifikate zulässigen Algorithmen definiert. Ebenso wurde der Algorithmus diffie-hellman-group14-sha1 aus den standardmäßig unterstützten Schlüsselwechselalgorithmen entfernt. Es wird darauf hingewiesen, dass die Verwendung von SHA-1 in Zertifikaten mit zusätzlichen Risiken verbunden ist, da ein Angreifer unbegrenzte Zeit hat, um Kollisionen für ein bestehendes Zertifikat zu finden, während die Zeitangreife auf die Hostschlüssel durch das Verbindungs-Timeout (LoginGraceTime) begrenzt sind.

Beim Ausführen von ssh-keygen wird nun standardmäßig der Algorithmus rsa-sha2-512 verwendet, der seit OpenSSH 7.2 unterstützt wird. Dies kann zu Kompatibilitätsproblemen führen, wenn versucht wird, Zertifikate, die in OpenSSH 8.2 signiert wurden, auf Systemen mit älteren Versionen von OpenSSH zu verarbeiten. Um das Problem bei der Signaturbildung zu umgehen, kann explizit "ssh-keygen -t ssh-rsa" angegeben oder die Algorithmen ecdsa-sha2-nistp256/384/521 verwendet werden, die seit OpenSSH 5.7 unterstützt werden.

Weitere Änderungen:

• In der sshd_config wurde die Direktive Include hinzugefügt, die es ermöglicht, den Inhalt anderer Dateien an der aktuellen Position der Konfigurationsdatei einzufügen (bei Angabe des Dateinamens sind Wildcards erlaubt);
• In ssh-keygen wurde die Option „no-touch-required“ hinzugefügt, die die Notwendigkeit einer physischen Bestätigung des Zugriffs auf das Token bei der Schlüsselerzeugung deaktiviert;
• In der sshd_config wurde die Direktive PubkeyAuthOptions hinzugefügt, die verschiedene Optionen zur Authentifizierung mit öffentlichen Schlüsseln zusammenführt. Derzeit wird nur das Flag „no-touch-required“ unterstützt, um die Überprüfung der physischen Anwesenheit bei der Authentifizierung mit einem Token zu überspringen. In ähnlicher Weise wurde die Option „no-touch-required“ zur Datei authorized_keys hinzugefügt;
• In ssh-keygen wurde die Option „-O write-attestation=/path“ hinzugefügt, mit der zusätzliche FIDO-Bescheinigungszertifikate bei der Schlüsselerzeugung aufgezeichnet werden können. OpenSSH verwendet diese Zertifikate derzeit nicht, aber sie könnten in Zukunft zur Überprüfung der Platzierung des Schlüssels in einem vertrauenswürdigen Hardware-Speicher verwendet werden;
• In den Konfigurationen von ssh und sshd kann nun über die Direktive IPQoS der Priorisierungsmodus für den Datenverkehr festgelegt werden. LE DSCP (Lower-Effort Per-Hop Behavior);
• Bei ssh wird beim Setzen des Wertes „AddKeysToAgent=yes“, wenn der Schlüssel kein Kommentarfeld enthält, der Schlüssel in den ssh-agent mit dem Pfad zum Schlüssel als Kommentar hinzugefügt.
  In ssh-keygen und ssh-agent werden jetzt auch PKCS#11-Tags und der X.509-Subjektname als Kommentare im Schlüssel verwendet, anstelle des Pfades zur Bibliothek.
• ssh-keygen hat die Möglichkeit hinzugefügt, PEM für DSA- und ECDSA-Schlüssel zu exportieren.
• Eine neue ausführbare Datei ssh-sk-helper wurde hinzugefügt, die zur Isolierung der Bibliothek für den Zugriff auf FIDO/U2F-Tokens verwendet wird.
• In ssh und sshd wurde eine Build-Option „—with-zlib“ hinzugefügt, um die Kompilierung mit Unterstützung der zlib-Bibliothek zu ermöglichen.
• Gemäß RFC4253 wird in der beim Verbindungsaufbau angezeigten Bannerwarnung ein Hinweis auf den Zugriff gesperrt, wenn die MaxStartups-Grenzen überschritten werden. Zur vereinfachten Diagnose zeigt der Prozesskopf von sshd, der bei der Verwendung des ps-Tools sichtbar ist, die Anzahl der aktuell authentifizierten Verbindungen und den Status des MaxStartups-Limits an.
• Bei ssh und ssh-agent wird beim Aufruf eines Programms zur Anzeige des Eingabeaufforderung, das über $SSH_ASKPASS festgelegt wird, jetzt zusätzlich ein Flag mit dem Typ der Eingabeaufforderung übergeben: „confirm“ – Bestätigungsdialog (ja/nein), „none“ – Informationsnachricht, „blank“ – Passwortanfrage;
• In ssh-keygen wurde eine neue Operation mit digitalen Signaturen „find-principals“ hinzugefügt, um im Datei der erlaubten Unterzeichner des Benutzers zu suchen, die mit der angegebenen digitalen Signatur verbunden sind;
• Die Unterstützung der Prozessisolierung von sshd in Linux wurde durch den seccomp-Mechanismus verbessert: IPC-Systemaufrufe wurden untersagt und clock_gettime64(), clock_nanosleep_time64 und clock_nanosleep() wurden erlaubt.

Quelle: opennet.ru