Nach vier Monaten Entwicklung wurde die Ver\u00f6ffentlichung von OpenSSH 8.7, einer offenen Implementierung des Clients und Servers f\u00fcr die Protokolle SSH 2.0 und SFTP, vorgestellt. <\/p>\n
Haupt\u00e4nderungen: <\/p>\n
\n
Im scp wurde ein experimenteller Daten\u00fcbertragungsmodus mit dem SFTP-Protokoll anstelle des traditionell verwendeten SCP\/RCP-Protokolls hinzugef\u00fcgt. Bei SFTP kommen vorhersehbarere Methoden zur Handhabung von Namen zum Einsatz, und die Verarbeitung von Glob-Mustern \u00fcber die Shell auf der Seite des anderen Hosts, die Sicherheitsprobleme verursacht, wird nicht verwendet. Um SFTP in scp zu aktivieren, wurde das Flag \u201e-s\u201c vorgeschlagen, aber in Zukunft ist geplant, standardm\u00e4\u00dfig auf dieses Protokoll umzusteigen.\n
Im sftp-server wurden Protokollerweiterungen f\u00fcr SFTP implementiert, um die Pfade ~\/ und ~user\/ zu unterst\u00fctzten, was f\u00fcr scp erforderlich ist.\n
Im scp-Tool wurde das Verhalten beim Kopieren von Dateien zwischen zwei entfernten Hosts (z.B. \u201escp host-a:\/path host-b:\u201d) ge\u00e4ndert, das nun standardm\u00e4\u00dfig \u00fcber einen lokalen Zwischenspeicher erfolgt, \u00e4hnlich wie mit dem Flag \u201e-3\u201c. Dieser Ansatz vermeidet eine unn\u00f6tige \u00dcbertragung von Anmeldeinformationen an den ersten Host und eine dreifache Interpretation von Dateinamen in der Shell (auf der Quell-, Ziel- und lokalen Systemseite). Au\u00dferdem erm\u00f6glicht die Verwendung von SFTP die Nutzung aller Authentifizierungsmethoden beim Zugriff auf entfernte Hosts und nicht nur nicht-interaktive Methoden. Um das alte Verhalten wiederherzustellen, wurde die Option \u201e-R\u201c hinzugef\u00fcgt.\n
In ssh wurde die Einstellung ForkAfterAuthentication hinzugef\u00fcgt, die dem Flag \u201e-f\u201c entspricht.\n
In ssh wurde die Einstellung StdinNull hinzugef\u00fcgt, die dem Flag \u201e-n\u201c entspricht.\n
In ssh wurde die Einstellung SessionType hinzugef\u00fcgt, \u00fcber die Modi gesetzt werden k\u00f6nnen, die den Flags \u201e-N\u201c (ohne Sitzung) und \u201e-s\u201c (Subsystem) entsprechen.\n
In ssh-keygen ist es in Schl\u00fcsseldaten erlaubt, einen G\u00fcltigkeitszeitraum f\u00fcr den Schl\u00fcssel anzugeben.\n
In ssh-keygen wurde das Flag \u201e-Oprint-pubkey\u201c hinzugef\u00fcgt, um den vollst\u00e4ndigen \u00f6ffentlichen Schl\u00fcssel im Rahmen der sshsig-Signatur auszugeben.\n
In ssh und sshd, sowohl Client als auch Server, wurde auf die Verwendung eines strengeren Parsers f\u00fcr die Konfigurationsdatei umgestellt, bei dem shell-\u00e4hnliche Regeln f\u00fcr die Verarbeitung von Anf\u00fchrungszeichen, Leerzeichen und Escape-Zeichen verwendet werden. Der neue Parser \u00fcberspringt auch keine vorher get\u00e4tigten Annahmen, wie das Auslassen von Argumenten in Optionen (z.B. jetzt kann die Direktive DenyUsers nicht mehr leer gelassen werden), ungeschlossene Anf\u00fchrungszeichen und die Angabe mehrerer Zeichen \u201e=\u201c.\n
Bei der Verwendung von DNS-Eintr\u00e4gen SSHFP zur Verifizierung von Schl\u00fcsseln \u00fcberpr\u00fcft ssh jetzt alle \u00fcbereinstimmenden Eintr\u00e4ge und nicht nur die, die einen bestimmten Typ digitaler Signatur enthalten.\n
Bei ssh-keygen wird bei der Generierung eines FIDO-Schl\u00fcssels mit der Option -Ochallenge f\u00fcr die Hash-Bildung jetzt die integrierte Middleware verwendet und nicht die Bibliothek libfido2, was die Verwendung von Challenge-Sequenzen erm\u00f6glicht, die gr\u00f6\u00dfer oder kleiner als 32 Byte sind.\n
In sshd wird bei der Verarbeitung der Direktive environment=\u201e\u2026\u201c in den authorized_keys-Dateien nun das erste Vorkommen akzeptiert, und es gibt eine Einschr\u00e4nkung auf 1024 Umgebungsvariablen. <\/ul>\n
Die Entwickler von OpenSSH haben auch gewarnt, dass die Verwendung von SHA-1-Hash-Algorithmen in den Bereich der veralteten Algorithmen \u00fcbergeht, aufgrund der steigenden Effizienz von Kollisionen mit festgelegtem Pr\u00e4fix (die Kosten f\u00fcr die Kollisionserzeugung werden auf etwa 50.000 US-Dollar gesch\u00e4tzt). In der n\u00e4chsten Version wird die M\u00f6glichkeit, den Digital Signature Algorithmus «ssh-rsa» zu verwenden, der im urspr\u00fcnglichen RFC f\u00fcr das SSH-Protokoll erw\u00e4hnt wird und in der Praxis weit verbreitet ist, standardm\u00e4\u00dfig deaktiviert. <\/p>\n
Um die Verwendung von ssh-rsa in Ihren Systemen zu \u00fcberpr\u00fcfen, k\u00f6nnen Sie versuchen, sich \u00fcber SSH mit der Option «-oHostKeyAlgorithms=-ssh-rsa» zu verbinden. Die standardm\u00e4\u00dfige Deaktivierung der Digital Signatures «ssh-rsa» bedeutet jedoch nicht, dass RSA-Schl\u00fcssel vollst\u00e4ndig aufgegeben werden, da das SSH-Protokoll neben SHA-1 auch andere Hash-Algorithmusmethoden zul\u00e4sst. Insbesondere neben «ssh-rsa» bleibt die Verwendung von «rsa-sha2-256» (RSA\/SHA256) und «rsa-sha2-512» (RSA\/SHA512) m\u00f6glich. <\/p>\n