Ubuntu 26.10: OpenSSH-Fehler kann SSH-Zugriff verhindern – Ursache und Workaround

Der Release-Wechsel ist geschafft, SSH funktioniert, jetzt noch die Paketliste aufräumen: Genau dieser letzte Schritt kann unter Ubuntu 26.10 gefährlich werden. Nach dem Wechsel zwischen regulärem OpenSSH und der GSSAPI-Variante kann das Purgen des entfernten Pakets Dateien löschen, die das installierte Gegenstück weiterhin benötigt. Bei einem Server steht damit der Fernzugriff auf dem Spiel.

Ubuntu 26.10: Was hat sich geändert?

Ubuntu 26.10 „Stonking Stingray“ erschien am 15. Oktober 2026. Als Zwischenversion erhält es neun Monate Unterstützung, bis Juli 2027. Canonical ordnet die Veröffentlichung in der offiziellen Ankündigung in die laufende Weiterentwicklung von Plattform und Sicherheitsfunktionen ein. Die Umstellung der coreutils auf die Rust-Implementierung uutils ist nun vollständig; auch cp, mv und rm wurden umgestellt.

Für eigene Skripte ist das ein Anlass zu Kompatibilitätstests. Die hier beschriebene SSH-Regression hat jedoch einen anderen, konkret dokumentierten Auslöser: die Paketbereinigung. Für Administratoren ergibt sich daraus eine praktische Aufgabe. Wer eine Zwischenversion auf einem ausschließlich über SSH erreichbaren Rechner einsetzt, sollte sowohl die Änderungen als auch den Wiederherstellungsweg vorab durchspielen und den kurzen Supportzeitraum einplanen.

OpenSSH mit und ohne GSSAPI/Kerberos

Die Release Notes beschreiben zwei Quellpakete: openssh und openssh-gssapi, auf Basis von OpenSSH 10.5. Für Client und Server sind diese Binärpakete relevant:

Über GSSAPI können Anwendungen beispielsweise Kerberos zur Authentifizierung nutzen. In Unternehmensnetzen ermöglicht das eine Anmeldung mit vorhandenen Tickets. Viele Installationen mit SSH-Schlüsseln benötigen diese Integration dagegen nicht. Canonicals erklärte Absicht ist, für diese Nutzer den exponierten Code und die Abhängigkeiten zu reduzieren und die benötigte Funktion für andere weiterhin anzubieten. Dazu gehört laut Release Notes ein umfangreicher nachgelagerter Kerberos-Patch, der nicht in OpenSSH selbst übernommen wurde.

Diese Trennung hat einen nachvollziehbaren Sicherheitsgrund. Der Fehler liegt bei der Übergabe zwischen den Paketen. Die jeweiligen Gegenstücke stehen im Konflikt: Wer die eine Variante installiert, entfernt damit die andere. Der Release-Upgrader sucht nach Hinweisen auf GSSAPI-Nutzung und berücksichtigt sie bei der Auswahl. Neuinstallationen verwenden standardmäßig die reguläre Variante. Welche Pakete tatsächlich vorliegen, zeigt deshalb erst die Paketdatenbank.

Warum rc ein beabsichtigter Zustand ist

Bei Debian-Paketen unterscheiden sich Entfernen und Purgen. Beim Entfernen verschwinden die installierten Programmdateien; Konfiguration und Verwaltungsdaten für eine spätere Bereinigung bleiben erhalten. Purgen beseitigt zusätzlich Konfigurationsreste und führt die entsprechende Paketlogik aus. Dieser Unterschied schützt die Arbeit des Administrators: Eine Deinstallation soll nicht zwangsläufig alle Einstellungen vernichten.

Die Statusanzeige von dpkg-query besteht aus mehreren Zeichen. Das erste beschreibt die gewünschte Aktion, das zweite den aktuellen Zustand. ii bedeutet: Installation gewünscht, Paket installiert. rc bedeutet: Entfernung gewünscht, Konfigurationsdateien verblieben. Eine normalerweise leere dritte Spalte kennzeichnet Fehler. Ein rc-Eintrag bedeutet nicht, dass noch ein zweiter SSH-Daemon läuft.

Nach einem Wechsel können also openssh-server mit rc und openssh-server-gssapi mit ii nebeneinander erscheinen. Das ist erwartbar und keine Aufforderung zur Reparatur. apt remove und apt purge sind verschiedene Aktionen. Bei autoremove müssen zusätzlich die gewählten Optionen und die lokale APT-Konfiguration berücksichtigt werden.

