OpenSSH auf Alpine: kritischer Bypass der Passwort-Authentifizierung — was bei VPS und Containern zu prüfen ist

Am 5. November 2026 ist Portable OpenSSH 10.6p2 mit einer kritischen Abhilfe erschienen: ein Bypass der Passwort-Authentifizierung, der über sshd auf Linux-Systemen mit musl und deaktiviertem PAM ausnutzbar ist. Das ist das typische Profil von Alpine Linux, oft in Containern und schlanken Cloud-Images. Am selben Tag hat Alpine eine eigene Security Advisory veröffentlicht.

Für ein Tessiner KMU lautet die praktische Frage nicht nur «laufen wir auf Alpine oder Ubuntu?», sondern: wo läuft ein erreichbares sshd, auf welchem System und mit welcher Anmeldemethode? Viele Büros nutzen Ubuntu-VPS oder Infomaniak-Hosting (glibc + PAM): die liegen ausserhalb des genannten Perimeters. Das Risiko steigt, wenn Sie (oder ein Lieferant) Alpine-Container oder -VMs mit exponiertem SSH und noch aktivem Passwort-Login betreiben.

Was OpenSSH und Alpine sagen

In den Release Notes hält das OpenSSH-Team fest, dass die eigentliche Ursache als ausserhalb von sshd betrachtet wird, sie aber über sshd ausnutzbar ist und dort vermieden werden kann. Gemeldet hat den Fehler Özgün Kültekin (Wakefield). Alpine fasst die betriebliche Wirkung so zusammen: Unter typischen Konfigurationsbedingungen von Alpine-Installationen ohne PAM kann sich jemand, der den SSH-Port erreicht, ohne gültiges Passwort authentifizieren. Zum Zeitpunkt der Alpine-Advisory war noch keine CVE-Kennung vergeben.

Damien Miller (OpenSSH) hat in seiner Release-Mitteilung, auch bei LWN aufgegriffen, drei für Betreiber nützliche Punkte klar gestellt:

• das Problem betrifft Linux mit musl und ohne PAM (Alpine ist das übliche Beispiel);
• es betrifft nicht Nicht-Linux-Systeme, Linux mit glibc und nicht Linux, das PAM für die Passwort-Authentifizierung nutzt;
• die Freigabe wurde beschleunigt, weil KI-Agenten bekannte Fehler innert Stunden neu entdecken und lange Embargos vor allem Angreifern nützen.

Er bestätigt auch, dass ein Build mit verfügbarem PAM, aber UsePAM no, im Perimeter bleibt. Alpine hält fest: das Paket openssh-server-pam mit UsePAM yes ist nicht betroffen; betroffen sind openssh-server (ohne PAM) oder PAM mit UsePAM no, wenn PasswordAuthentication auf yes steht.

Wer draussen ist und wer drinnen – in der Praxis

Typischerweise ausserhalb (laut OpenSSH und Alpine): Debian-/Ubuntu-Server mit glibc und Passwort-Auth über PAM; Systeme mit PasswordAuthentication no; Container ohne laufendes sshd; Cloud-Images, die (oft via cloud-init) bereits nur SSH-Schlüssel akzeptieren.

Sofort zu prüfen: Alpine-Hosts (unterstützte Releases und ältere Zweige) mit lauschendem sshd, OpenSSH ohne PAM oder mit ausgeschaltetem PAM und noch aktiviertem Passwort-Login. Das gilt auch für kleine VPS, Bastions, CI-Runner und Alpine-Appliances, die «nur für den Notfall» aus dem Internet erreichbar gelassen wurden.

Was im Büro zu prüfen ist

