OpenSSH 8.7 veröffentlicht

Nach vier Monaten Entwicklung wurde die Veröffentlichung von OpenSSH 8.7, einer offenen Implementierung des Clients und Servers für die Protokolle SSH 2.0 und SFTP, vorgestellt.

Hauptänderungen:

• Im scp wurde ein experimenteller Übertragungsmodus hinzugefügt, der das SFTP-Protokoll anstelle des traditionell verwendeten SCP/RCP-Protokolls benutzt. SFTP verwendet vorhersehbarere Methoden zur Handhabung von Namen und setzt keine Glob-Musterverarbeitung über die Shell auf dem anderen Host ein, was Sicherheitsprobleme verursacht. Um SFTP in scp zu aktivieren, wurde das Flag „-s“ vorgeschlagen, jedoch wird in Zukunft ein Wechsel zu diesem Protokoll als Standard geplant.
• Im sftp-server wurden Protokollerweiterungen für SFTP implementiert, um die Pfade ~/ und ~user/ zu unterstützten, was für scp erforderlich ist.
• In der scp-Utility wurde das Verhalten beim Kopieren von Dateien zwischen zwei entfernten Hosts (zum Beispiel „scp host-a:/path host-b:“) geändert, das jetzt standardmäßig über einen zwischenliegenden lokalen Host erfolgt, ähnlich wie beim Setzen des Flags „-3“. Dieser Ansatz vermeidet die Übertragung unnötiger Anmeldedaten an den ersten Host und die dreifache Verarbeitung von Dateinamen in der Shell (auf der Quell-, Ziel- und lokalen Systemseite) und ermöglicht bei Verwendung von SFTP die Nutzung aller Authentifizierungsmethoden beim Zugriff auf entfernte Hosts, nicht nur nicht-interaktive Methoden. Zum Wiederherstellen des alten Verhaltens wurde die Option „-R“ hinzugefügt.
• In ssh wurde die Einstellung ForkAfterAuthentication hinzugefügt, die dem Flag „-f“ entspricht.
• In ssh wurde die Einstellung StdinNull hinzugefügt, die dem Flag „-n“ entspricht.
• In ssh wurde die Einstellung SessionType hinzugefügt, mit der man Modi festlegen kann, die den Flags „-N“ (ohne Sitzung) und „-s“ (Subsystem) entsprechen.
• In ssh-keygen ist es in Schlüsseldaten erlaubt, einen Gültigkeitszeitraum für den Schlüssel anzugeben.
• In ssh-keygen wurde das Flag „-Oprint-pubkey“ hinzugefügt, um den vollständigen öffentlichen Schlüssel in der Signatur sshsig auszugeben.
• In ssh und sshd, sowohl im Client als auch im Server, wurde auf einen strengeren Parser für die Konfigurationsdatei umgestellt, der ähnliche Regeln wie die Shell für die Verarbeitung von Anführungszeichen, Leerzeichen und Escape-Zeichen verwendet. Der neue Parser lässt auch keine früheren Annahmen mehr zu, wie das Weglassen von Argumenten in Optionen (zum Beispiel kann die Direktive DenyUsers jetzt nicht mehr leer gelassen werden), nicht geschlossene Anführungszeichen und die Angabe mehrerer „=“-Symbole.
• Bei der Verwendung von DNS-Einträgen SSHFP zur Verifizierung von Schlüsseln überprüft ssh jetzt alle übereinstimmenden Einträge und nicht nur die, die einen bestimmten Typ digitaler Signatur enthalten.
• Bei ssh-keygen wird bei der Generierung eines FIDO-Schlüssels mit der Option -Ochallenge für die Hash-Bildung jetzt die integrierte Middleware verwendet und nicht die Bibliothek libfido2, was die Verwendung von Challenge-Sequenzen ermöglicht, die größer oder kleiner als 32 Byte sind.
• Bei sshd wird bei der Verarbeitung der Direktive environment="…" in den Dateien authorized_keys jetzt die erste Übereinstimmung akzeptiert und eine Begrenzung von 1024 Umgebungsvariablen-Namen angewendet.

Die Entwickler von OpenSSH haben auch davor gewarnt, dass algorithmen, die SHA-1-Hashes verwenden, als veraltet eingestuft werden, aufgrund der erhöhten Effizienz von Kollisionen mit vorgegebenem Präfix (die Kosten für das Finden einer Kollision werden auf etwa 50.000 Dollar geschätzt). Im nächsten Release wird beabsichtigt, die Verwendung des digitalen Signaturalgorithmus „ssh-rsa“, der im ursprünglichen RFC für das SSH-Protokoll erwähnt wird und in der Praxis 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. Die standardmäßige Deaktivierung von 'ssh-rsa'-Digital Signaturen bedeutet jedoch nicht, dass RSA-Schlüssel vollständig verworfen werden, da das SSH-Protokoll, abgesehen von SHA-1, auch die Verwendung anderer Hash-Berechnungsalgorithmen zulässt. Insbesondere bleiben die Kombinationen 'rsa-sha2-256' (RSA/SHA256) und 'rsa-sha2-512' (RSA/SHA512) neben 'ssh-rsa' weiterhin verfügbar.

Um den Übergang zu neuen Algorithmen zu erleichtern, wurde in OpenSSH standardmäßig die Einstellung UpdateHostKeys aktiviert, die es ermöglicht, Clients automatisch auf sicherere Algorithmen umzustellen. Mit dieser Einstellung wird eine spezielle Protok-Erweiterung „hostkeys@openssh.com“ aktiviert, die es ermöglicht, zu einem Server nach der Authentifizierung 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 Austausch von Schlüsseln erleichtert. Server.

Die Verwendung von UpdateHostKeys unterliegt mehreren Vorbedingungen, die in Zukunft möglicherweise aufgehoben werden: Der Schlüssel muss im UserKnownHostsFile erwähnt werden und darf nicht im GlobalKnownHostsFile verwendet werden; der Schlüssel muss nur unter einem Namen vorhanden sein; Zertifikate für Hostschlüssel dürfen nicht verwendet werden; im known_hosts dürfen keine Hostnamenmasken verwendet werden; die Einstellung VerifyHostKeyDNS muss deaktiviert sein; der Parameter UserKnownHostsFile muss aktiviert 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).

Quelle: opennet.ru