OpenSSH-Lücke sshole: Wer betroffen ist, wie Sie patchen

Wer von der OpenSSH-Lücke sshole betroffen ist

Die OpenSSH-Lücke sshole (CVE-2026-123158) trifft nur einen schmalen Fall. sshd muss gegen musl libc gebaut sein, PAM darf die Passwortprüfung nicht übernehmen, Passwort-Login muss erlaubt sein, und mindestens ein Konto braucht * als Passwortfeld. Ubuntu, Debian, Fedora, Rocky und Alma nutzen glibc und sind laut dem Advisory des Entdeckers nicht betroffen.

Wer dagegen Alpine Linux einsetzt, sollte heute prüfen. Das gilt für den Alpine-VPS, für Alpine-Container unter Proxmox (LXC, Linux Containers) und für Docker-Images, die auf Alpine aufbauen und einen eigenen sshd mitbringen. Diese Anleitung zeigt die Prüfung in drei Schritten, das Update, die Sofortmaßnahme und die Suche nach Spuren in den Logs.

Was die Lücke ist und wann sie bekannt wurde

Das OpenSSH-Projekt hat am 5. November 2026 die Version 10.6p2 veröffentlicht. Die Release Notes nennen sie einen kritischen Sicherheits-Workaround für Linux-Systeme mit musl libc und abgeschaltetem PAM (Pluggable Authentication Modules, das Modulsystem für Anmeldungen unter Linux). Der Eintrag beschreibt einen Bypass der Passwort-Anmeldung. Ausnutzbar ist er, wenn sshd „built and run with PAM support disabled“ ist. Gemeldet hat ihn Özgün Kültekin. Die Entwickler sehen die eigentliche Ursache außerhalb von sshd. Sie schließen die Lücke trotzdem in sshd, weil sie dort ausnutzbar ist.

Die NVD (National Vulnerability Database der US-Behörde NIST) führt den Fehler als CVE-2026-123158, veröffentlicht am 5. November 2026. Betroffen ist laut Eintrag sshd in OpenSSH vor 10.6p2 unter Linux, wenn musl libc ohne PAM genutzt wird. Als Beispiel nennt der Eintrag Alpine Linux. Die Bewertung nach CVSS 3.1 (Common Vulnerability Scoring System) liegt bei 8.1, also „High“. Der Angriff läuft über das Netz und braucht kein Konto. Die Angriffskomplexität ist als hoch eingestuft (AC:H).

Warum ein Konto mit * zum Einfallstor wird

In /etc/shadow steht bei Konten ohne gültiges Passwort oft ein *. Solche Konten melden sich nur per Schlüssel an, oder gar nicht. Typisch sind Dienstkonten wie git in einem Git-Server.

Das Advisory des Entdeckers beschreibt die Kette so. Die Funktion crypt() von musl gibt bei einem Fehler nicht NULL zurück, sondern den String *. Die SHA-512-Variante von crypt() in musl lehnt Schlüssel ab, die länger als 256 Byte sind. Im musl-Quelltext steht dafür KEY_MAX 256. Ein Passwort mit mehr als 256 Byte lässt crypt() also scheitern, und das Ergebnis lautet *. Das ist genau der Wert, der im Passwortfeld des Kontos steht.

Dazu kommt eine weitere Bedingung aus dem Advisory. Es braucht ein zweites Konto mit einem echten Passwort-Hash (Präfix $5$ oder $6$). sshd nutzt diesen Hash laut Advisory als Quelle für den Salt. Ohne so ein Spender-Konto greift der Angriff nach Angaben des Entdeckers nicht.

Zur genauen Passwortlänge widersprechen sich die Quellen. Die NVD schreibt 256 bis 1024 Zeichen, der Entdecker 257 bis 1024. Der musl-Quelltext scheitert erst bei mehr als 256 Byte. Für Ihre Prüfung spielt das keine Rolle. Entscheidend sind die Bedingungen, nicht die Länge.

Der Fix in openssh-portable ist der Commit 4353fdc mit der Nachricht „avoid password authn bypass“. Er verlangt, dass der gespeicherte Hash mindestens 4 Zeichen lang ist. Ein einzelnes * kann dann nicht mehr passen.

Warum glibc-Systeme sicher sind, steht ebenfalls im Advisory. Die meisten Distributionen prüfen Passwörter über PAM, und PAM ruft crypt() für ein * gar nicht erst auf. Dropbear und OpenBSD sind nach Aussage des Entdeckers ebenfalls nicht betroffen.

