- OpenSSH 10.6 ist am 6. Oktober 2026 erschienen und behebt elf sicherheitsrelevante Fehler. Der Debian Security Tracker führt dazu zehn CVE-Nummern, von CVE-2026-106552 bis CVE-2026-106589.
- Für Debian 12 und Debian 13 stehen alle zehn derzeit auf „vulnerable“, ein korrigiertes Paket gibt es dort noch nicht. Behoben ist bisher nur Debian unstable.
- Keine der zehn Beschreibungen nennt eine Codeausführung aus der Ferne vor der Anmeldung. Drei Einstellungen in der
sshd_confignehmen den serverseitigen Lücken bis zum Update die Grundlage.
SSH ist auf fast jedem Linux-Server der einzige Weg hinein. Wenn das OpenSSH-Projekt eine Version mit einem ganzen Block an Sicherheitskorrekturen veröffentlicht und die eigene Distribution noch kein Paket hat, stellt sich eine praktische Frage: Was kannst du heute schon tun, und was musst du abwarten?
Worum es geht
Die Release Notes zu OpenSSH 10.6 listen elf Punkte unter „Security“. Das Projekt schreibt dazu, es habe zuletzt sehr viele Fehlermeldungen erhalten, viele davon mit Hilfe von KI-Werkzeugen gefunden. Weil dieselben Fehler oft kurz darauf unabhängig ein zweites Mal entdeckt würden, will das Team vorerst häufiger kleinere Versionen veröffentlichen, statt Korrekturen bis zum nächsten großen Release zu sammeln. Für Betreiber heißt das: Mit weiteren Sicherheitsversionen in kurzen Abständen ist zu rechnen.
Den Stand der Pakete haben wir am 7. Oktober 2026 im Debian Security Tracker nachgesehen. Dort sind zehn CVEs eingetragen, für bookworm (Debian 12) und trixie (Debian 13) alle als „vulnerable“.
| Teil | Fehler | Wen es trifft |
|---|---|---|
| sshd | Anmeldedaten aus einem fehlgeschlagenen GSSAPI-Versuch bleiben erhalten und stehen nach einer anderen, erfolgreichen Anmeldung zur Verfügung (CVE-2026-106553, CVE-2026-106555) | Server mit GSSAPIAuthentication yes, also meist mit Kerberos |
| sshd und ssh | Seitenkanal über die gemeinsame Kompression: Wer in einer Sitzung eigene Daten einschleusen kann, kann über die Länge der verschlüsselten Pakete Geheimnisse aus einem anderen Kanal derselben Sitzung erraten (CVE-2026-106582) | Verbindungen mit aktivierter Kompression, die vertrauenswürdige und fremde Daten mischen |
| sshd | Das Schlüsselwort restrict in authorized_keys galt nicht für Tunnel-Weiterleitung (CVE-2026-106586) | Server mit PermitTunnel ungleich no |
| sshd | Der Wert „none“ wurde in Match-Blöcken bei einigen Optionen wie AuthorizedPrincipalsFile als Dateiname gelesen (CVE-2026-106587) | Server mit solchen Match-Regeln |
| sshd und ssh | Komprimierte Pakete wurden nicht auf die maximale Paketgröße begrenzt (CVE-2026-106585) | Verbindungen mit Kompression |
| sftp | Ein bösartiger Server kann beim rekursiven Kopieren Dateien außerhalb des Zielordners schreiben (CVE-2026-106552) | Du als Client, wenn du von einem fremden Server holst |
| ssh | $ und \ im Benutzernamen auf der Kommandozeile konnten über ProxyCommand oder Match exec in die Shell gelangen (CVE-2026-106583) | Skripte, die Benutzernamen aus fremden Quellen an ssh übergeben |
| ssh-keygen | Sommerzeit falsch umgerechnet, Zertifikate liefen bis zu eine Stunde früher oder später ab (CVE-2026-106584) | Wer SSH-Zertifikate ausstellt |
Die zehnte CVE (CVE-2026-106589) betrifft Plattformen wie QNX 6, auf denen der Sitzungsprozess mit root-Rechten weiterläuft. Für Linux-Server spielt sie keine Rolle.
Was wir geprüft haben
Entscheidend ist, ob die Voraussetzungen auf einem normal eingerichteten Server überhaupt erfüllt sind. Wir haben dazu die Standardwerte in den Handbuchseiten nachgelesen und die Einstellungen auf einem unveränderten Ubuntu 24.04 mit OpenSSH 9.6 ausgelesen:
GSSAPIAuthenticationist im Server standardmäßigno. Wer kein Kerberos einsetzt, ist von den beiden GSSAPI-Fehlern nicht betroffen.PermitTunnelist standardmäßigno. Derrestrict-Fehler greift erst, wenn du Tunnel bewusst erlaubt hast.Compressionist im Server standardmäßigyes, im Clientno. Komprimiert wird also nur, wenn der Client sie anfordert, etwa mitssh -C. Dann aber greift der Seitenkanal grundsätzlich.
Das Ergebnis: Für einen Server mit Standardeinstellungen bleiben vor allem die Kompression und die Fehler auf der Client-Seite übrig. Beide lassen sich ohne neues Paket entschärfen.
sshd_config angepasst hast oder eine Vorlage verwendest, die das tut, zählt allein, was sshd -T auf deinem Server ausgibt.So prüfst du deinen Server
- Version feststellen.
Alles unter 10.6 ist betroffen, sofern deine Distribution die Korrekturen nicht zurückportiert hat. Bei Debian zeigt der Security Tracker, ab welcher Paketversion das der Fall ist.ssh -V apt policy openssh-server - Wirksame Einstellungen auslesen.
sudo sshd -T | grep -Ei '^(gssapiauthentication|compression|permittunnel) ' - Bis zum Update härten. Ergänze in
/etc/ssh/sshd_configoder in einer eigenen Datei unter/etc/ssh/sshd_config.d/:Compression no GSSAPIAuthentication no PermitTunnel noGSSAPIAuthenticationundPermitTunnellässt du nur aus, wenn du Kerberos oder SSH-Tunnel tatsächlich nutzt. - Konfiguration testen, dann neu laden.
Lass die aktuelle Sitzung offen und melde dich in einem zweiten Fenster neu an, bevor du die erste schließt.sudo sshd -t && sudo systemctl reload ssh - Update einspielen, sobald es da ist.
sudo apt update sudo apt install --only-upgrade openssh-server openssh-client
So erkennst du, dass es geklappt hat
Nach dem Neuladen muss sshd -T die neuen Werte zeigen, und die Anmeldung im zweiten Fenster muss funktionieren. Nach dem Paketupdate zeigt apt policy openssh-server die installierte Version. Vergleiche sie mit der im Security Tracker als „fixed“ eingetragenen.
tar czf oder zstd. Das empfiehlt auch das OpenSSH-Projekt, und es ist gegen diesen Seitenkanal immun.Und auf deinem eigenen Rechner?
Drei der Fehler betreffen den Client. Bis dein Betriebssystem ein Update liefert, hilft es, sftp -r und scp -r nur gegen Server einzusetzen, denen du vertraust, und in Skripten keine Benutzernamen aus fremden Eingaben an ssh zu übergeben. scp -R gibt ab 10.6 übrigens eine Warnung aus: Das Projekt will die Option abschaffen.
Wie du den SSH-Zugang darüber hinaus absicherst, mit Schlüsseln statt Passwörtern und mit fail2ban, steht in unserem Beitrag SSH-Zugang richtig absichern. Wenn die Aktualisierung bei dir an einem alten System scheitert, hilft der Beitrag zum Upgrade von Debian 12 auf Debian 13.