Wann aus Aufräumen ein Ausfall werden kann

Der am 6. Oktober angelegte Launchpad-Bug 2169738 beschreibt die problematische postrm-Logik des entfernten Pakets. Ohne Korrektur kann sie Hostschlüssel und sshd_config löschen sowie die systemd-Aktivierung beeinträchtigen, obwohl das installierte Gegenstück diese Konfiguration inzwischen benötigt. Auch die Client-Pakete sind betroffen, unter anderem bei gemeinsam genutzter SSH-Konfiguration und systemweiten bekannten Hostschlüsseln.

Es braucht eine bestimmte Abfolge: Ein Variantenwechsel entfernt das bisherige Paket, dessen Bereinigungszustand bleibt erhalten, und anschließend wird dieses Restpaket gepurgt, während das Gegenstück installiert ist. Ein Skript, das alle rc-Pakete pauschal purgt, kann diesen letzten Schritt auslösen. Dasselbe gilt für einen gezielten Purge-Befehl oder ein entsprechend eingestelltes Aufräumwerkzeug.

Eine unveränderte Installation einer einzigen Variante erfüllt diese Abfolge nicht. Das bloße Vorhandensein eines rc-Eintrags ebenfalls nicht. Weder ein Release-Upgrade noch eine normale Anmeldung beweisen für sich diesen Fehler. Umgekehrt garantiert eine noch bestehende Sitzung nicht, dass nach beschädigter Konfiguration oder Aktivierung auch die nächste Verbindung gelingt.

Fixstatus: Proposed ist noch kein ausgeliefertes SRU

Ein veröffentlichtes SRU für das reguläre Paket war in diesen Daten beim Prüfen noch nicht sichtbar. Ein Paket in stonking-proposed belegt nicht, dass ein normal gepflegter Produktionsserver es bereits erhalten hat. Proposed nur für eine Aufräumaktion zu aktivieren, wäre keine sinnvolle Lösung. Im Bug wird außerdem eine i386-Testkomplikation beschrieben: Für diese Architektur wird das GSSAPI-Gegenstück nicht gebaut. Das betrifft den Test- und Migrationsablauf; daraus folgt kein allgemeiner SSH-Ausfall auf sämtlichen Architekturen.

Die Richtung ist entscheidend. Beim Purgen des alten regulären Pakets läuft dessen Skript, auch wenn die installierte GSSAPI-Variante bereits korrigiert ist. Ein Update des installierten Gegenstücks beweist nicht, dass das zurückbehaltene Skript eines rc-Pakets sicher ist. Auch ältere GSSAPI-Revisionen stammen aus der Zeit vor dem Schutz. Die Tabelle dokumentiert den Archivstand am Prüftag und erteilt keine pauschale Freigabe zum Purgen.

Zuerst lesen, dann entscheiden

cat /etc/os-release

Prüfe, ob tatsächlich Ubuntu mit VERSION_ID="26.10" läuft. Andere Releases müssen gesondert bewertet werden. Danach folgt die Paketübersicht:

dpkg -l 'openssh-*'

Achte getrennt für Client und Server auf zusammengehörige rc/ii-Paare. Die Anführungszeichen verhindern eine Dateinamenerweiterung durch die Shell. Eine Meldung über fehlende passende Pakete belegt für sich keine beschädigte SSH-Installation.

apt-cache policy openssh-server openssh-server-gssapi openssh-client openssh-client-gssapi

Die Ausgabe zeigt installierte Versionen, Kandidaten und die dem lokalen APT-Cache bekannten Paketquellen. Sie aktualisiert diesen Cache nicht. Spiegelserver, Pinning und aktivierte Archivbereiche können das Ergebnis verändern. Für das Beispiel eines zurückgebliebenen regulären Serverpakets lässt sich zusätzlich das gespeicherte Bereinigungsskript lesen:

dpkg-query --control-show openssh-server postrm

Dieser Befehl gibt Text aus und führt das Skript nicht aus. Setze nur das tatsächlich untersuchte Restpaket ein. Fehlt das Skript, muss der Zustand geklärt werden. Interne dpkg-Dateien als vermeintlichen Reparaturtrick zu bearbeiten, ist hier kein sinnvoller Ausweg.

Der verifizierte vorbeugende Workaround

