Veröffentlichung von OpenSSH 8.2 mit Unterstützung für FIDO/U2F-Zwei-Faktor-Authentifizierungstoken

Nach vier Monaten Entwicklungszeit eingereicht freigeben OpenSSH 8.2, eine offene Client- und Serverimplementierung für die Arbeit über die Protokolle SSH 2.0 und SFTP.

Eine wesentliche Verbesserung in der Veröffentlichung von OpenSSH 8.2 war die Möglichkeit, die Zwei-Faktor-Authentifizierung mit Geräten zu verwenden, die das Protokoll unterstützen U2F, entwickelt von der Allianz FIDO. U2F ermöglicht die Erstellung kostengünstiger Hardware-Token, um die physische Anwesenheit des Benutzers zu überprüfen und mit ihm über USB, Bluetooth oder NFC zu interagieren. Solche Geräte werden als Mittel zur Zwei-Faktor-Authentifizierung auf Websites beworben, werden bereits von gängigen Browsern unterstützt und werden von verschiedenen Herstellern hergestellt, darunter Yubico, Feitian, Thetis und Kensington.

Um mit Geräten zu interagieren, die die Anwesenheit des Benutzers bestätigen, wurden OpenSSH neue Schlüsseltypen „ecdsa-sk“ und „ed25519-sk“ hinzugefügt, die die digitalen Signaturalgorithmen ECDSA und Ed25519 in Kombination mit dem SHA-256-Hash verwenden. Prozeduren für die Interaktion mit Token werden in einer Zwischenbibliothek abgelegt, die auf ähnliche Weise wie die Bibliothek für PKCS#11-Unterstützung geladen wird und einen Wrapper über der Bibliothek darstellt libfido2, das Tools für die Kommunikation mit Token über USB bereitstellt (die Protokolle FIDO U2F/CTAP 1 und FIDO 2.0/CTAP 2 werden unterstützt). Von OpenSSH-Entwicklern erstellte Zwischenbibliothek libsk-libfido2 enthalten in den Kern libfido2, sowie HID-Treiber für OpenBSD.

Um einen Schlüssel zu authentifizieren und zu generieren, müssen Sie in den Einstellungen den Parameter „SecurityKeyProvider“ angeben oder die Umgebungsvariable SSH_SK_PROVIDER festlegen, die den Pfad zur externen Bibliothek libsk-libfido2.so angibt (export SSH_SK_PROVIDER=/path/to/libsk-libfido2. Also). Es ist möglich, OpenSh mit integrierter Unterstützung für die Layer-Bibliothek (--with-security-key-builtin) zu erstellen. In diesem Fall müssen Sie den Parameter „SecurityKeyProvider=internal“ festlegen.
Als nächstes müssen Sie „ssh-keygen -t ecdsa-sk“ ausführen oder, wenn die Schlüssel bereits erstellt und konfiguriert wurden, mit „ssh“ eine Verbindung zum Server herstellen. Wenn Sie ssh-keygen ausführen, wird das generierte Schlüsselpaar in „~/.ssh/id_ecdsa_sk“ gespeichert und kann ähnlich wie andere Schlüssel verwendet werden.

Der öffentliche Schlüssel (id_ecdsa_sk.pub) sollte in der Datei „authorized_keys“ auf den Server kopiert werden. Auf der Serverseite wird nur die digitale Signatur überprüft und auf der Clientseite erfolgt die Interaktion mit Token (Sie müssen libsk-libfido2 nicht auf dem Server installieren, aber der Server muss den Schlüsseltyp „ecdsa-sk“ unterstützen). . Der generierte private Schlüssel (id_ecdsa_sk) ist im Wesentlichen ein Schlüsselhandle und bildet nur in Kombination mit der auf der U2F-Token-Seite gespeicherten geheimen Sequenz einen echten Schlüssel. Wenn der id_ecdsa_sk-Schlüssel in die Hände eines Angreifers gelangt, muss er zum Bestehen der Authentifizierung auch Zugriff auf das Hardware-Token erhalten, ohne das der in der id_ecdsa_sk-Datei gespeicherte private Schlüssel nutzlos ist.

Darüber hinaus ist bei der Durchführung von Vorgängen mit Schlüsseln (sowohl bei der Generierung als auch bei der Authentifizierung) standardmäßig eine lokale Bestätigung der physischen Anwesenheit des Benutzers erforderlich. Beispielsweise wird vorgeschlagen, den Sensor auf dem Token zu berühren, was dies erschwert Remote-Angriffe auf Systeme mit angeschlossenem Token durchführen. Als weitere Verteidigungslinie kann während der Startphase von ssh-keygen auch ein Passwort festgelegt werden, um auf die Schlüsseldatei zuzugreifen.

Die neue Version von OpenSSH kündigte außerdem die bevorstehende Abschaffung von Algorithmen an, die SHA-1-Hashes verwenden Förderung die Wirksamkeit von Kollisionsangriffen mit einem bestimmten Präfix (die Kosten für die Auswahl einer Kollision werden auf etwa 45 Dollar geschätzt). In einer der kommenden Versionen ist geplant, die Möglichkeit zur Verwendung des digitalen Signaturalgorithmus „ssh-rsa“ mit öffentlichem Schlüssel, 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 die Verwendung zu testen). von ssh-rsa in Ihren Systemen können Sie versuchen, eine Verbindung über ssh mit der Option „-oHostKeyAlgorithms=-ssh-rsa“ herzustellen.