Mit PAM gebaut, aber UsePAM no: betroffen?

Die Release Notes sprechen von „built and run with PAM support disabled“. Das klingt, als wäre ein sshd mit PAM-Unterstützung immer sicher. Der Quelltext sagt etwas anderes. In auth-passwd.c nimmt sshd den PAM-Weg nur, wenn options.use_pam gesetzt ist. Sonst fällt die Prüfung auf sys_auth_passwd() zurück, und genau diese Funktion repariert der Fix. Auch die Checkliste des Entdeckers nennt UsePAM no ausdrücklich als betroffenen Fall.

Das ist wichtig, weil UsePAM laut der Manpage sshd_config(5) von OpenSSH Portable standardmäßig auf no steht. Ein Paket mit PAM-Unterstützung schützt Sie also nur, wenn in der Konfiguration auch UsePAM yes steht. Der sichere Fall ist UsePAM yes, nicht „PAM ist installiert“.

Bei Alpine gibt es dafür zwei Pakete. Das normale openssh-server hängt laut Paketseite von so:libc.musl ab und hat keine Abhängigkeit zu libpam. Das Unterpaket openssh-server-pam ist der „OpenSSH server with pam support“ und hängt von so:libpam.so.0 ab.

Schritt 1: Läuft Ihr sshd auf musl?

Führen Sie die folgenden Befehle als root aus. Auf Alpine heißt das oft doas statt sudo, oder Sie arbeiten direkt in einer root-Shell.

command -v sshd
ls /lib/ld-musl-*.so.1
grep -qa ld-musl "$(command -v sshd)" && echo "sshd ist gegen musl gelinkt"

Das sind dieselben zwei Tests, die das Prüfskript des Entdeckers verwendet: die Suche nach dem musl-Loader unter /lib und die Suche nach dem String ld-musl im sshd-Binary. Findet keiner der beiden Tests etwas, ist Ihr sshd nach diesem Test kein musl-Build. Auf einem Ubuntu- oder Debian-Server können Sie hier aufhören.

Schritt 2: PAM und Passwort-Login prüfen

sshd -T | grep -Ei '^(usepam|passwordauthentication) '
apk policy openssh-server openssh-server-pam

sshd -T liest die Konfiguration und gibt die Werte aus, mit denen sshd tatsächlich startet. Dabei zählen auch Dateien unter /etc/ssh/sshd_config.d/, wenn die Hauptdatei sie einbindet. Im Quelltext von OpenSSH steht die Ausgabe der usepam-Zeile in einem #ifdef USE_PAM. Fehlt die Zeile usepam, wurde sshd also ohne PAM gebaut, und PAM kann Sie nicht schützen.

So lesen Sie das Ergebnis:

• usepam yes: Die Passwortprüfung läuft über PAM. Dieser Weg ist nicht betroffen.
• usepam no oder keine usepam-Zeile: sshd prüft Passwörter selbst. Das ist der verwundbare Weg.
• passwordauthentication no: Passwort-Login ist aus. Die Lücke lässt sich darüber nicht ausnutzen.
• passwordauthentication yes: Das ist laut Manpage sshd_config(5) der Standard. Hier müssen Sie handeln.

apk policy zeigt, welches der beiden Pakete installiert ist und in welcher Version. Diese Version vergleichen Sie gleich mit der Liste der behobenen Versionen.

Schritt 3: Konten mit * und ein Spender-Hash

awk -F: '$2 == "*" {print $1}' /etc/shadow
awk -F: '$2 ~ /^\$[56]\$/ {print $1}' /etc/shadow

Der erste Befehl listet Konten, deren Passwortfeld genau * ist. Der zweite listet Konten mit einem SHA-256- oder SHA-512-Hash, also mögliche Salt-Spender. Er gibt nur die Namen aus, nie die Hashes. Kommen in beiden Listen Namen vor und ist Passwort-Login an, erfüllt der Server alle Bedingungen aus dem Advisory. Nutzt Ihr System Benutzer aus LDAP oder einem anderen Verzeichnisdienst, reichen diese beiden Listen nicht aus. Diese Konten stehen dann nicht in /etc/shadow.

