Release von OpenSSH 8.7

Nach vier Monaten Entwicklung wurde die Version OpenSSH 8.7 veröffentlicht, eine Open-Source-Implementierung von Client und Server für die Protokolle SSH 2.0 und SFTP.

Wesentliche Änderungen:

• In scp wurde ein experimenteller Datenübertragungsmodus mit dem SFTP-Protokoll anstelle des traditionell verwendeten SCP/RCP-Protokolls hinzugefügt. SFTP verwendet vorhersagbarere Methoden zur Handhabung von Namen und vermeidet die Verarbeitung von Glob-Mustern über die Shell auf der anderen Seite, was Sicherheitsprobleme verursachen kann. Um SFTP in scp zu aktivieren, wurde das Flag „-s“ vorgeschlagen, wobei in Zukunft ein Standardwechsel zu diesem Protokoll geplant ist.
• In sftp-server wurden SFTP-Protokollerweiterungen implementiert, um die Pfade ~/ und ~user/ offenzulegen, was für scp erforderlich ist.
• In dem Tool scp wurde das Verhalten beim Kopieren von Dateien zwischen zwei entfernten Hosts (z. B. „scp host-a:/path host-b:“) geändert. Dies erfolgt jetzt standardmäßig über einen dazwischenliegenden lokalen Host, wie bei Angabe des Flags „-3“. Dieser Ansatz verhindert die Übertragung unnötiger Anmeldedaten an den ersten Host und eine dreifache Interpretation von Dateinamen im Shell (auf der Quelle, dem Empfänger und dem lokalen System). Die Nutzung von SFTP ermöglicht zudem den Einsatz aller Authentifizierungsmethoden beim Zugriff auf entfernte Hosts, nicht nur nicht-interaktive Methoden. Um das alte Verhalten wiederherzustellen, 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, über die sich Modi entsprechend den Flags „-N“ (ohne Sitzung) und „-s“ (Subsystem) festlegen lassen.
• In ssh-keygen ist es nun erlaubt, in Schlüsseldateien einen Gültigkeitszeitraum anzugeben.
• In ssh-keygen wurde das Flag „-Oprint-pubkey“ hinzugefügt, um den vollständigen öffentlichen Schlüssel im Rahmen der Signatur sshsig auszugeben.
• In ssh und sshd, sowohl der Client als auch der Server, wurde auf einen strikteren Parser der Konfigurationsdatei umgestellt. Dabei werden Shell-ähnliche Regeln für die Verarbeitung von Anführungszeichen, Leerzeichen und Escape-Zeichen verwendet. Der neue Parser ignoriert auch frühere Annahmen, wie das wegzulassen von Argumenten in Optionen (zum Beispiel kann die Direktive DenyUsers jetzt nicht mehr leer gelassen werden), nicht geschlossene Anführungszeichen und die Angabe mehrerer «=»-Zeichen.
• Bei der Verwendung von DNS-Einträgen SSHFP zur Überprüfung von Schlüsseln, überprüft ssh jetzt alle übereinstimmenden Einträge und nicht nur die, die einen bestimmten Typ von digitaler Signatur enthalten.
• In ssh-keygen wird bei der Generierung eines FIDO-Schlüssels mit der Option -Ochallenge für das Hashing nun eine integrierte Schicht verwendet, anstelle von libfido2, was es ermöglicht, Challenge-Sequenzen größer oder kleiner als 32 Bytes zu verwenden.
• In sshd wird bei der Verarbeitung der Direktive environment=»…» in den Dateien authorized_keys jetzt das erste Übereinstimmung akzeptiert, und es gilt eine Beschränkung von 1024 Umgebungsvariablen.

Die Entwickler von OpenSSH haben auch vor der Umstellung der Algorithmen gewarnt, die SHA-1-Hashes verwenden, da die Effizienz der Angriffe mit vorgegebenem Präfix gestiegen ist (die Kosten für einen Kollisionsangriff werden auf etwa 50.000 Dollar geschätzt). In der nächsten Version wird die Nutzung des digitalen Signaturalgorithmus "ssh-rsa", der im ursprünglichen RFC für das SSH-Protokoll erwähnt wird und nach wie vor weit verbreitet ist, standardmäßig deaktiviert.

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 neuen Algorithmen zu erleichtern, wurde in OpenSSH zuvor standardmäßig die Einstellung UpdateHostKeys aktiviert, die es ermöglicht, Clients automatisch auf zuverlässigere Algorithmen umzustellen. Diese Einstellung aktiviert eine spezielle Protokollerweiterung "hostkeys@openssh.com", die es ermöglicht, 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 erleichtert 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).

Quelle: opennet.ru