Um den Übergang zu neuen Algorithmen in OpenSSH zu erleichtern, wird in einer zukünftigen Version die Einstellung „UpdateHostKeys“ standardmäßig aktiviert, wodurch Clients automatisch auf zuverlässigere Algorithmen migriert werden. 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 OpenSSH 8.2 ist die Möglichkeit, eine Verbindung über „ssh-rsa“ herzustellen, weiterhin verfügbar, dieser Algorithmus wurde jedoch aus der CASignatureAlgorithms-Liste entfernt, die die Algorithmen definiert, die zum digitalen Signieren neuer Zertifikate zulässig sind. Ebenso wurde der diffie-hellman-group14-sha1-Algorithmus aus den unterstützten Standardalgorithmen für den Schlüsselaustausch entfernt. Es wird darauf hingewiesen, dass die Verwendung von SHA-1 in Zertifikaten mit einem zusätzlichen Risiko verbunden ist, da der Angreifer unbegrenzt Zeit hat, nach einer Kollision für ein vorhandenes Zertifikat zu suchen, während die Angriffszeit auf Hostschlüssel durch das Verbindungszeitlimit (LoginGraceTime) begrenzt ist ).

Beim Ausführen von ssh-keygen wird jetzt 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, in OpenSSH 8.2 signierte Zertifikate auf Systemen zu verarbeiten, auf denen ältere OpenSSH-Versionen ausgeführt werden (um das Problem zu umgehen, wenn When). Beim Generieren einer Signatur können Sie explizit „ssh-keygen -t ssh-rsa“ angeben oder die Algorithmen ecdsa-sha2-nistp256/384/521 verwenden, die seit OpenSSH 5.7 unterstützt werden.

Weitere Änderungen:

• Zu sshd_config wurde eine Include-Direktive hinzugefügt, die es Ihnen ermöglicht, den Inhalt anderer Dateien an der aktuellen Position der Konfigurationsdatei einzuschließen (bei der Angabe des Dateinamens können Glob-Masken verwendet werden);
• Die Option „No-Touch-Required“ wurde zu ssh-keygen hinzugefügt, die die Notwendigkeit einer physischen Bestätigung des Zugriffs auf das Token bei der Schlüsselgenerierung deaktiviert;
• Zu sshd_config wurde eine PubkeyAuthOptions-Direktive hinzugefügt, die verschiedene Optionen im Zusammenhang mit der Authentifizierung mit öffentlichen Schlüsseln kombiniert. Derzeit wird nur das Flag „No-Touch-Required“ unterstützt, um physische Anwesenheitsprüfungen für die Token-Authentifizierung zu überspringen. Analog dazu wurde die Option „no-touch-required“ zur Datei „authorized_keys“ hinzugefügt;
• Option „-O write-attestation=/path“ zu ssh-keygen hinzugefügt, um das Schreiben zusätzlicher FIDO-Bescheinigungszertifikate beim Generieren von Schlüsseln zu ermöglichen. OpenSSH verwendet diese Zertifikate noch nicht, sie können jedoch später verwendet werden, um zu überprüfen, ob der Schlüssel in einem vertrauenswürdigen Hardware-Shop abgelegt ist;
• In den ssh- und sshd-Einstellungen ist es nun möglich, den Traffic-Priorisierungsmodus über die IPQoS-Direktive festzulegen LE DSCP (Verhalten mit geringerem Aufwand pro Hop);
• Wenn in ssh der Wert „AddKeysToAgent=yes“ festgelegt wird und der Schlüssel kein Kommentarfeld enthält, wird er zum ssh-agent hinzugefügt und gibt den Pfad zum Schlüssel als Kommentar an. IN
  ssh-keygen und ssh-agent verwenden jetzt auch PKCS#11-Labels und den X.509-Subjektnamen anstelle des Bibliothekspfads als Kommentare im Schlüssel;

• Möglichkeit hinzugefügt, PEM für DSA- und ECDSA-Schlüssel nach ssh-keygen zu exportieren;
• Eine neue ausführbare Datei, ssh-sk-helper, hinzugefügt, die zum Isolieren der FIDO/U2F-Token-Zugriffsbibliothek verwendet wird;
• Build-Option „--with-zlib“ zu ssh und sshd für die Kompilierung mit Zlib-Bibliotheksunterstützung hinzugefügt;
• Gemäß der Anforderung von RFC4253 wird im Banner, das während der Verbindung angezeigt wird, eine Warnung vor Zugriffsblockierung aufgrund der Überschreitung der MaxStartups-Grenzwerte angezeigt. Um die Diagnose zu vereinfachen, zeigt der sshd-Prozessheader, der bei Verwendung des ps-Dienstprogramms sichtbar ist, jetzt die Anzahl der aktuell authentifizierten Verbindungen und den Status des MaxStartups-Limits an;
• In ssh und ssh-agent wird beim Aufruf eines Programms zur Anzeige einer Einladung auf dem Bildschirm, spezifiziert über $SSH_ASKPASS, nun zusätzlich ein Flag mit der Art der Einladung übermittelt: „confirm“ – Bestätigungsdialog (ja/nein), „none ” – Informationsnachricht, „leer“ – Passwortabfrage;
• Eine neue Operation für digitale Signaturen „find-principals“ zu ssh-keygen hinzugefügt, um die Datei „allowed-signers“ nach dem Benutzer zu durchsuchen, der einer bestimmten digitalen Signatur zugeordnet ist;
• Verbesserte Unterstützung für die SSHD-Prozessisolation unter Linux mithilfe des Seccomp-Mechanismus: IPC-Systemaufrufe deaktivieren, Clock_gettime64(), Clock_nanosleep_time64 und Clock_Nanosleep() zulassen.

Source: opennet.ru