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

Nach viermonatiger Entwicklung vorgestellt Release OpenSSH 8.2, einer offenen Implementierung von Client und Server für die Protokolle SSH 2.0 und SFTP.

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

Um mit Geräten zu interagieren, die die Anwesenheit des Benutzers bestätigen, wurden in OpenSSH neue Schlüsseltypen "ecdsa-sk" und "ed25519-sk" hinzugefügt, in denen die digitalen Signatur-Algorithmen ECDSA und Ed25519 in Kombination mit dem Hash SHA-256 verwendet werden. Die Interaktionsverfahren mit den Tokens wurden in eine Zwischenbibliothek ausgelagert, die analog zu der Bibliothek für die Unterstützung von PKCS#11 geladen wird und eine Schnittstelle zur Bibliothek 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 den Entwicklern von OpenSSH vorbereitete Zwischenbibliothek libsk-libfido2 eingeschlossen ist Teil von libfido2, ebenso wie HID-Treiber für OpenBSD.

Für die Authentifizierung und Schlüsselgenerierung muss in den Einstellungen der Parameter "SecurityKeyProvider" angegeben oder die Umgebungsvariable SSH_SK_PROVIDER gesetzt werden, wobei der Pfad zur externen Bibliothek libsk-libfido2.so angegeben wird (export SSH_SK_PROVIDER=/path/to/libsk-libfido2.so). Es ist auch möglich, OpenSSH mit integrierter Unterstützung der Zwischenbibliothek zu kompilieren (—with-security-key-builtin); in diesem Fall muss der Parameter "SecurityKeyProvider=internal" gesetzt werden.
Anschließend muss der Befehl "ssh-keygen -t ecdsa-sk" ausgeführt werden oder, wenn die Schlüssel bereits erstellt und konfiguriert sind, kann man sich mit "ssh" mit dem Server verbinden. Bei der Ausführung von ssh-keygen wird das erstellte Schlüsselpaar in "~/.ssh/id_ecdsa_sk" gespeichert und kann 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 Token auf der Clientseite erfolgt (es ist nicht erforderlich, libsk-libfido2 auf dem Server zu installieren, aber der Server muss den Schlüsseltyp 'ecdsa-sk' unterstützen). Der generierte private Schlüssel (id_ecdsa_sk) ist im Grunde ein Schlüsseldescriptor, der den eigentlichen Schlüssel nur in Kombination mit einer geheimen Sequenz bildet, 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 auch Zugriff auf das Hardware-Token, ohne das der im Datei id_ecdsa_sk gespeicherte private Schlüssel nutzlos ist.

Darüber hinaus ist standardmäßig bei der Ausführung von Schlüsseloperationen (sowohl bei der Generierung als auch bei der Authentifizierung) eine lokale Bestätigung der physischen Anwesenheit des Benutzers erforderlich, beispielsweise indem der Benutzer aufgefordert wird, den Sensor des Tokens zu berühren, was die Durchführung von Remote-Angriffen auf Systeme mit angeschlossenem Token erschwert. Zudem kann während des Starts von ssh-keygen ein Passwort für den Zugriff auf die Schlüsseldatei festgelegt werden.

In der neuen Version von OpenSSH wurde auch die bevorstehende Einstufung von Algorithmen, die SHA-1-Hashes verwenden, als veraltet angekündigt, in Bezug auf einer Erhöhung Die Effektivität von Kollisionangriffen mit einem bestimmten Präfix (die Kosten zur Auffindung einer Kollision werden auf etwa 45.000 Dollar geschätzt). In einer der nächsten Ausgaben ist geplant, die Verwendung des digitalen Signaturalgorithms mit öffentlichem Schlüssel „ssh-rsa“ standardmäßig zu deaktivieren, der im ursprünglichen RFC für das SSH-Protokoll erwähnt wird und in der Praxis nach wie vor weit verbreitet ist (um zu überprüfen, ob ssh-rsa in Ihren Systemen verwendet wird, können Sie versuchen, sich per SSH mit der Option „-oHostKeyAlgorithms=-ssh-rsa“ zu verbinden).

Um den Übergang zu neuen Algorithmen in OpenSSH zu erleichtern, wird in einer der nächsten 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 zählen 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 wurde die Möglichkeit des Anschlusses mit "ssh-rsa" vorerst beibehalten, jedoch wurde dieser Algorithmus aus der Liste der CASignatureAlgorithms entfernt, die die Algorithmen definiert, die für die digitale Signatur neuer Zertifikate zulässig sind. Ebenso wurde der Algorithmus diffie-hellman-group14-sha1 aus den standardmäßig unterstützten Schlüssel-Austauschalgorithmen entfernt. Es wird darauf hingewiesen, dass die Verwendung von SHA-1 in Zertifikaten ein zusätzliches Risiko birgt, da ein Angreifer unbegrenzte Zeit hat, um eine Kollision für ein bestehendes Zertifikat zu finden, während die Angriffszeit auf Host-Schlüssel durch die Verbindungszeitbeschränkung (LoginGraceTime) begrenzt ist.