1. SSH-Inventar. Jede Maschine, VM und jeden Container mit sshd erfassen und klären, von wo er erreichbar ist (nur internes Netz, VPN, Internet). Ist Port 22 (oder ein anderer SSH-Port) zum Internet offen, hat das höchste Priorität. Dieselbe Inventar-Logik gilt beim Prüfen exponierter Dienste: dazu unser Artikel vom 4. November zu NAS und Portweiterleitung.
2. Betriebssystem und Libc. Auf typischen Ubuntu-/Debian-/Infomaniak-Hosts liegen Sie ausserhalb des Falls musl+kein-PAM. Bei Alpine, «slim»-Images oder musl-basierten Appliances den Host als potenziell betroffen behandeln, bis Paket und Konfiguration geprüft sind.
3. Anmeldemethode. SSH-Schlüssel bevorzugen und Passwort-Login abschalten, wo er nicht nötig ist. Die Sicherheitsstufen der Zugänge (Passwort, SMS, Passkey) erklärt unser Artikel zu den fünf Stufen des BACS.
4. OpenSSH-Version und Neustart des Daemons. Alpine betont: ein Paket-Upgrade ersetzt nicht allein den laufenden Daemon – nach dem Upgrade muss sshd neu gestartet werden. Die in der Advisory genannten Alpine-Zweige (von edge bis 3.16 und neuer) haben korrigierte Pakete; Upstream-OpenSSH verweist für die Abhilfe auf 10.6p2.
5. Lieferanten und Container. Bei Hosting, Kubernetes oder CI nachfragen, ob Alpine-Knoten oder -Images SSH exponieren. Ein Container ohne sshd liegt ausserhalb; einer mit SSH und Passwörtern nicht.

Defensive Massnahmen

Zwei Wege schliessen die Lücke, wie Alpine angibt:

1. Aktualisieren des OpenSSH-/Alpine-Pakets auf die korrigierte Version Ihres Zweigs und sshd neu starten.
2. Wenn ein Update nicht sofort möglich ist: PasswordAuthentication no setzen (nur Schlüssel), zuvor prüfen, dass der Schlüssel-Login funktioniert, und die aktuelle Sitzung offen halten, bis ein neuer Login getestet ist; danach sshd neu starten.

Wir veröffentlichen keine Exploit-Schritte und keine Payloads: Ziel ist, die Exposition zu schliessen, nicht sie nachzustellen. Zu weiteren jüngsten Lücken in Web- und Server-Stacks siehe unsere Übersicht von Ende Oktober.

Häufige Fragen

Unser VPS läuft unter Ubuntu bei Infomaniak: müssen wir heute handeln?

Laut OpenSSH fällt Linux mit glibc und Passwort-Authentifizierung über PAM nicht unter diese Schwachstelle. OpenSSH aktuell zu halten und Schlüssel zu bevorzugen bleibt gute Praxis, ist aber nicht dasselbe Szenario wie Alpine/musl ohne PAM.

Wir nutzen nur Alpine-basierte Docker-Container ohne SSH darin: sind wir betroffen?

Alpine hält fest: wer in dem Container kein sshd betreibt, ist nicht betroffen. Das Risiko betrifft Umgebungen, in denen SSH lauscht und erreichbar ist.

Wir haben das Paket aktualisiert, sshd aber nicht neu gestartet: reicht das?

Nein. Alpine warnt ausdrücklich, dass das Paket-Upgrade den laufenden Daemon nicht ersetzt: sshd muss neu gestartet werden.

Gibt es schon eine CVE?

Zum Zeitpunkt der Alpine-Advisory (5. November 2026) war noch keine CVE-Kennung vergeben. Folgen Sie den OpenSSH-10.6p2-Notes und der Alpine-Advisory, nicht einer erfundenen CVE-Nummer.

Unser Ansatz

ElaraTeq Sagl unterstützt KMU und Praxen im Tessin beim Inventar der SSH-Zugänge, bei der Wahl zwischen Schlüsseln und Passwörtern und bei der Update-Planung auf VPS, Containern und Hosting in der Schweiz (Hosting, Beratung). Für eine Prüfung Ihrer Exposition können Sie uns kontaktieren.

Quellen

• OpenSSH, Portable OpenSSH 10.6p2 Release Notes, 5. November 2026
• Alpine Linux, Security advisory: openssh-server password authentication bypass, 5. November 2026
• Damien Miller, Ankündigung OpenSSH 10.6p2, 5. November 2026
• LWN.net, Critical security vulnerability affects OpenSSH on Alpine Linux systems, 5. November 2026