Nach fünf Monaten Entwicklungszeit wurde die Version OpenSSH 8.5 veröffentlicht, eine offene Implementierung von Client und Server für die Protokolle SSH 2.0 und SFTP.
Die Entwickler von OpenSSH erinnerten an den bevorstehenden Umstieg auf als veraltet geltende Algorithmen, die SHA-1-Hashes verwenden. Dies geschieht im Zuge der erhöhten Effizienz von Kollisionen mit vorgegebenem Präfix (die Kosten zur Erzeugung einer Kollision werden auf etwa 50.000 Dollar geschätzt). In einer der nächsten Versionen ist geplant, die Verwendung des digitalen Signaturalgorithmus 'ssh-rsa' standardmäßig zu deaktivieren, der im ursprünglichen RFC für das SSH-Protokoll erwähnt wird und weiterhin weit verbreitet ist.
Um die Verwendung von ssh-rsa in Ihren Systemen zu überprüfen, können Sie versuchen, sich mit der SSH-Option '-oHostKeyAlgorithms=-ssh-rsa' zu verbinden. Die standardmäßige Deaktivierung der digitalen Signaturen 'ssh-rsa' bedeutet jedoch nicht, dass RSA-Schlüssel vollständig abgelehnt werden, da das SSH-Protokoll neben SHA-1 auch die Verwendung anderer Hash-Algorithmus-Methoden erlaubt. Insbesondere bleibt zusätzlich zu 'ssh-rsa' die Möglichkeit, die Kombinationen 'rsa-sha2-256' (RSA/SHA256) und 'rsa-sha2-512' (RSA/SHA512) zu verwenden.
Um den Übergang zu den neuen Algorithmen in OpenSSH 8.5 zu erleichtern, ist standardmäßig die Einstellung UpdateHostKeys aktiviert, die es ermöglicht, Clients automatisch auf sicherere Algorithmen umzuleiten. Mit dieser Einstellung wird eine spezielle Erweiterung des Protokolls „hostkeys@openssh.com“ aktiviert, die dem Server nach der Authentifizierung ermöglicht, den Client über alle verfügbaren Hostschlüssel zu informieren. Der Client kann diese Schlüssel in seiner Datei ~/.ssh/known_hosts speichern, was die Aktualisierung der Hostschlüssel organisiert und den Schlüsselwechsel vereinfacht. Server.
Die Verwendung von UpdateHostKeys ist durch einige Vorbehalte eingeschränkt, die in Zukunft möglicherweise aufgehoben werden: Der Schlüssel muss in UserKnownHostsFile erwähnt werden und darf nicht im GlobalKnownHostsFile verwendet werden; der Schlüssel muss nur unter einem Namen vorhanden sein; Hostschlüsselzertifikate dürfen nicht verwendet werden; in known_hosts dürfen keine Hostnamen-Muster verwendet werden; die Einstellung VerifyHostKeyDNS muss deaktiviert sein; die Option UserKnownHostsFile muss aktiv sein.
Zu den empfohlenen Algorithmen für die Migration gehören rsa-sha2-256/512 basierend auf RFC8332 RSA SHA-2 (unterstützt ab OpenSSH 7.2 und standardmäßig verwendet), ssh-ed25519 (unterstützt ab OpenSSH 6.5) und ecdsa-sha2-nistp256/384/521 basierend auf RFC5656 ECDSA (unterstützt ab OpenSSH 5.7).
Weitere Änderungen:
- Sicherheitsänderungen:
- Im ssh-agent wurde eine Schwachstelle behoben, die durch das doppelte Freigeben eines bereits freigegebenen Speicherbereichs (double-free) verursacht wurde. Das Problem tritt seit der Veröffentlichung von OpenSSH 8.2 auf und könnte potenziell ausgenutzt werden, wenn ein Angreifer Zugriff auf den ssh-agent-Socket auf dem lokalen System hat. Eine Ausnutzung wird dadurch erschwert, dass nur root und der ursprüngliche Benutzer Zugang zum Socket haben. Das wahrscheinlichste Angriffsszenario besteht darin, den Agenten auf ein Konto umzuleiten, das unter der Kontrolle des Angreifers steht, oder auf einen Host, auf dem der Angreifer Root-Zugriff hat.
- In sshd wurde ein Schutz gegen die Übertragung sehr großer Parameter mit Benutzernamen in das PAM-Subsystem eingeführt, was es ermöglicht, Schwachstellen in den PAM-Systemmodulen (Pluggable Authentication Module) zu blockieren. Diese Änderung hilft beispielsweise, die Verwendung von sshd als Vektor für die Ausnutzung einer kürzlich entdeckten Root-Schwachstelle in Solaris (CVE-2020-14871) zu verhindern.
- Änderungen, die möglicherweise die Kompatibilität beeinträchtigen:
- In ssh und sshd wurde die experimentelle Methode zum Schlüsselaustausch überarbeitet, die gegen das Knacken durch Quantencomputer resistent ist. Quantencomputer sind erheblich schneller beim Lösen der Aufgabe, eine natürliche Zahl in Primfaktoren zu zerlegen, die die Grundlage moderner asymmetrischer Verschlüsselungsalgorithmen bildet und auf klassischen Prozessoren praktisch nicht lösbar ist. Die verwendete Methode basiert auf dem NTRU Prime-Algorithmus, der für post-quanten Kryptosysteme entwickelt wurde, sowie auf dem Schlüsselaustauschverfahren basierend auf den elliptischen Kurven X25519. Anstelle von sntrup4591761x25519-sha512@tinyssh.org wird die Methode jetzt als sntrup761x25519-sha512@openssh.com identifiziert (der Algorithmus sntrup4591761 wurde durch sntrup761 ersetzt).
- In ssh und sshd wurde die Reihenfolge der Ankündigung unterstützter Algorithmen für digitale Signaturen geändert. Jetzt wird ED25519 anstelle von ECDSA als erstes angeboten.
- In ssh und sshd erfolgt die Einstellung der Quality of Service TOS/DSCP Parameter für interaktive Sitzungen jetzt vor dem Aufbau der TCP-Verbindung.
- In ssh und sshd wird der Cipher rijndael-cbc@lysator.liu.se nicht mehr unterstützt, der identisch mit aes256-cbc ist und bis zur Genehmigung von RFC-4253 verwendet wurde.
- Die Einstellung CheckHostIP ist standardmäßig deaktiviert, da ihr Nutzen gering ist, die Nutzung jedoch die Schlüsselrotation für Hosts hinter Load Balancern erheblich erschwert.
- In sshd wurden die Einstellungen PerSourceMaxStartups und PerSourceNetBlockSize hinzugefügt, um die Intensität des Startens von Handlern in Bezug auf die Clientadresse zu begrenzen. Diese Parameter ermöglichen eine feinere Steuerung des Startlimits für Prozesse im Vergleich zur allgemeinen Einstellung MaxStartups.
- In ssh und sshd wurde eine neue Einstellung LogVerbose hinzugefügt, die es ermöglicht, das Niveau der im Log ausgegebenen Debug-Informationen zu erhöhen, mit der Möglichkeit zur Filterung nach Mustern, Funktionen und Dateien.
- In ssh wird beim Akzeptieren eines neuen Hostschlüssels die Anzeige aller Hostnamen sichergestellt. IP-Adressen, die mit dem Schlüssel assoziiert sind.
- In ssh ist die Option UserKnownHostsFile=none erlaubt, um die Verwendung der known_hosts-Datei bei der Identifizierung von Host-Schlüsseln zu deaktivieren.
- In ssh_config für ssh wurde die Einstellung KnownHostsCommand hinzugefügt, um Daten aus der known_hosts-Datei aus der Ausgabe eines angegebenen Befehls zu erhalten.
- In ssh_config für ssh wurde die Option PermitRemoteOpen hinzugefügt, um das Ziel bei Verwendung der Option RemoteForward mit SOCKS einzuschränken.
- In ssh wird bei FIDO-Schlüsseln eine erneute PIN-Anforderung ermöglicht, wenn eine digitale Signaturoperation aufgrund einer falschen PIN fehlschlägt und keine PIN-Anforderung vom Benutzer erfolgt (zum Beispiel, wenn keine korrekten biometrischen Daten erfasst werden konnten und das Gerät in den manuellen PIN-Eingabemodus zurückgekehrt ist).
- In sshd wurde die Unterstützung zusätzlicher Systemaufrufe in den auf seccomp-bpf basierenden Prozessisolation-Mechanismus auf der Linux-Plattform integriert.
- Das Dienstprogramm contrib/ssh-copy-id wurde aktualisiert.
Quelle: opennet.ru