Wer alles auf einmal prüfen will, kann das Skript check.sh aus dem Repository oz9un/sshole des Entdeckers nutzen. Es muss als root laufen und liest unter anderem /etc/shadow und die sshd-Konfiguration. Es schreibt nichts und baut keine Netzverbindung auf. Lesen Sie es trotzdem, bevor Sie es starten. Achten Sie auf die Exit-Codes, denn sie sind umgekehrt zur üblichen Erwartung: 0 heißt „exponiert“, 1 heißt „nicht exponiert“, 2 heißt „unklar“. Exit-Code 2 kommt, wenn die gelaufenen Prüfungen keine Exposition gefunden haben, einige Prüfungen aber nicht laufen konnten. Das Skript rät dann, das Ergebnis als „wahrscheinlich“ zu werten.

wget https://raw.githubusercontent.com/oz9un/sshole/main/check.sh
less check.sh
chmod +x check.sh
./check.sh; echo "Exit-Code: $?"

Alpine-VPS und LXC patchen

Der Alpine Security Tracker führt openssh für CVE-2026-123158 in diesen Versionen als behoben:

• edge: 10.6_p2-r0
• Alpine 3.24: 10.3_p1-r2
• Alpine 3.23: 10.2_p1-r1
• Alpine 3.22: 10.0_p1-r11
• Alpine 3.21: 9.9_p2-r1
• Alpine 3.20: 9.7_p1-r6
• Alpine 3.19: 9.6_p1-r3

Die stabilen Zweige bekommen also nicht 10.6p2, sondern eine neue Paket-Revision ihrer bisherigen Version. Eine Versionsnummer unter 10.6 ist darum kein Zeichen für ein fehlendes Update. Vergleichen Sie mit der Zeile Ihres Zweigs. Zweige älter als 3.19 stehen nicht im Tracker. Dort hilft nur ein Upgrade auf einen neueren Zweig oder die Sofortmaßnahme weiter unten.

apk update
apk upgrade
apk policy openssh-server openssh-server-pam
rc-service sshd restart

apk update lädt die Paketlisten neu, apk upgrade spielt alle Updates ein. Danach muss apk policy die behobene Version Ihres Zweigs oder eine neuere als installiert zeigen. Starten Sie sshd danach neu. So sehen Sie gleich, dass der Dienst mit dem neuen Paket sauber startet. Lassen Sie die SSH-Sitzung, über die Sie arbeiten, offen, bis eine zweite Anmeldung klappt.

Unter Proxmox erledigen Sie das für einen Alpine-Container vom Host aus. Ersetzen Sie 105 durch die ID Ihres Containers:

pct exec 105 -- sh -c 'apk update && apk upgrade && rc-service sshd restart'

Sofortmaßnahme: Passwort-Login abschalten

Wenn Sie nicht sofort aktualisieren können, schalten Sie Passwort-Login ab. Die Lücke steckt in der Passwortprüfung. Ist Passwort-Login aus, ist sie laut Entdecker nicht ausnutzbar. Prüfen Sie vorher, dass Ihre eigene Anmeldung per Schlüssel funktioniert. Wie Sie Schlüssel sauber erzeugen und verteilen, steht in den Grundlagen der SSH-Schlüsselverwaltung.

grep -i '^include' /etc/ssh/sshd_config
printf 'PasswordAuthentication no\n' > /etc/ssh/sshd_config.d/10-no-password.conf
sshd -t
rc-service sshd restart
sshd -T | grep -i '^passwordauthentication'

Der erste Befehl zeigt, ob Ihre sshd_config Dateien aus sshd_config.d/ einbindet. Fehlt die Include-Zeile, schreiben Sie PasswordAuthentication no direkt an den Anfang von /etc/ssh/sshd_config. Der Anfang ist wichtig, denn sshd übernimmt bei solchen Optionen den ersten Wert, den es findet. Eine spätere Zeile mit yes ändert dann nichts mehr. sshd -t prüft die Syntax, bevor Sie neu starten. sshd -T muss am Ende passwordauthentication no zeigen.

Testen Sie das danach von außen, von Ihrem eigenen Rechner:

ssh -o PubkeyAuthentication=no -o PreferredAuthentications=password user@server.example

Die Anmeldung muss mit Permission denied scheitern. In der Klammer dahinter listet der Server die Verfahren, die er noch anbietet. Dort darf password nicht mehr stehen. Weitere Einstellungen für einen öffentlich erreichbaren sshd finden Sie in der Anleitung zum Härten von SSH auf dem VPS.

Docker-Images mit eigenem sshd finden

Ein Container nutzt den Kernel des Hosts, bringt aber seine eigene libc mit. Ein Ubuntu-Host mit einem Alpine-Container, in dem sshd läuft, hat also einen musl-sshd. Auf dem Host sehen Sie alle Prozesse, auch die in Containern. Diese Schleife findet Container mit sshd und prüft jeden davon:

