Alpine OpenSSH: Ist Ihr Server vom Passwort-Bypass betroffen?

Der Passwort-Bypass in Alpine OpenSSH betrifft nicht jeden Alpine-Server oder -Container. Prüfen Sie, ob ein SSH-Daemon läuft, ob er die Passwortauthentifizierung erlaubt, ob PAM aktiv ist und ob die Konten die Voraussetzungen aus Alpines Sicherheitshinweis erfüllen. Die Verwendung von SSH-Schlüsseln allein belegt nicht, dass der Server geschützt ist: Die Passwortauthentifizierung kann daneben weiterhin aktiviert sein. Alpines Sicherheitshinweis.

OpenSSH veröffentlichte am 5. November 2026 die portable Version 10.6p2 mit einer kritischen Behelfslösung für Linux-Systeme, die musl ohne PAM verwenden. Laut OpenSSH liegt die eigentliche Ursache außerhalb von sshd. Inzwischen wurde CVE-2026-123158 vergeben, während Alpines Sicherheitshinweis zunächst noch keine Kennung nannte. OpenSSH-Versionshinweise, veröffentlichter CVE-Eintrag.

Die folgende Entscheidungstabelle fasst die Bedingungen des Herstellers zu einer Prüfung der Betroffenheit zusammen. Sie beruht auf einer Auswertung des Sicherheitshinweises, nicht auf einem Scan Ihrer Infrastruktur oder einer Reproduktion der Schwachstelle. Die Paketangaben entsprechen dem Stand vom 6. November; spätere Änderungen finden Sie im verlinkten Sicherheitshinweis.

Welche Alpine-SSH-Server sind betroffen?

Für die betroffene Konfiguration müssen mehrere Bedingungen zugleich erfüllt sein. Die Bezeichnung Alpine, ein installiertes OpenSSH-Paket oder eine ältere Versionsnummer reichen als Nachweis nicht aus.

Alpine nennt einen Authentifizierungspfad ohne PAM mit aktivierter Passwortanmeldung, ein für die Anmeldung infrage kommendes Konto mit * im Passwortfeld und ein weiteres lokales Konto mit einem Passwort-Hash im Format $5$ oder $6$. Das Standardpaket openssh-server verwendet den Pfad ohne PAM. Auch nach der Installation von openssh-server-pam bleibt diese Bedingung erfüllt, wenn UsePAM weiterhin auf no steht. Voraussetzungen laut Hersteller.

Die Tabelle gilt für diesen konkreten Bypass. Die Einstufung „Nicht betroffen“ setzt voraus, dass Sie die aktive Konfiguration für das jeweilige Konto und die jeweilige Verbindung ermittelt haben.

Diese Einstufungen fassen Alpines Sicherheitshinweis zusammen. Sie sagen weder etwas über die Gesamtsicherheit des Systems aus noch klären sie, ob es bereits kompromittiert wurde.

Die Unterscheidung bei den Konten ist wesentlich. Alpine unterscheidet den Platzhalter * von der Sperrmarkierung !; behandeln Sie Passwortfelder, die nach einer deaktivierten Anmeldung aussehen, nicht pauschal gleich. Prüfen Sie die Kontovoraussetzungen im Rahmen Ihrer autorisierten Administration, ohne Passwort-Hashes in Tickets oder Chats zu kopieren. Ändern Sie Passwortfelder nicht als improvisierte Gegenmaßnahme.

Prüfen Sie auch die Anmelderegeln für root genau. Eine Einstellung, die die direkte Passwortanmeldung als root sperrt, sagt nichts darüber aus, ob ein anderes infrage kommendes Konto betroffen ist. Ebenso verändert ein privates Netzwerk, wer einen Dienst erreichen kann; es verändert nicht, ob dessen Authentifizierungskonfiguration den Bedingungen des Sicherheitshinweises entspricht.

Schützen SSH-Schlüssel vor diesem Bypass?

„Wir verwenden SSH-Schlüssel“ und PasswordAuthentication no sind zwei verschiedene Aussagen. Eine erfolgreiche Schlüsselanmeldung beweist, dass die Schlüsselauthentifizierung funktioniert. Sie beweist nicht, dass der Server die Passwortauthentifizierung für diesen oder andere Benutzer ablehnt.

In kleinen Teams wird das leicht übersehen. Möglicherweise gibt seit Jahren niemand mehr ein Passwort ein, während der Daemon weiterhin Passwortversuche annimmt. Prüfen Sie die Servereinstellung, statt sie aus den üblichen Verbindungsgewohnheiten Ihres Teams abzuleiten. Alpine nennt eine deaktivierte Passwortauthentifizierung ausdrücklich als Ausschlusskriterium für diesen Bypass. Alpines Konfigurationshinweise.

Dasselbe gilt für PAM, das Authentifizierungsframework des alternativen Serverpakets. Prüfen Sie sowohl das Paket als auch die aktive Einstellung UsePAM. Eine Paketliste mit dem Eintrag „PAM“ ist kein vollständiger Nachweis, wenn der Dienst so konfiguriert ist, dass er PAM nicht verwendet.

