OpenSSH 10.0 veröffentlicht

Der Release von OpenSSH 10.0, der offenen Implementierung eines Clients und Servers für die Protokolle SSH 2.0 und SFTP, wurde veröffentlicht. Hauptänderungen:

• Die Unterstützung für digitale Signaturen auf der Basis des DSA-Algorithmus wurde entfernt, da deren Sicherheitsniveau nicht den modernen Anforderungen entspricht. Die Kosten für die Fortführung der Unterstützung des unsicheren DSA-Algorithmus rechtfertigen sich nicht und seine Entfernung wird dazu beitragen, die Unterstützung von DSA in anderen SSH-Implementierungen und kryptografischen Bibliotheken einzustellen. Die Verwendung von DSA-Schlüsseln wurde standardmäßig bereits 2015 eingestellt.
• Die Trennung von sshd in mehrere separate ausführbare Dateien wurde fortgesetzt. In OpenSSH 9.8 wurde der sshd-Prozess in den sshd-session-Prozess überführt, der Aufgaben im Zusammenhang mit der Sitzungsverwaltung erfüllt. In OpenSSH 10.0 wurde aus dem sshd-session-Prozess der Code, der die Authentifizierung durchführt, in einen separaten Prozess sshd-auth überführt. Der sshd-auth-Prozess ermöglicht eine zusätzliche Isolierung der mit der Authentifizierung verbundenen Daten im Adressraum eines separaten Prozesses, was den Zugriff auf diese Daten im Speicher bei Angriffen auf den zur Verarbeitung der Verbindungsphasen vor Abschluss der Authentifizierung verwendeten Code verhindert. Darüber hinaus verringert diese Änderung den Speicherverbrauch etwas, da der mit der Authentifizierung verbundene Code nun nur im Speicher vorhanden ist, während die Authentifizierung durchgeführt wird, und anschließend beim Beenden des sshd-auth-Prozesses entladen wird.
• In SSH wird standardmäßig ein hybrider Schlüssel-Austauschalgorithmus "mlkem768x25519-sha256" verwendet, der quantencomputersicher ist und eine Kombination aus X25519 ECDH und dem ML-KEM Algorithmus (CRYSTALS-Kyber) darstellt, die vom National Institute of Standards and Technology (NIST) standardisiert wurden. ML-KEM nutzt kryptografische Methoden, die auf der Lösung von Gitterproblemen basieren, deren Lösungszeiten sich bei klassischen und quantencomputing nicht unterscheiden.
• In ssh_config wurden Unterstützung für die Direktiven SetEnv und User mit Platzhaltern "%-token" und die Auflösung von Umgebungsvariablen hinzugefügt.
• In ssh_config und sshd_config wurde die Unterstützung für den Ausdruck "Match version" hinzugefügt, der es ermöglicht, Einstellungen je nach vorhandener Version von OpenSSH anzuwenden. Beispielsweise kann für die Bindung an OpenSSH 10 "Match version OpenSSH_10.*" angegeben werden.
• In ssh_config wurde die Unterstützung für Ausdrücke hinzugefügt:
  • „Match sessiontype“, das es ermöglicht, Einstellungen je nach angeforderter Sitzung zu verwenden: „shell“ für interaktive Sitzungen, „exec“ zum Ausführen von Befehlen, „subsystem“ für sftp und „none“ für Tunnel und Traffic-Umleitungen.
  • „Match command“ zur Bindung von Aktionen an die in der Befehlszeile angegebenen Befehle zum Ausführen über ssh.
  • „Match tagged „“ und „Match command „“ zur Bindung an leere Tags und zum Ausführen von ssh ohne Angabe des auszuführenden Befehls.
• In sshd_config ist die Verwendung von Masken in Dateipfaden, die in den Direktiven AuthorizedKeysFile und AuthorizedPrincipalsFile angegeben sind, zulässig.
• Im ssh-Client wurde die Unterstützung der Option „VersionAddendum“ hinzugefügt, um benutzerdefinierten Text zur Versionsnummer hinzuzufügen (früher war diese Option nur für Server sshd).
• In den Tools scp und sftp wird die Einstellung „ControlMaster no“ unterstützt, um die Verwendung vorhandener Verbindungen bei erneutem Anschluss an den Host zu verhindern.
• In sshd ist die Unterstützung der Implementierung des Diffie-Hellman-Algorithmus im Endfeld standardmäßig deaktiviert, was zur Entfernung der Methoden „diffie-hellman-group*“ und „diffie-hellman-group-exchange-*“ aus der Liste der KEXAlgorithms führte. Im Vergleich zu den auf elliptischen Kurven basierenden Diffie-Hellman-Algorithmen ist die entfernte Implementierung langsamer und benötigt bei identischem Sicherheitsniveau zusätzliche Rechenressourcen.
• In ssh ist der Modus AES-GCM bei der Auswahl eines Verschlüsselungsalgorithmus für die Verbindung nun bevorzugter als AES-CTR. Standardmäßig wird eine Prioritätenliste für die Auswahl von Verschlüsselungen festgelegt: Chacha20/Poly1305, AES-GCM (128/256) und AES-CTR (128/192/256).
• Im ssh-agent wurde die Funktion zum Entfernen aller geladenen Schlüssel bei Empfang des Signals SIGUSR1 implementiert.
• In ssh-keygen wurde die Unterstützung für FIDO-Tokens hinzugefügt, die keine Attestierungsdaten zurückgeben, wie z. B. WinHello.
• Im ssh-agent wurde die Option „-Owebsafe-allow=…“ hinzugefügt, um die Whitelist für FIDO-Anwendungen zu überschreiben.
• Ein experimentelles Tool regress/misc/ssh-verify-attestation zur Überprüfung der FIDO-Attestierungsdaten wurde hinzugefügt, die optional von ssh-keygen bei der Registrierung von FIDO-Schlüsseln generiert werden.
• In ssh-keygen ist die Verwendung von „-“ anstelle des Dateinamens erlaubt.
• In ssh-agent und der tragbaren Version von OpenSSH wurde die Unterstützung für die Aktivierung über den Socket im systemd-Stil implementiert, realisiert mit dem LISTEN_PID/LISTEN_FDS-Mechanismus.
• In der tragbaren Version:
  • Wurde die Unterstützung für die kryptographische Bibliothek AWS-LC (AWS libcrypto) implementiert.
  • In sshd wurde die Unterstützung für wtmpdb, ein Äquivalent zu wtmp, das nicht von dem Jahr 2038-Problem betroffen ist, hinzugefügt.
  • In sshd wurde die Option „—with-linux-memlock-onfault“ hinzugefügt, um sshd im Arbeitsspeicher zu verankern (Verbot des Auslagerns in den Swap-Bereich).
  • Die Option „—with-security-key-standalone“ wurde hinzugefügt, um eine isolierte Bibliothek sk-libfido2 zu erstellen.
  • Die Build-Einstellungen für RHEL 6 wurden aus der RPM-Paket-Spezifikation entfernt.
• Änderung in sshd bezüglich der Sicherheit: Die Direktive DisableForwarding erlaubte nicht ordnungsgemäß das Forwarding des X11-Protokolls und der Anfragen an den ssh-agent. Das X11-Forwarding ist standardmäßig auf der Serverseite deaktiviert, während das ssh-agent-Forwarding auf der Clientseite aktiviert ist.

Quelle: opennet.ru