pgrep -a sshd
for c in $(docker ps -q); do
  docker top "$c" | grep -q sshd || continue
  echo "== Container $c"
  docker exec "$c" sh -c 'ls /lib/ld-musl-*.so.1 2>/dev/null; apk policy openssh-server openssh-server-pam 2>/dev/null; sshd -T 2>/dev/null | grep -Ei "^(usepam|passwordauthentication) "'
done

Manche Images legen ihre sshd_config an einem anderen Ort ab. Dann zeigt sshd -T ohne -f nicht die Konfiguration, mit der der Dienst wirklich läuft. Schauen Sie in solchen Fällen in die Datei, die das Image dokumentiert.

Einen Container patchen Sie nicht mit apk upgrade im laufenden Container. Diese Änderung ist weg, sobald der Container neu erstellt wird. Ziehen Sie ein neues Image, sobald der Anbieter eines mit dem Fix gebaut hat, und prüfen Sie danach erneut mit apk policy. Die beiden Befehle laufen im Verzeichnis Ihres Compose-Projekts:

docker compose pull
docker compose up -d

Wie Compose-Projekte aufgebaut sind, erklärt die Einführung zu Docker Compose auf dem VPS.

Gitea und Forgejo

Wir haben am 7. November 2026 die Dockerfiles auf den Entwicklungszweigen gelesen (Gitea main, Forgejo forgejo). Beide bauen auf Alpine 3.24 auf, installieren das Paket openssh ohne PAM und setzen das Passwortfeld des Kontos git auf *, mit echo "git:*" | chpasswd -e. Zwei Bedingungen sind damit erfüllt. Die mitgelieferte sshd-Vorlage setzt aber PasswordAuthentication no und PermitRootLogin no. Im Auslieferungszustand fehlt also der Passwort-Login. Betroffen ist so ein Container nur, wenn jemand die Vorlage geändert hat. Release-Images können auf einem anderen Stand bauen als der Entwicklungszweig. Prüfen Sie also Ihr Tag.

linuxserver/openssh-server

Dieses Image baut auf baseimage-alpine:3.24 auf und installiert openssh-server-pam, also die PAM-Variante. Das Init-Skript setzt PasswordAuthentication no und schaltet auf yes um, wenn PASSWORD_ACCESS auf true steht. Eine UsePAM-Zeile setzt das Skript nicht. Da UsePAM standardmäßig no ist, schützt das PAM-Paket allein nicht. Wenn Sie PASSWORD_ACCESS=true nutzen, prüfen Sie UsePAM in /config/sshd/sshd_config und die installierte Paketversion.

Home Assistant

Das Community-Add-on „Advanced SSH & Web Terminal“ installiert Alpines openssh ohne PAM. Im Dockerfile des Add-ons (Repository hassio-addons/addon-ssh) ist es auf dem main-Zweig heute auf openssh=10.3_p1-r2 festgelegt. Das ist die Version, die der Tracker für Alpine 3.24 als behoben führt. Passwort-Login schaltet das Add-on nur ein, wenn die Option password gesetzt ist. Welche Version in Ihrer Installation läuft und auf welchem Alpine-Zweig das Basis-Image steht, haben wir nicht geprüft. Das offizielle Add-on „Terminal & SSH“ konnten wir nicht prüfen. Schauen Sie in beiden Fällen in der Add-on-Konsole nach der installierten openssh-Version.

OpenWrt: Dropbear ist der Standard

OpenWrt nimmt dropbear in die Standard-Paketliste jedes Builds auf. Dropbear ist nach Aussage des Entdeckers nicht betroffen. Relevant ist nur ein Router, auf dem Sie zusätzlich OpenSSH installiert haben. Prüfen Sie auf dem Router:

command -v sshd

Kommt kein Pfad zurück, läuft dort kein OpenSSH-Server. Kommt ein Pfad zurück, gehen Sie die Schritte 1 bis 3 wie auf Alpine durch.

Wurde schon eingebrochen? Logs prüfen