Cloud-Images erfordern eine eigene Prüfung. Alpines Sicherheitshinweis behandelt tiny-cloud und cloud-init getrennt. Gehen Sie daher nicht bei allen Cloud-Images von derselben Konfiguration aus. Ermitteln Sie die ursprüngliche Konfiguration des Images und spätere Änderungen an den Konten und vergleichen Sie beides mit den Herstellerhinweisen zu Cloud-Images. Der Name eines Basis-Images verrät nicht, was nach dem Start administrativ geändert wurde.

Welche Alpine-Pakete enthalten die Korrektur?

Alpine hat die Korrektur auf ältere Paketzweige zurückportiert. Vergleichen Sie Ihren Zweig und die vollständige Paketrevision mit der Herstellertabelle, statt auf jedem Rechner die Upstream-Version 10.6p2 zu verlangen.

Ausgewählte korrigierte Pakete, geprüft am 6. November:

Quelle: Alpines Tabelle der korrigierten Pakete. Dies ist ein Auszug, keine vollständige Supportübersicht. Weitere Zweige finden Sie im Sicherheitshinweis. Eine Rückportierung verlängert nicht den Support einer bereits abgekündigten Version.

Befolgen Sie bei einem betroffenen Dienst Alpines Anweisungen zur Paketaktualisierung und starten Sie sshd neu. Für einen mit OpenRC verwalteten Alpine-Dienst nennt der Sicherheitshinweis diesen Befehl:

rc-service sshd restart

Wenn ein Container oder ein anderer Dienstmanager den Daemon steuert, verwenden Sie dessen Verfahren. Falls Sie nicht sofort aktualisieren können, dokumentiert Alpine als Gegenmaßnahme das Deaktivieren der Passwortauthentifizierung mit anschließendem Neustart des Dienstes. Befolgen Sie die Anleitung des Herstellers, statt eine Konfigurationsänderung ungeprüft in eine Ihnen unbekannte Umgebung zu übernehmen.

Halten Sie vor Änderungen am Fernzugriff eine funktionierende Schlüsselsitzung offen und stellen Sie sicher, dass Sie auf die Wiederherstellungskonsole zugreifen können. Planen Sie einen separaten regulären Anmeldeversuch, damit ein Konfigurationsfehler Sie nicht vom Server aussperrt.

Was sollten Sie nach der Aktualisierung prüfen?

Prüfen Sie die Konfiguration unter denselben Bedingungen, unter denen der Dienst läuft, und bestätigen Sie anschließend, dass die Dienständerung wirksam wurde. Eine Konfigurationsprüfung und eine neue Anmeldung beantworten unterschiedliche Fragen.

Das offizielle Handbuch beschreibt sshd -t zur Prüfung von Konfiguration und Schlüsseln sowie sshd -T zur Ausgabe der wirksamen eingelesenen Konfiguration. Geben Sie -C an, wenn Sie verbindungsabhängige Match-Regeln auswerten. Zum Beispiel:

sshd -t
sshd -T -C user=example,addr=192.0.2.10,host=example.test

Benutzer, Adresse und Hostname sind hier Beispielwerte. Ersetzen Sie sie durch einen relevanten Verbindungskontext und prüfen Sie weitere Kontexte, für die andere Regeln gelten. Verwenden Sie dieselbe ausführbare Datei, Konfigurationsdatei und dieselben Startoptionen wie der laufende Dienst. Offizielles sshd-Handbuch.

Diese Befehle starten einen neuen Prozess. Sie fragen nicht die Einstellungen ab, die der laufende Daemon bereits im Speicher hält. Eine erfolgreiche Ausgabe ersetzt daher nicht den Nachweis, dass der vorgesehene Neustart abgeschlossen wurde und der korrigierte Dienst läuft.

Öffnen Sie nach der Änderung eine separate autorisierte Schlüsselsitzung und behalten Sie Ihren bestehenden Zugang bei. Prüfen Sie, ob das vorgesehene Konto weiterhin funktioniert und der Dienst die erwarteten Authentifizierungseinstellungen verwendet. Versuchen Sie nicht, den Bypass auf dem Produktivsystem auszunutzen, um sich Sicherheit zu verschaffen. Eine erfolgreiche neue Anmeldung prüft den Zugang. Sie belegt weder, dass die Passwortauthentifizierung deaktiviert ist, noch, dass zuvor keine Kompromittierung stattgefunden hat.

Zuständigkeiten für ungeklärte Konfigurationen festhalten

Halten Sie fest, welche Voraussetzungen noch ungeklärt sind. „PAM-Einstellung unbekannt“ oder „Neustart unbestätigt“ sagt der nächsten zuständigen Person, was noch zu klären ist. Ein pauschales „Alpine geprüft“ verdeckt diese Arbeit.

Wird ein betroffener Dienst als Schwachstelle gemeldet, kann Kit Security die zuständige Person, die Bewertung, die interne Diskussion und die dokumentierte Prüfung der Korrektur an einem Ort zusammenführen. Die Nachweise zu Host und Dienst liefert weiterhin Ihr Betriebsteam; der Meldeprozess entdeckt weder Alpine-Server noch prüft er automatisch den Zustand des Daemons.

Beginnen Sie mit dem Dienst, den Ihr Team jetzt prüfen kann. Ermitteln Sie dessen Authentifizierungspfad, vergleichen Sie das Paket mit Alpines Korrektur für den jeweiligen Zweig und bestätigen Sie die erforderliche Dienständerung. Halten Sie für die übrigen Konfigurationsfragen fest, wer sie klärt, bis sie beantwortet sind.