Canonicals dokumentierte Vorsichtsmaßnahme lautet, betroffene OpenSSH-Restpakete vorerst nicht zu purgen. Nimm sie aus automatischer Bereinigung heraus und prüfe Skripte, die Paketstatuslisten mit purge, --purge oder autopurge verbinden. Eine APT-Simulation hilft beim Prüfen der Paketauswahl. Sie führt aber keine Maintainer-Skripte aus und kann deren Dateilöschungen nicht als ungefährlich bestätigen.

Grenze der Verifikation: Für diesen Artikel wurden Dokumentation, Archivdaten, Paketsource und veröffentlichte Testergebnisse abgeglichen. Einen eigenen Praxistest auf Ubuntu 26.10 habe ich nicht durchgeführt. Der Regressionstest wechselt die Varianten, purgt die alten Pakete und prüft, ob Konfiguration und ein Hostschlüssel erhalten bleiben. Der amd64-Lauf vom 11. Oktober war erfolgreich. Das belegt die Korrektur in dieser Testumgebung, nicht eine hier lokal erprobte Wiederherstellung.

Wiederherstellung über die Konsole

Sichere den noch vorhandenen Baum /etc/ssh, relevante Dienstanpassungen und Protokolle geschützt, bevor du Dateien veränderst. Dazu gehören private Hostschlüssel, Konfigurationsfragmente und Authentifizierungsregeln. Ist der Schaden schon eingetreten, bewahre diesen Zustand getrennt auf und beschaffe zusätzlich ein bekannt gutes älteres Backup. Mein Beitrag zum Sichern der Linux-Konfiguration ordnet die verschiedenen Sicherungen ein.

Kläre an der Konsole, welche Variante auf diesem Rechner vorgesehen ist. Eine Kerberos-Umgebung braucht ihre GSSAPI-Unterstützung; das reguläre Paket als Abkürzung einzuspielen, kann ein neues Anmeldeproblem erzeugen. Stelle die passende Konfiguration samt Fragmenten, Eigentümern, Berechtigungen und ursprünglichen Hostschlüsseln aus vertrauenswürdiger Sicherung wieder her. Eine gehärtete Serverkonfiguration sollte nicht durch ein beliebiges Standardbeispiel ersetzt werden.

Müssen paketverwaltete Dateien repariert werden, prüfe zunächst die geplante Aktion per Simulation. Dieses Beispiel passt nur, wenn der GSSAPI-Server das beabsichtigte installierte Paket ist:

apt-get -s --reinstall install openssh-server-gssapi

Die Simulation ändert keine Pakete. Lies besonders die vorgeschlagenen Entfernungen. Eine tatsächliche Neuinstallation führt möglicherweise Skripte aus und beeinflusst Dienste; sie ist eine Entscheidung für den konkreten Rechner mit verfügbarer Konsole. Außerdem ersetzt sie kein vollständiges Backup: dpkg kann eine fehlende Conffile als beabsichtigte Löschung respektieren. Generierte und durch ucf verwaltete Dateien folgen wiederum anderen Regeln. Verwende keine pauschalen Force-Optionen. Sind ursprüngliche Hostschlüssel endgültig verloren, verändert ihre Neuerzeugung die Serveridentität. Neue Fingerprints müssen über einen vertrauenswürdigen Weg bestätigt werden; Warnungen einfach zu ignorieren ist keine Wiederherstellung.

Nach dem Wiederherstellen zunächst prüfen, ohne den Dienst neu zu starten:

sudo /usr/sbin/sshd -t

Bei Erfolg bleibt die Ausgabe normalerweise leer und der Exitstatus ist null. Fehler zuerst beheben. Bei gestopptem Dienst kann beispielsweise auch ein fehlendes Laufzeitverzeichnis auffallen; nicht jede Diagnose stammt automatisch vom Purge-Bug.

systemctl status ssh.service ssh.socket --no-pager

sudo journalctl -u ssh.service -u ssh.socket -b -n 80 --no-pager

Berücksichtige die Socket-Aktivierung. Ein lauschender Socket bei noch inaktivem Dienst kann vor der ersten Verbindung normal sein. Für inaktive oder fehlgeschlagene Units kann der Statusbefehl einen von null verschiedenen Exitstatus liefern. Stelle die vorgesehene Aktivierung wieder her, bevor du über die Konsole gezielt startest oder neu lädst. Erst eine frische authentifizierte Anmeldung aus einem weiteren Terminal bestätigt den nutzbaren Zugriff. Prüfe Konto, Rechte und Anmeldemethode, bevor du die Rettungskonsole schließt.