Das Unternehmen Previdian gibt an, den ersten Angriffsversuch weniger als neun Stunden nach Veröffentlichung der CVE gesehen zu haben. Nach eigener Aussage bestätigte Previdian Root-Zugriff auf einem Honeypot mit echtem Alpine Linux und OpenSSH. Gezählt hat das Unternehmen acht Versuche von einer IP-Adresse aus Japan, alle an einem Sensor. Das berichtete Help Net Security am 6. November 2026. Es ist eine Angabe des Anbieters, unabhängig geprüft ist sie nicht. Ein exponierter Server ist trotzdem ein Grund, nach Spuren zu suchen.

Eine erfolgreiche Anmeldung protokolliert sshd mit einer Zeile, die mit Accepted beginnt. Danach folgen Verfahren, Benutzer, IP-Adresse und Port. Bei einer Passwort-Anmeldung steht dort also Accepted password for und der Kontoname. Help Net Security nennt, unter Berufung auf SOCRadar, /var/log/messages als Ort für diese Prüfung. Wohin Ihr System tatsächlich schreibt, hängt vom syslog-Dienst ab.

grep 'Accepted password for' /var/log/messages

Steht dort ein Konto, das sich nur per Schlüssel anmelden sollte, oder ein Konto mit * im Passwortfeld, gehen Sie von einem Einbruch aus. Bei Containern prüfen Sie zusätzlich docker logs für den betroffenen Container. Ein leeres Ergebnis beweist nichts. Wer root-Rechte hat, kann Logs löschen.

Nach einem Einbruch versuchen Sie nicht, das System zu säubern. Isolieren Sie den Server beim Anbieter, sichern Sie einen Snapshot der Platte, tauschen Sie alle Zugangsdaten und bauen Sie neu auf. Die Reihenfolge erklärt der Leitfaden Was tun, wenn Ihr VPS gehackt wurde.

Ein Hinweis zu Fail2ban: Es reagiert auf fehlgeschlagene Anmeldungen. Ein Angriff, der beim ersten Versuch gelingt, erzeugt keinen Fehlschlag, den es zählen könnte. Gegen Passwort-Raten bleibt Fail2ban zum Schutz von SSH nützlich. Das Update ersetzt es nicht.

FAQ

Ist Ubuntu oder Debian von sshole betroffen?

Nein, laut dem Advisory des Entdeckers nicht. Ubuntu, Debian, Fedora, Rocky und Alma bauen OpenSSH gegen glibc. Laut Advisory prüfen die meisten Distributionen Passwörter über PAM, und PAM ruft crypt() für ein * im Passwortfeld gar nicht auf. Betroffen sind sshd-Builds auf musl libc ohne aktives PAM, vor allem auf Alpine Linux und in Alpine-basierten Containern.

Reicht PasswordAuthentication no als Schutz, bis das Update da ist?

Ja, als Sofortmaßnahme. Die Lücke liegt in der Passwortprüfung, und der Entdecker nennt abgeschalteten Passwort-Login als nicht betroffen. Prüfen Sie den wirksamen Wert mit sshd -T | grep -i passwordauthentication, starten Sie sshd neu und testen Sie von außen mit ssh -o PubkeyAuthentication=no -o PreferredAuthentications=password. Spielen Sie das Update trotzdem ein, damit eine spätere Konfigurationsänderung die Lücke nicht wieder öffnet.

Schützt mich das Alpine-Paket openssh-server-pam?

Nur mit UsePAM yes in der Konfiguration. UsePAM steht standardmäßig auf no. Dann prüft sshd Passwörter selbst, auch wenn es mit PAM gebaut wurde, und genau dieser Weg ist verwundbar. Der Entdecker nennt openssh-server-pam mit UsePAM yes als sicher. Prüfen Sie den Wert mit sshd -T | grep -i usepam.

Ist mein Gitea- oder Forgejo-Container betroffen?

Im Auslieferungszustand fehlt eine Bedingung. Die am 7. November 2026 gelesenen Dockerfiles beider Projekte nutzen Alpine 3.24, OpenSSH ohne PAM und ein Konto git mit * als Passwortfeld. Ihre sshd-Vorlage setzt aber PasswordAuthentication no. Hat jemand Passwort-Login in Ihrem Container eingeschaltet, ist er betroffen, bis ein Image mit dem Fix läuft. Prüfen Sie die Version mit apk policy openssh-server im Container.

Ist Dropbear auf meinem OpenWrt-Router betroffen?

Nach Aussage des Entdeckers nicht. Dropbear ist der Standard-SSH-Server von OpenWrt und steht in der Standard-Paketliste jedes Builds. Relevant ist nur ein zusätzlich installierter OpenSSH-Server. command -v sshd auf dem Router zeigt, ob einer vorhanden ist.