{"id":101069,"date":"2021-08-20T22:22:44","date_gmt":"2021-08-20T20:22:44","guid":{"rendered":"https:\/\/prohoster.info\/blog\/novosti-interneta\/reliz-openssh-8-7"},"modified":"2021-08-20T22:22:44","modified_gmt":"2021-08-20T20:22:44","slug":"reliz-openssh-8-7","status":"publish","type":"post","link":"https:\/\/prohoster.info\/de\/blog\/novosti-interneta\/reliz-openssh-8-7","title":{"rendered":"Release von OpenSSH 8.7","gt_translate_keys":[{"key":"rendered","format":"text"}]},"content":{"rendered":"
Nach vier Monaten Entwicklung wurde die Version OpenSSH 8.7 ver\u00f6ffentlicht, eine Open-Source-Implementierung von Client und Server f\u00fcr die Protokolle SSH 2.0 und SFTP. <\/p>\n
Wesentliche \u00c4nderungen: <\/p>\n
\n
In scp wurde ein experimenteller Daten\u00fcbertragungsmodus mit dem SFTP-Protokoll anstelle des traditionell verwendeten SCP\/RCP-Protokolls hinzugef\u00fcgt. SFTP verwendet vorhersehbarere Methoden zur Verarbeitung von Dateinamen und vermeidet die Verwendung von Glob-Mustern \u00fcber die Shell auf der anderen Hostseite, was Sicherheitsprobleme verursachen kann. Um SFTP in scp zu aktivieren, wurde das Flag \u00ab-s\u00bb vorgeschlagen, aber in Zukunft ist geplant, auf dieses Protokoll standardm\u00e4\u00dfig umzuschalten.\n
In sftp-server wurden SFTP-Protokollerweiterungen implementiert, um die Pfade ~\/ und ~user\/ offenzulegen, was f\u00fcr scp erforderlich ist.\n
In der scp-Anwendung wurde das Verhalten beim Kopieren von Dateien zwischen zwei entfernten Hosts (zum Beispiel \u00abscp host-a:\/path host-b:\u00bb) ge\u00e4ndert, sodass dies nun standardm\u00e4\u00dfig \u00fcber einen zwischengeschalteten lokalen Host erfolgt, wie es bei Angabe des Flags \u00ab-3\u00bb der Fall ist. Dieser Ansatz erm\u00f6glicht es, unn\u00f6tige Anmeldedaten an den ersten Host zu vermeiden und die dreifache Interpretation von Dateinamen in der Shell (auf der Quell-, Ziel- und lokalen Ebene) zu umgehen. Au\u00dferdem erm\u00f6glicht es bei der Verwendung von SFTP, alle Authentifizierungsmethoden beim Zugriff auf entfernte Hosts zu nutzen und nicht nur nicht-interaktive Methoden. Um das alte Verhalten wiederherzustellen, wurde die Option \u00ab-R\u00bb hinzugef\u00fcgt.\n
In ssh wurde die Einstellung ForkAfterAuthentication hinzugef\u00fcgt, die dem Flag \u201a-f\u2018 entspricht.\n
In ssh wurde die Einstellung StdinNull hinzugef\u00fcgt, die dem Flag \u201a-n\u2018 entspricht.\n
In ssh wurde die Einstellung SessionType hinzugef\u00fcgt, mit der die Modi entsprechend den Flags \u201a-N\u2018 (ohne Sitzung) und \u201a-s\u2018 (Subsystem) festgelegt werden k\u00f6nnen.\n
In ssh-keygen ist es nun erlaubt, in Schl\u00fcsseldateien einen G\u00fcltigkeitszeitraum anzugeben.\n
In ssh-keygen wurde das Flag \u201a-Oprint-pubkey\u2018 hinzugef\u00fcgt, um den vollst\u00e4ndigen \u00f6ffentlichen Schl\u00fcssel im Rahmen der Signatur sshsig auszugeben.\n
In ssh und sshd, sowohl auf Client- als auch auf Serverseite, wurde ein strikterer Parser f\u00fcr die Konfigurationsdatei eingef\u00fchrt, der shell-\u00e4hnliche Regeln f\u00fcr die Verarbeitung von Anf\u00fchrungszeichen, Leerzeichen und Escape-Zeichen verwendet. Der neue Parser ignoriert auch vorherige Annahmen, wie das Weglassen von Argumenten in Optionen (z.B. es ist jetzt nicht mehr erlaubt, die Direktive DenyUsers leer zu lassen), nicht geschlossene Anf\u00fchrungszeichen und die Angabe mehrerer Zeichen \u201a=\u2018.\n
Bei der Verwendung von DNS-Eintr\u00e4gen SSHFP zur \u00dcberpr\u00fcfung von Schl\u00fcsseln, \u00fcberpr\u00fcft ssh jetzt alle \u00fcbereinstimmenden Eintr\u00e4ge und nicht nur die, die einen bestimmten Typ von digitaler Signatur enthalten.\n
In ssh-keygen wird bei der Generierung eines FIDO-Schl\u00fcssels mit der Option -Ochallenge f\u00fcr das Hashing nun eine integrierte Schicht verwendet, anstelle von libfido2, was es erm\u00f6glicht, Challenge-Sequenzen gr\u00f6\u00dfer oder kleiner als 32 Bytes zu verwenden.\n
In sshd wird bei der Verarbeitung der Direktive environment=\u201a\u2026\u2018 in den authorized_keys-Dateien jetzt das erste Vorkommen akzeptiert, und es gilt eine Begrenzung von 1024 Umgebungsvariablen. <\/ul>\n
Die OpenSSH-Entwickler haben ebenfalls gewarnt, dass Algorithmen, die SHA-1-Hashes verwenden, als obsolet eingestuft werden, aufgrund der zunehmend effektiven Kollisionsangriffe mit vorgegebenem Pr\u00e4fix (die Kosten zur Generierung einer Kollision werden auf etwa 50.000 Dollar gesch\u00e4tzt). In der n\u00e4chsten Version wird die Verwendung des \u00f6ffentlichen Schl\u00fcssels \"ssh-rsa\" f\u00fcr digitale Signaturen standardm\u00e4\u00dfig deaktiviert, der im Original-RFC f\u00fcr das SSH-Protokoll erw\u00e4hnt wird und in der Praxis weit verbreitet ist. <\/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. Das standardm\u00e4\u00dfige Deaktivieren der digitalen Signaturen \"ssh-rsa\" bedeutet jedoch nicht, dass RSA-Schl\u00fcssel vollst\u00e4ndig aufgegeben werden, da das SSH-Protokoll neben SHA-1 auch die Verwendung anderer Hash-Algorithmen zul\u00e4sst. Insbesondere bleibt neben \"ssh-rsa\" die M\u00f6glichkeit, die Verbindungen \"rsa-sha2-256\" (RSA\/SHA256) und \"rsa-sha2-512\" (RSA\/SHA512) zu nutzen. <\/p>\n