USN-8928-1 betrifft einen anderen Sachverhalt

Die am 14. Oktober 2026 veröffentlichte Sicherheitsmeldung USN-8928-1 nennt Ubuntu 26.04 LTS, 24.04 LTS und 22.04 LTS. Sie behandelt neun CVEs zu SFTP-Pfaden, GSSAPI-Authentifizierungszustand, Kompression, Client-Benutzernamen, Zertifikatsdaten, Dekompressionsgrenzen, Tunnelbeschränkungen und Konfigurationsverarbeitung. Dafür gelten jeweils eigene Voraussetzungen. Die Meldung macht den Paketbereinigungsbug 2169738 nicht zu einem Remote-Exploit.

Das sind die LTS-Sicherheitsversionen aus der Meldung, keine Versionsgrenzen für den 26.10-Purge-Fix. Installiere die unterstützten Sicherheitsupdates des jeweiligen Releases im regulären Wartungsprozess. Eine gefährliche Bereinigung aufzuschieben bedeutet nicht, Sicherheitsaktualisierungen auszusetzen.

Was in den Wartungsplan gehört

Erfasse beide SSH-Rollen und die Zustände beider Varianten. Behalte die Ausnahme in der Bereinigungsautomatik bei, bis die passende veröffentlichte Korrektur und die zurückbehaltenen Skripte bewertet sind. Probiere Variantenwechsel und Wiederherstellung in einer entbehrlichen VM aus, bewahre die Hostidentität und teste nach Wartungsarbeiten immer neue Verbindungen. Zum Upgradeplan gehört auch das Supportende im Juli 2027.

Die fachliche Kritik lässt sich klar benennen: Ein Paketwechsel muss Konfiguration und Identität erhalten, die das Nachfolgepaket übernimmt. Optionale Authentifizierungsfunktionen abzutrennen kann die Angriffsfläche verkleinern; eine fehlerhafte Übergabe schafft ein vermeidbares Verfügbarkeitsrisiko. Korrektur und Regressionstest setzen an dieser Grenze an. Für spätere Wartungen bleibt der Tracker maßgeblich, nicht dieser datierte Artikel als vermeintliche Live-Statusanzeige.

Häufige Fragen aus der Praxis

Verliert jeder Ubuntu-26.10-Server seinen SSH-Zugang?

Nein. Dieser Fehler benötigt die betroffene Abfolge aus Variantenwechsel und Purgen. Andere Anmeldeprobleme müssen eigenständig untersucht werden.

Muss ich rc-Pakete entfernen, damit das Upgrade fertig ist?

Nein. Der Restzustand ist vorgesehen. Bei betroffenen OpenSSH-Paketen ist das Belassen die dokumentierte Vorsichtsmaßnahme.

Ist mit Fix Released bei GSSAPI jede Wechselrichtung sicher?

Nein. Entscheidend ist das Bereinigungsskript des alten Pakets. Die reguläre Korrektur lag beim Prüfen noch in Proposed.

Bringt eine Neuinstallation meine Regeln und Hostidentität zurück?

Darauf solltest du dich nicht verlassen. Vertrauenswürdige Backups sichern und wiederherstellen, anschließend Konfiguration und eine neue Anmeldung prüfen.

Offizielle Quellen und weiterführende Dokumentation

• Ubuntu 26.10 Release Notes: Lebenszyklus, coreutils, Varianten und Purge-Vorsichtsmaßnahme.
• Launchpad-Bug 2169738: Auswirkungen, SRU-Plan und getrennte Aufgabenstände; auch über die Launchpad-API abrufbar.
• Veröffentlichungen von Stonking openssh und openssh-gssapi: Unterscheidung zwischen Release und Proposed.
• Ubuntu-Quelltext des Server-Bereinigungsskripts und Paket-Changelog: Schutz ab Revision 1:10.5p1-1ubuntu3.
• Canonicals Release-Ankündigung und USN-8928-1.
• Handbücher zu dpkg, dpkg-query und apt-get sowie Ubuntus OpenSSH-Administrationsanleitung.

Recherche am 19. Oktober 2026 geprüft. Paketstände wurden über Launchpads Quellpaket-API und amd64-Binärveröffentlichungen abgeglichen. Die Befehle sind anhand der Dokumentation geprüfte Beispiele, keine Ausgaben einer hier betriebenen Ubuntu-26.10-Installation.