OpenSSH 10.6: Sicherheitskorrekturen und neue Signaturen
OpenSSH 10.6 ist am 6. Oktober erschienen. Das Update korrigiert Sicherheitsprobleme bei Kompression, SFTP und GSSAPI und aktiviert hybride Post-Quanten-Signaturen. Priorität haben betroffene Konfigurationen; eine pauschale Schlüsselrotation ist nicht erforderlich.
OpenSSH 10.6 ist am 6. Oktober 2026 erschienen. Das Update schließt mehrere Sicherheitsprobleme in SSH-Clients, SFTP und dem Server und aktiviert hybride Post-Quanten-Signaturen. Für Linux-Admins steht zunächst die Prüfung von Paketstand und tatsächlich genutzten Funktionen an. Besonders relevant sind komprimierte Verbindungen mit gemischtem vertrauenswürdigem und fremdem Datenverkehr, rekursive SFTP-Downloads und Server mit GSSAPI-Authentifizierung.
Die Release-Notes nennen keine aktive Ausnutzung und keinen pauschalen Notfall für jeden SSH-Server. Die genannten Risikokonfigurationen sollten zeitnah geprüft werden; sonst ist ein vorbereitetes Wartungsfenster angemessen. Ohne SSH-Kompression greift der beschriebene Kompressionsangriff nicht. Systeme ohne OpenSSH gehören nicht automatisch zum betroffenen Bestand. Bei Distributionspaketen entscheidet zusätzlich der dokumentierte Patchstand, nicht allein die sichtbare Versionsnummer.
Was OpenSSH 10.6 konkret ändert
Die offizielle Ankündigung nennt den 6. Oktober als Veröffentlichungsdatum; Linuxiac berichtet am selben Tag über das Release. Für portable Systeme steht OpenSSH 10.6p1 bereit. Das Projekt kündigt außerdem vorübergehend häufigere Veröffentlichungen an: Sicherheitsprobleme würden teilweise mit KI-Unterstützung gefunden und später unabhängig erneut entdeckt. Daraus leitet das Team schnellere Fehlerkorrekturen ab, nicht den Nachweis laufender Angriffe.
- SSH-Kompression verwendet den LZ77-Wörterbuchkodierer nicht mehr. Dadurch sinkt die Kompressionsleistung zugunsten der Sicherheit.
- SFTP prüft vom Server gelieferte Pfade strenger, damit rekursive Kopien nicht außerhalb des vorgesehenen Zielverzeichnisses schreiben.
- GSSAPI-Zugangsdaten werden erst nach erfolgreicher Authentifizierung gespeichert; zusätzlich wird der Authentifizierungszustand vor neuen Versuchen zurückgesetzt.
- Direkt auf der SSH-Kommandozeile angegebene Benutzernamen dürfen weder Dollarzeichen noch Rückwärtsschrägstriche enthalten.
Kompression: Datenabfluss über gemeinsam genutzte Kanäle
Der dokumentierte Angriff ist ein Seitenkanal zur Wiedergewinnung geheimer Klartextdaten. Ein Angreifer beeinflusst Eingaben in einem Kanal einer SSH-Sitzung und beobachtet Auswirkungen auf die Länge verschlüsselter Daten. Das gemeinsam verwendete Kompressionswörterbuch kann dabei Informationen über Geheimnisse in einem anderen Kanal derselben Sitzung verraten. Verschlüsselung verhindert diese Längeninformation nicht automatisch.
Damit ist nicht jede verschlüsselte SSH-Verbindung gleichermaßen betroffen. Entscheidend sind aktive Wörterbuchkompression und das Zusammentreffen vertrauenswürdiger sowie angreiferkontrollierter Daten im gemeinsamen Kontext. OpenSSH hatte bereits davor von Kompression in solchen Verbindungen abgeraten. Das Projekt empfiehlt stattdessen Kompression auf Anwendungsebene. Für Backup- und Übertragungsstrecken bedeutet das: Bandbreiteneinsparung und Laufzeit nach dem Update erneut bewerten, statt die bisherige Wirkung der SSH-Kompression vorauszusetzen.
SFTP, GSSAPI und eingeschränkte Schlüssel
Bei SFTP liegt der Angriffspfad auf der Serverseite: Ein bösartiger Server kann einem Client präparierte Pfade liefern. Die Korrektur schützt rekursive Kopieroperationen vor Schreibzugriffen außerhalb des Zielverzeichnisses. Das ist keine Aussage über eine beliebige unauthentifizierte Codeausführung auf einem SSH-Server. Relevant sind insbesondere automatisierte Downloads von Gegenstellen, denen nicht vollständig vertraut werden kann.
Die GSSAPI-Korrekturen betreffen dagegen die serverseitige Anmeldung. Daten eines fehlgeschlagenen Versuchs konnten erhalten bleiben und nach einer später erfolgreichen anderen Authentifizierung unangemessen verfügbar werden. Zusätzlich berücksichtigt authorized_keys das Schlüsselwort restrict nun korrekt beim Tunnel-Forwarding. PermitTunnel ist standardmäßig deaktiviert; das Projekt bezeichnet diesen Fehler ausdrücklich als getrennt von der Korrektur in OpenSSH 10.5.
Auch die Kommandozeilenprüfung ist nur eine zusätzliche Schutzschicht. Benutzernamen aus der Konfigurationsdirektive User unterliegen dieser neuen Beschränkung nicht. Ungeprüfte externe Eingaben bleiben deshalb in Automatisierungen mit ProxyCommand oder Match exec problematisch. Die Release-Notes warnen weiterhin davor, Werkzeug-Kommandozeilen direkt fremden Eingaben auszusetzen.
Post-Quanten-Signaturen sind nicht der Schlüsselaustausch
Neu aktiviert ist der hybride Signaturalgorithmus ssh-mldsa44-ed25519. Er verbindet ein Post-Quanten-Verfahren mit Ed25519. Die frühere experimentelle Variante trug den Zusatz @openssh.com; damit erzeugte Schlüssel müssen laut Projekt neu erzeugt beziehungsweise entfernt werden. Daraus folgt keine Aufforderung, sämtliche vorhandenen Ed25519-Schlüssel sofort auszutauschen.
Davon getrennt ist die neue Serveroption WarnWeakCrypto. Sie ist standardmäßig aktiv und protokolliert Verbindungen, deren Schlüsselaustausch nicht als post-quantensicher gilt. Eine solche Meldung ist weder ein Einbruchsnachweis noch eine automatische Verbindungssperre. Für die Planung zählt, welche Gegenstellen moderne Verfahren unterstützen und welche bewusst weiter klassische Verfahren benötigen.
Was Admins jetzt priorisieren sollten
- Zuerst OpenSSH-Clients und Server inventarisieren: Paketversion, Hersteller-Patchstand, Kompression, GSSAPI und rekursive SFTP-Aufträge erfassen.
- Komprimierte Sitzungen mit gemischten Datenquellen priorisieren und die Notwendigkeit der SSH-Kompression bis zur Aktualisierung überprüfen.
- Automatisierte Downloads von fremden SFTP-Servern und den Patchstand der ausführenden Clients vor anderen reinen Komfortfunktionen prüfen.
- Server mit GSSAPI sowie bewusst freigegebenem
PermitTunnelgegen die Release-Änderungen abgleichen. - Updates aus dem unterstützten Distributionskanal bevorzugen. Das Upstream-Release allein belegt noch keine Paketverfügbarkeit für jede Linux-Distribution.
- Vor der Änderung Konfiguration und Konsolenzugang absichern; danach neue Anmeldungen, Dateiübertragungen und benötigte Weiterleitungen kontrollieren.
- Experimentelle Post-Quanten-Schlüssel gezielt suchen und deren Migration planen, ohne funktionierende Zugänge vorzeitig zu entfernen.
- Skripte auf
scp -Rprüfen: Die Option funktioniert noch, erzeugt jetzt aber eine Warnung und soll später ignoriert werden.
Weitere Betriebsänderungen ohne Alarmismus
SFTP unterstützt nun mkdir -p und lmkdir -p; ChannelTimeout akzeptiert Sekundenbruchteile. AgentSocketPath steuert den Ort weitergeleiteter Agent-Sockets. Außerdem steigt die Standardzahl der KDF-Runden für private OpenSSH-Schlüssel von 24 auf 32. Die Release-Notes beschreiben diesen Anstieg als linear, nicht exponentiell.
Bei scp -R betrifft die angekündigte Abkündigung die direkte Kopie zwischen entfernten Hosts, bei der scp auf einem entfernten Rechner ausgeführt wird. Künftig soll stattdessen das normale Kopieren über den aufrufenden Host bestehen bleiben. Für Unternehmen ist daher die Kombination aus Sicherheitsupdate und gezielter Kompatibilitätsprüfung sinnvoller als eine ungeplante flächendeckende Schlüsselrotation.
Passende Anleitungen auf S-EDV
- SSH-Härtung mit sshd_config und ssh-audit: Hintergrund zu effektiver Konfiguration, Match-Blöcken und sicherem Neuladen. Die dort genannten Versionsgrenzen bleiben zu beachten; es ist keine Anleitung zur neuen Signatur in 10.6.
- SSH-Key-Authentifizierung unter Linux und Windows: Grundlagen zu privaten Schlüsseln, Zugriffsrechten und der abgesicherten Umstellung des Anmeldewegs.