Bei der Ausführung von ssh-keygen wird nun standardmäßig der Algorithmus rsa-sha2-512 verwendet, der seit OpenSSH 7.2 unterstützt wird, was Kompatibilitätsprobleme bei der Verarbeitung von Zertifikaten, die in OpenSSH 8.2 signiert wurden, auf Systemen mit älteren Versionen von OpenSSH verursachen kann (um das Problem bei der Erstellung von Signaturen zu umgehen, kann ausdrücklich "ssh-keygen -t ssh-rsa" angegeben oder die Algorithmen ecdsa-sha2-nistp256/384/521, die seit OpenSSH 5.7 unterstützt werden, verwendet werden).

Weitere Änderungen:

• In die sshd_config wurde die Direktive Include hinzugefügt, die es erlaubt, den Inhalt anderer Dateien an der aktuellen Position der Konfigurationsdatei einzufügen (bei der Angabe des Dateinamens sind Glob-Masken zulässig);
• In ssh-keygen wurde die Option „no-touch-required“ hinzugefügt, die die physische Bestätigung des Zugangs zum Token bei der Schlüsselerzeugung deaktiviert;
• In sshd_config wurde die Direktive PubkeyAuthOptions hinzugefügt, die verschiedene Optionen zur Authentifizierung mit öffentlichen Schlüsseln zusammenfasst. Derzeit wird nur das Flag „no-touch-required“ unterstützt, um die Überprüfung der physischen Anwesenheit bei der Authentifizierung mittels Token zu überspringen. Entsprechend wurde in die Datei authorized_keys die Option „no-touch-required“ eingefügt;
• In ssh-keygen wurde die Option „-O write-attestation=/path“ hinzugefügt, die es ermöglicht, zusätzliche FIDO-Bescheinigungszertifikate bei der Schlüsselerzeugung zu schreiben. OpenSSH verwendet diese Zertifikate zwar vorerst nicht, sie könnten jedoch später zur Überprüfung der Platzierung des Schlüssels in einem vertrauenswürdigen Hardware-Speicher verwendet werden;
• In den Einstellungen von ssh und sshd über die Direktive IPQoS ist nun die Einstellung des Priorisierungsmodus für den Datenverkehr möglich. LE DSCP (Lower-Effort Per-Hop Behavior);
• In ssh wird bei der Einstellung „AddKeysToAgent=yes“ der Schlüssel, wenn er kein Kommentarfeld enthält, mit dem Pfad zum Schlüssel als Kommentar in den ssh-agent hinzugefügt.
  ssh-keygen und ssh-agent verwenden jetzt auch PKCS#11-Tags und den X.509-Subjektnamen als Kommentare im Schlüssel anstelle des Bibliothekspfads;
• 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, um die Zugriffsbibliothek für FIDO/U2F-Tokens zu isolieren;
• In ssh und sshd wurde die Build-Option „—with-zlib“ zur Kompilierung mit Unterstützung für die zlib-Bibliothek hinzugefügt;
• Gemäß den Anforderungen von RFC4253 wird beim Verbindungsbanner eine Warnung über den Zugriffssperrhinweis aufgrund von MaxStartups-Überschreitungen angezeigt. Zur vereinfachten Diagnose wird im Header des sshd-Prozesses, der bei der Verwendung des ps-Tools sichtbar ist, die Anzahl der gerade authentifizierten Verbindungen und der Status des MaxStartups-Limits angezeigt;
• In ssh und ssh-agent wird beim Aufruf des Programms zur Anzeige der über $SSH_ASKPASS festgelegten Eingabeaufforderung jetzt zusätzlich ein Flag des Eingabetypen übergeben: „confirm“ — Bestätigungsdialog (ja/nein), „none“ — Informationsnachricht, „blank“ — Passwortabfrage;
• In ssh-keygen wurde eine neue operation angebaut, um mittels digitaler Signaturen „find-principals“ zu suchen, die mit der angegebenen digitalen Signatur im allowed-signers-Dokument des Benutzers verbunden sind;
• Die Unterstützung der Prozessisolierung von sshd in Linux wurde mithilfe des seccomp-Mechanismus verbessert: IPC-Systemaufrufe wurden verboten, während clock_gettime64(), clock_nanosleep_time64 und clock_nanosleep() erlaubt wurden.

Quelle: opennet.ru