SSHole (CVE-2026-123158): OpenSSH-Lücke bei Alpine und musl prüfen und schließen

Linux-Server und Container-Images auf Lücken wie SSHole prüfen lassen? WZ-IT erfasst Hosts und Images, spielt Updates ein und überwacht neue Schwachstellen, siehe CVE-Monitoring und Managed Server-Betreuung. Termin vereinbaren

Am 5. November 2026 hat das OpenSSH-Projekt mit OpenSSH 10.6p2 eine dringende Sicherheitsversion veröffentlicht. Sie schließt CVE-2026-123158, vom Entdecker Özgün Kültekin „SSHole“ genannt: Auf Linux-Systemen mit musl libc und ohne PAM akzeptiert sshd für Konten, deren Shadow-Feld * lautet, ein überlanges Passwort. Der Standardfall ist Alpine Linux mit dem Paket openssh-server.

Nach Angaben des OpenSSH-Projekts existiert die Lücke weder auf Linux mit glibc noch auf Systemen mit PAM-Passwortprüfung. Debian, Ubuntu, RHEL und Proxmox VE sind glibc-basiert und nutzen in der Standardkonfiguration PAM; Red Hat erklärt seine Produkte ausdrücklich für nicht betroffen. Relevant ist die Lücke dort, wo Alpine als Basis eingesetzt wird, oft ohne dass es auffällt: in Container-Images mit eigenem sshd (Git-Server, Bastion- und Jump-Container, SFTP-Dienste), auf Hosts, die mit Alpine statt Debian aufgesetzt wurden, und in Coolify-Deployments auf Alpine-Servern.

Dieser Beitrag nennt die Voraussetzungen im Detail, die gepatchten Versionen je Alpine-Branch, den Stand der Ausnutzung und konkrete Prüfbefehle für Hosts und Container. Alle Angaben haben den Stand 9. November 2026.

Inhaltsverzeichnis

1. Die Lücke in Kürze
2. Wie der Fehler entsteht
3. Wer betroffen ist und wer nicht
4. Betroffene und gepatchte Versionen
5. Wird die Lücke ausgenutzt? Stand am 9. November 2026
6. So prüfen Sie Hosts und Container
7. Sofortmaßnahme und Update
8. Container-Images neu bauen statt nur Pakete aktualisieren
9. Coolify, Git-Server und Bastion-Container
10. Spuren eines Angriffs prüfen
11. Debian, Ubuntu und Proxmox: Warum der Scanner trotzdem meldet
12. Unser Vorgehen bei WZ-IT
13. Weiterführende Guides

Die Lücke in Kürze

Quellen: CVE-Eintrag, NVD, OpenSSH-Release-Notes 10.6p2, Alpine-Advisory, BSI-Warnung vom 6. November 2026.

Der Vektor beschreibt eine Lücke, die über das Netz ohne Nutzerinteraktion und ohne Vorab-Rechte ausnutzbar ist (AV:N, PR:N, UI:N). AC:H (hohe Komplexität) steht nach der CVSS-Spezifikation für Bedingungen außerhalb der Kontrolle des Angreifers. Eine Begründung des CNA liegt nicht vor; naheliegend ist, dass die gleichzeitig nötigen Voraussetzungen auf dem Zielsystem gemeint sind (Einschätzung). Die Release-Notes nennen die Umgehung in sshd einen „critical security workaround“; die Ursache liegt laut OpenSSH außerhalb von sshd.

Wie der Fehler entsteht

Der Fehler entsteht aus dem Zusammenspiel von vier Verhaltensweisen. Die Darstellung folgt der Alpine-Advisory und der Seite des Entdeckers:

1. Konten, die sich nicht per Passwort anmelden sollen, tragen oft *. In /etc/shadow steht bei Schlüsselkonten, bei root (unter Alpine seit etwa Version 3.16) und bei vielen Dienstkonten ein Stern im Hash-Feld. Kein gültiger Passwort-Hash lautet *, die Anmeldung per Passwort ist damit nach shadow(5) ausgeschlossen. Davon zu unterscheiden sind andere Zustände: Ein mit ! beginnendes Feld ist gesperrt, ein leeres Feld erlaubt laut shadow(5) die Anmeldung ohne Passwort, sofern die Anwendung den Zugriff nicht trotzdem verweigert. „Konto ohne Passwort“ meint in diesem Beitrag ein Konto mit genau *.
2. musl meldet Fehler als *. Die Funktion crypt() der musl libc liefert bei einem Fehler den String * statt NULL zurück. Ein Fehler tritt auch auf, wenn der Schlüssel länger als 256 Bytes ist und ein SHA-256- oder SHA-512-Salt verwendet wird. Laut Entdecker liefert crypt() nach POSIX im Fehlerfall NULL, libxcrypt ein Fehler-Token wie *0 (je nach Konfiguration auch NULL); keines davon stimmt mit * überein, und sshd lehnt die Anmeldung ab.
3. sshd borgt sich ein fremdes Salt. Seit der Korrektur zu CVE-2016-6210 (Erkennung existierender Benutzer über Laufzeitunterschiede) hasht sshd ohne PAM auch für Konten ohne verwertbaren Hash. Das Salt stammt dabei von einem anderen Konto. Dafür muss es mindestens ein Konto mit $5$- oder $6$-Hash geben. Im Quellcode (pick_salt()) nimmt sshd das Salt des ersten Kontos, dessen Hash mit $ beginnt. Ob ein vorhandener $5$- oder $6$-Hash tatsächlich als Salt dient, hängt deshalb von der Reihenfolge der Konten ab.
4. Der Vergleich geht auf. crypt() liefert *, im Shadow-Feld steht *, beide sind gleich: sshd wertet das als richtiges Passwort.

Der Angreifer sendet dafür ein Passwort mit 257 bis 1024 Bytes für einen Kontonamen, den er kennt. Alpine beschreibt das für ein ausnutzbares System so: eine Verbindung, funktioniert jedes Mal, keine Wiederholversuche. Der CVE-Text nennt abweichend „256 und 1024 Zeichen“, die Seite des Entdeckers „257 und 1024 Zeichen“ und beschreibt das musl-Limit in Bytes. Alpine nennt 257 bis 1024 Bytes, was zum 256-Byte-Limit von musl (KEY_MAX 256 in crypt_sha512.c) passt.

Mit PAM-Passwortprüfung tritt der Fehler nach Angaben des OpenSSH-Projekts nicht auf; laut Entdecker ruft PAM, über das die meisten Distributionen laufen, für ein Konto mit * die Funktion crypt() gar nicht erst auf. Die Korrektur in OpenSSH 10.6p2 (Commit 4353fdc) lässt in auth-passwd.c keinen gespeicherten Hash mehr zu, der kürzer als vier Zeichen ist. Ein einzelnes * kann damit nicht mehr als Treffer zählen.

Wer betroffen ist und wer nicht

Nach der Alpine-Advisory müssen alle vier Bedingungen gleichzeitig erfüllt sein. Sie sind Mindestvoraussetzungen: Zugangsbeschränkungen wie AllowUsers und DenyUsers oder AuthenticationMethods mit mehreren zu durchlaufenden Verfahren (sshd_config) können die Anmeldung trotzdem verhindern.

Ein einziges Konto mit $5$- oder $6$-Hash kann Konten mit * erreichbar machen. Das kann ein Passwort sein, das ein Admin für die Konsole gesetzt hat, oder ein Benutzer, der über cloud-init mit hashed_passwd angelegt wurde.

Typische Zielkonten laut Alpine:

• Schlüsselkonten, die mit adduser ohne Passwort angelegt wurden.
• Benutzer aus einem Verzeichnisdienst über musl-nscd (nslcd, winbind, sssd), sofern sie keinen Shadow-Eintrag haben.
• root: Das Konto trägt seit etwa Alpine 3.16 root:*. Die Standardeinstellung PermitRootLogin prohibit-password schützt root, solange niemand PermitRootLogin yes setzt.
• Der Benutzer alpine auf den offiziellen tiny-cloud-Images (qcow2, VHD, AMI) von 3.18.11 bis 3.24.3. Er hat ein * und passwortloses doas. Laut Alpine sind die Images beim ersten Start sicher und werden ausnutzbar, sobald ein $6$-Hash auf der Maschine existiert. Images ab 3.21.10, 3.22.8, 3.23.8 und 3.24.4 enthalten den Fix.

Nicht betroffen laut Alpine:

• Container, in denen kein sshd läuft.
• Systeme mit PasswordAuthentication no.
• Gesperrte Konten mit ! im Shadow-Feld (Zeile beginnt mit user:!:). Laut Alpine können sie sich weder mit Passwort noch mit Schlüssel anmelden (Aussage der Advisory für sshd ohne PAM).
• Systeme, auf denen kein Konto einen $-Hash hat.
• Cloud-Images, die per cloud-init konfiguriert werden und bei denen cloud-init PasswordAuthentication no schreibt. Das gilt nur, solange es dabei bleibt: ssh_pwauth: true aktiviert die Passwortanmeldung wieder, ohne Angabe bleibt der bestehende Wert unverändert (cloud-init).

Zwei Punkte werden leicht falsch verstanden. Erstens funktioniert nicht „jedes Passwort für jedes Konto“: Das Zielkonto muss genau * tragen, das Passwort muss 257 bis 1024 Bytes lang sein, und ein anderes Konto braucht einen $5$- oder $6$-Hash. Zweitens schützt ein Konto mit * nicht vor dieser Lücke, obwohl es sich nicht mit einem normalen Passwort anmelden kann: Laut Alpine ist ein Konto mit ! im Feld gesperrt und deshalb nicht betroffen.

Außerhalb von Alpine nennt der Entdecker weitere musl-Systeme zur Prüfung: OpenWrt, Buildroot und Yocto sowie Docker-Images auf deren Basis (Help Net Security). Dropbear und OpenBSD sind laut Entdecker nicht betroffen.

Betroffene und gepatchte Versionen

Upstream sind alle OpenSSH-Portable-Versionen vor 10.6p2 auf Linux im CVE-Eintrag formal als betroffen geführt; das sagt nicht, dass jede dieser Versionen technisch betroffen ist. Entscheidend ist die libc: Auf glibc-Systemen oder mit PAM tritt der Fehler nicht auf (siehe unten).

Bei Alpine behalten die gepatchten Pakete ihre ältere Versionsnummer, weil der Fix in die Pakete der stabilen Branches zurückportiert wurde. Alpine hat gepatchte Pakete für jeden Branch von 3.16 bis edge veröffentlicht:

Quellen: Paketversionen aus der Alpine-Advisory, Support-Stand aus den Alpine-Releases. Die Paketversionen stimmen mit den APKINDEX-Dateien der Repositories main (x86_64) der Branches 3.16 bis edge vom 9. November 2026 überein. Der Eintrag im APKBUILD von 3.22 lautet 10.0_p1-r11: CVE-2026-123158.

Für Branches vor 3.16 ist die Betroffenheit in der Advisory nicht ausgeführt. Wir empfehlen, Images und Server auf diesen Ständen ohnehin zu ersetzen.

Andere Distributionen (Stand 9. November 2026):

Damien Miller vom OpenSSH-Projekt hat die Abgrenzung in seiner Ankündigung so formuliert: Die Lücke existiert nicht auf Nicht-Linux-Systemen, nicht auf Linux mit glibc und nicht auf Linux-Systemen, die PAM für die Passwortanmeldung nutzen.

Wird die Lücke ausgenutzt? Stand am 9. November 2026

Die Quellen berichten zu unterschiedlichen Zeitpunkten. Die folgende Tabelle trennt, wer was sagt:

Einordnung:

• Belegt: Ein Proof-of-Concept ist öffentlich. Der CVE-Eintrag verweist auf Reproduktions-Repositories, das BSI bestätigt die Verfügbarkeit. Previdian warnt, die öffentlichen Skripte seien unverifiziert und könnten Schadcode enthalten.
• Beobachtete Versuche: Previdian meldet Versuche und einen Root-Zugriff auf einen eigenen Honeypot. Das SANS Internet Storm Center beobachtete unabhängig davon ab dem 5. November Exploit-Versuche in Honeypots; ob sie gelangen, lässt der Bericht vom 8. November offen. Eine dokumentierte Kompromittierung produktiver Systeme haben wir bis zum 9. November 2026 nicht gefunden. Die frühere Aussage von Field Effect widerspricht dem nicht, sie bezieht sich auf den Zeitpunkt der Offenlegung.
• Nicht belegt: eine breite Angriffswelle. 20 Versuche an 4 Sensoren erlauben keine Aussage zur Verbreitung.

Praktisch ändert der offene Stand der Ausnutzung nichts. Ein erfolgreicher Angriff braucht eine Verbindung und den Namen eines Kontos mit *, und Namen wie alpine, root oder git sind leicht zu raten. Ein Host, der die Voraussetzungen erfüllt, ist bis zum Update oder bis zum Abschalten der Passwortanmeldung als ausnutzbar zu behandeln.

So prüfen Sie Hosts und Container

Die Befehle sind für Alpine-Hosts mit OpenRC und BusyBox ausgelegt. Sie lesen nur und ändern keine Konfiguration.

Schritt 1: Läuft das System auf Alpine, und welcher sshd läuft?

cat /etc/alpine-release
ldd /usr/sbin/sshd; echo "ldd-Exitstatus: $?"
apk list -I 'openssh*'
ls -l /proc/$(cat /run/sshd.pid)/exe

ldd zeigt bei musl-Systemen einen Eintrag wie ld-musl-x86_64.so.1, auf glibc-Systemen libc.so.6. Eine leere Ausgabe oder eine Fehlermeldung ist kein Beleg für glibc: Dann fehlt das Binary oder die Prüfung ist fehlgeschlagen, und der Exitstatus entscheidet. apk list -I listet die installierten OpenSSH-Pakete mit Version, die Version vergleichen Sie mit der Tabelle oben. Das zeigt den Paketstand und nicht den Stand des laufenden Prozesses: Ein vor dem Update gestarteter Daemon läuft bis zum Neustart mit dem alten Code weiter. Die letzte Zeile zeigt das tatsächlich laufende Binary, wenn sshd über OpenRC mit der Standard-PID-Datei läuft: /usr/sbin/sshd ist der Build ohne PAM, sshd.pam der PAM-Build und sshd.krb5 der Kerberos-Build, der mit PAM-Unterstützung gebaut wird (die Alpine-Advisory behandelt diese Variante nicht).

Hinweis zur PAM-Prüfung: Der Paketname allein beweist nicht, ob PAM verwendet wird. Der OpenRC-Dienst von Alpine 3.22 wählt das Binary nach der Konfiguration: Mit GSSAPIAuthentication yes oder KerberosAuthentication yes startet er sshd.krb5, mit UsePAM yes sshd.pam, sonst sshd. Installierte Variante, gestartetes Binary und UsePAM müssen zusammenpassen. Außerdem läuft die Authentifizierungsphase seit OpenSSH 10.0 (Alpine 3.22 und neuer) in einem eigenen Binary sshd-auth, und im Alpine-Paket openssh-server-pam ist libpam an sshd-auth.pam gebunden, nicht an sshd. Ein ldd /usr/sbin/sshd | grep -i pam ist deshalb kein Test auf PAM.

Schritt 2: Ist die Passwortanmeldung aktiv?

sshd -T | grep -i -E '^(passwordauthentication|usepam|permitrootlogin|allowusers|authenticationmethods) '
sshd -T -C user=alpine,host=localhost,addr=127.0.0.1 | grep -i -E '^(passwordauthentication|usepam) '
grep -n -i -E '^[[:space:]]*(PasswordAuthentication|Match|UsePAM|Include|AllowUsers|AuthenticationMethods)' /etc/ssh/sshd_config /etc/ssh/sshd_config.d/*.conf

sshd -T zeigt die Konfiguration des aufgerufenen Binarys und braucht in der Regel Root-Rechte. Läuft sshd.pam oder sshd.krb5, rufen Sie dieses Binary statt sshd auf und übergeben Sie den Konfigurationspfad (-f) und die Startoptionen des Dienstes, sonst bildet die Ausgabe den laufenden Dienst nicht zuverlässig ab. Ohne -C werden Match-Blöcke nicht angewendet; mit -C user=...,host=...,addr=... gibt sshd -T die Konfiguration für eine konkrete Verbindung aus (sshd(8)). Passen Sie user und addr an die Konten und Quelladressen an, die Sie prüfen wollen. Bei permitrootlogin kann without-password erscheinen, der ältere Name für prohibit-password. Die dritte Zeile ist nur ein Hinweis auf Match-Blöcke, Include-Zeilen und Zugangsbeschränkungen; sie wertet weder Bedingungen von Match-Blöcken noch Includes außerhalb der angegebenen Pfade aus. Maßgeblich ist sshd -T -C. In der Standard-sshd_config des Alpine-Pakets (geprüft für 3.22) ist PasswordAuthentication nicht gesetzt, es gilt der OpenSSH-Standard yes.

Schritt 3: Gibt es Zielkonten und Salt-Quellen?

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

Die erste Zeile listet Konten, deren Feld genau * ist (mögliche Ziele). Die zweite listet Konten mit $5$- oder $6$-Hash (mögliche Salt-Quellen). Konten mit ! am Anfang des Feldes sind gesperrt und tauchen nicht auf. Beide Befehle lesen nur /etc/shadow; Benutzer aus einem Verzeichnisdienst ohne Shadow-Eintrag erscheinen dort nicht und müssen getrennt betrachtet werden.

Auswertung:

Die Auswertung ersetzt keine Einzelfallprüfung. Der Stand des laufenden Daemons, das tatsächlich gestartete Binary, die Salt-Auswahl und zusätzliche Zugangskontrollen entscheiden mit. Ob das Zielkonto sich über SSH überhaupt anmelden darf, begrenzen Direktiven wie AllowUsers. Die Beispielkonfiguration des Gitea-Images unten zeigt das.

Schritt 4: Container finden

Laufende Container, in deren Prozessliste ein sshd erscheint (docker top liest die Prozesse vom Host aus; die Alpine-Version wird mit ausgegeben):

for c in $(docker ps -q); do
  if docker top "$c" | grep -q '[s]shd'; then
    echo "$c $(docker inspect -f '{{.Config.Image}}' "$c"): sshd-Prozess, Alpine $(docker exec "$c" cat /etc/alpine-release 2>/dev/null || echo 'nein')"
  fi
done

Eigene Dockerfiles im Repository nach installiertem OpenSSH-Server durchsuchen (openssh-client wird dabei ausgenommen):

find . -type f \( -name 'Dockerfile*' -o -name '*.Dockerfile' \) -exec grep -nHEi 'openssh([^-a-z]|$)|openssh-server|sshd' {} \;

Das ist eine Suchheuristik: Kommentare, Client-Konfigurationen und andere Erwähnungen von sshd können ebenfalls treffen. Treffer prüfen Sie dann auf eine Alpine-Basis (FROM alpine, FROM node:...-alpine) und anschließend im laufenden Container mit den Schritten 1 bis 3.

Sofortmaßnahme und Update

Sofort: Passwortanmeldung abschalten. Alpine nennt das als Minimalmaßnahme, wenn das Update noch nicht möglich ist. Vorher sicherstellen, dass die Anmeldung per Schlüssel funktioniert, und die aktuelle Sitzung offen halten, bis eine neue Anmeldung getestet ist. Als Root:

mkdir -p /etc/ssh/sshd_config.d
echo 'PasswordAuthentication no' > /etc/ssh/sshd_config.d/00-no-passwords.conf
sshd -t && rc-service sshd restart
sshd -T -C user=alpine,host=localhost,addr=127.0.0.1 | grep -i passwordauthentication

Die letzte Zeile muss passwordauthentication no ausgeben. Das Drop-in wirkt nur, wenn die Konfiguration das Verzeichnis einbindet: Alpines Standard-sshd_config liest sshd_config.d ab Version 3.19, ältere Releases oder eigene Konfigurationen ignorieren es, und Match-Blöcke können die Einstellung für einzelne Verbindungen überschreiben. Prüfen Sie deshalb mit -C die Konten und Adressen, die Sie absichern wollen. Für ältere Releases und für Match-Blöcke, die die Einstellung überschreiben, nennt die Alpine-Advisory einen sed-Befehl, der PasswordAuthentication in /etc/ssh/sshd_config auf no setzt und eine Sicherung sshd_config.bak anlegt.

Danach: Update.

apk upgrade -U -a
apk list -I 'openssh*'
rc-service sshd restart

Die zweite Zeile prüft die Paketversion gegen die Tabelle. Der Neustart ist Pflicht: Alpine weist ausdrücklich darauf hin, dass das Paketupdate den laufenden Daemon nicht ersetzt. Auf Systemen ohne OpenRC erfolgt der Neustart mit dem jeweiligen Init-System, in Containern durch Neustart des Containers aus dem neuen Image.

UsePAM yes allein ist keine Ersatzmaßnahme. In der Standardvariante openssh-server ist PAM nicht einkompiliert. Wirksam sind das Update, das Abschalten der Passwortanmeldung oder der Wechsel auf openssh-server-pam mit UsePAM yes, den Alpine als nicht betroffen führt.

Container-Images neu bauen statt nur Pakete aktualisieren

Ein apk upgrade im laufenden Container ändert nur dessen beschreibbare Schicht. Das Image bleibt unverändert, und wird der Container neu erzeugt, etwa bei einem Re-Deployment, startet wieder die verwundbare Version. Für Container gilt deshalb:

1. Image ohne Build-Cache neu bauen. Ein Layer mit apk add openssh aus dem Build-Cache liefert weiterhin das alte Paket.

   docker build --pull --no-cache -t mein-image:neu .
   docker run --rm --entrypoint sh mein-image:neu -c "apk list -I 'openssh*'"
   

   Die Ausgabe muss mindestens die Version aus der Tabelle für den Alpine-Branch des Basisimages zeigen. Ein bereits laufender Container behält sein altes Image: Er muss aus dem neuen Image neu erzeugt werden. Logs, die nur im Container oder auf einem tmpfs liegen, gehen dabei verloren; sichern Sie sie vorher.

2. Fremde Images aktualisieren und Container neu erzeugen.

   docker compose pull
   docker compose up -d --force-recreate
   

   Das liefert gepatchte Pakete nur, wenn der Maintainer ein aktualisiertes Image veröffentlicht hat. Bietet er noch keines an, bleibt die Passwortanmeldung im Container aus oder das Image wird mit eigenem Dockerfile neu gebaut.

3. Alte Tags aus der eigenen Registry entfernen, damit kein Deployment sie über diesen Tag wieder zieht (Referenzen per Digest oder auf andere Tags prüfen Sie getrennt). Eine bloße Kennzeichnung verhindert den Pull nicht.

4. Den Prozess prüfen: Das Dockerfile nutzt entweder apk add ohne feste Paketversion und wird regelmäßig neu gebaut, oder es pinnt Paketversionen und hat einen geregelten Update-Prozess. Ein fest gepinntes Alpine-Tag allein hält ein Image nicht aktuell.

Der Neustart von sshd erfolgt bei Containern, sobald der Container aus dem neuen Image gestartet wird; ein rc-service-Aufruf ist dafür nicht nötig.

Coolify, Git-Server und Bastion-Container

Coolify-Hosts auf Alpine. Coolify führt Alpine Linux in der Liste unterstützter Betriebssysteme. Erkennt das Installationsskript keinen OpenSSH-Server, installiert es auf Alpine per apk add openssh das Paket openssh, das als Abhängigkeit openssh-server (ohne PAM) mitbringt, und aktiviert und startet den Dienst. Es setzt PasswordAuthentication nicht und prüft nur PermitRootLogin. Die Coolify-Dokumentation zu OpenSSH empfiehlt PubkeyAuthentication yes und PermitRootLogin prohibit-password. Läuft auf einem Coolify-Host der vom Installer nachinstallierte openssh-server, ist die erste Bedingung erfüllt. Ist SSH dagegen vorinstalliert oder wird eine andere Variante gestartet, gilt die dort laufende Variante (Prüfung wie oben). Ob der Host angreifbar ist, entscheiden die übrigen Bedingungen. In der Coolify-Community liegt dazu ein offener Hardening-Vorschlag vom 7. November 2026, der ausdrücklich nicht behauptet, dass Coolify selbst verwundbar ist. Eine Antwort der Maintainer lag am 9. November 2026 nicht vor. Läuft Coolify auf Debian oder Ubuntu (glibc, PAM), betrifft die Lücke den Host nicht.

Git-Server-Images. Das Dockerfile des offiziellen Gitea-Images (Branch main, Stand 9. November 2026; veröffentlichte Tags können abweichen) basiert auf Alpine 3.24, installiert openssh und legt den Benutzer git mit echo "git:*" | chpasswd -e an: Das Konto mit * ist also vorhanden. Die mitgelieferte sshd-Vorlage setzt aber PasswordAuthentication no, PermitRootLogin no und AllowUsers auf den Git-Benutzer. In der Standardkonfiguration fehlt damit die zweite Bedingung. Wer eine eigene sshd_config einbindet oder die Vorlage ändert, sollte genau diese Zeilen prüfen. Das Forgejo-Image folgt demselben Muster: Alpine 3.24, openssh, Benutzer git:* und eine sshd-Vorlage mit PasswordAuthentication no, PermitRootLogin no und AllowUsers.

SSH-Container für Dateiübertragung. Das Image panubo/sshd ist ein Alpine-Image mit sshd. Laut README ist die Passwortanmeldung standardmäßig aus und lässt sich über SSH_ENABLE_PASSWORD_AUTH=true einschalten. Mit aktivierter Passwortanmeldung ist eine der Voraussetzungen erfüllt; die übrigen Voraussetzungen und der Paketstand des Images entscheiden, ob es angreifbar ist.

Bastion- und Jump-Container. Hier lohnt der Blick auf die Frage, wofür die Passwortanmeldung gebraucht wird. Ein Bastion-Host, der ausschließlich Schlüssel akzeptiert, kann PasswordAuthentication no dauerhaft setzen; das empfehlen wir auch ohne SSHole.

Spuren eines Angriffs prüfen

Ein Update macht eine bereits erfolgte Anmeldung nicht rückgängig. Nach Alpine-Advisory prüfen:

grep 'Accepted password for' /var/log/messages
grep '^alpine:' /etc/shadow

Jede Zeile Accepted password for <konto>, in der <konto> ein Konto mit * ist (alpine, root, ein Schlüsselkonto, git), ist verdächtig. Zeigt der Shadow-Eintrag des Kontos * und das Log eine erfolgreiche Passwortanmeldung, kann eine Ausnutzung stattgefunden haben (BleepingComputer). Der aktuelle Shadow-Wert muss dabei nicht dem Zustand zum Zeitpunkt der Anmeldung entsprechen. Bei Containern liegen die sshd-Meldungen je nach Image im Container-Log (docker logs <container>) oder in einer Logdatei im Container. Bei einem normalen Neustart des Containers bleiben sie erhalten. Beim Entfernen und Neuerzeugen (etwa bei einem Redeployment) gehen sie verloren, sofern sie nicht auf einem Volume, einem Bind-Mount oder in einem externen Logging-System liegen; Daten in der beschreibbaren Schicht bleiben nicht erhalten, wenn der Container entfernt wird (Docker). Sichern Sie die Logs deshalb vor dem Neuerzeugen, zum Beispiel mit docker logs <container> > sshd-container.log 2>&1. Das erfasst nur die Ausgabe, die docker logs liefert; eine Logdatei im Container (etwa /var/log/messages) sichern Sie getrennt, zum Beispiel mit docker cp.

Zusätzlich prüfen (laut Alpine-Advisory):

• Nutzung von doas,
• neu angelegte Benutzer und neu angelegte oder geänderte Dateien,
• authorized_keys aller Konten auf unbekannte Schlüssel.

Über die Advisory hinaus prüfen wir außerdem die Nutzung von sudo und die ausgehenden Verbindungen des Hosts.

Previdian nennt als beobachtete Quelladresse 89.116.89[.]18. Das Fehlen dieser Adresse im Log beweist nichts, weil es nur eine einzelne Beobachtung eines Anbieters ist. Lässt sich ein Login nicht ausschließen, behandelt Alpine die Maschine als kompromittiert. Unsere Empfehlung für diesen Fall: Schlüssel, Tokens und Zugangsdaten, die auf dem Host lagen, rotieren und den Host sauber neu aufsetzen, statt einzelne Veränderungen zu suchen.

Debian, Ubuntu und Proxmox: Warum der Scanner trotzdem meldet

Der CVE-Eintrag nennt als betroffenen Bereich „OpenBSD OpenSSH vor 10.6p2“ auf der Plattform Linux. Eine Bedingung zur libc enthält die maschinenlesbare Angabe nicht. Scanner, die nur die Versionsnummer gegen den Eintrag abgleichen, können deshalb auch Debian bookworm (OpenSSH 9.2p1) und trixie (10.0p1) melden. Debian führt diese Pakete formal als „vulnerable“, stuft die Dringlichkeit aber als „unimportant“ ein. Red Hat erklärt seine Produkte für nicht betroffen.

Der Gegenfall tritt bei Alpine auf: Gepatchte Pakete behalten ihre ältere Versionsnummer (3.22 hat 10.0_p1-r11), und ein Scanner, der nur gegen 10.6p2 vergleicht, zeigt fertig gepatchte Alpine-Hosts als verwundbar.

Für beide Richtungen taugt dieselbe Vorgehensweise:

• Auf glibc-Systemen mit PAM (Debian, Ubuntu, Proxmox, RHEL) die Meldung mit der Ausgabe von ldd /usr/sbin/sshd (libc.so.6 statt ld-musl; bei Fehler oder leerer Ausgabe liegt kein Beleg vor) und der Distributions-Aussage belegen und als nicht zutreffend dokumentieren.
• Auf Alpine gegen die Paketversion je Branch aus der Tabelle prüfen, nicht gegen 10.6p2.
• Auf beiden Seiten Ausnahmen mit Datum und Quelle festhalten, damit das nächste Audit sie nachvollziehen kann.

Unser Vorgehen bei WZ-IT

• Bestandsaufnahme: Wir erfassen, wo sshd läuft: auf Hosts, VMs und in Container-Images, dazu die Basis (Alpine oder musl gegenüber Debian oder Ubuntu) und die Paketvariante mit oder ohne PAM.
• Absichern: Wir schalten die Passwortanmeldung auf betroffenen Systemen ab, testen die Anmeldung per Schlüssel und starten sshd neu.
• Aktualisieren: Wir spielen die gepatchten Pakete ein, bauen Container-Images ohne Build-Cache neu und prüfen die Paketversion im neuen Image.
• Spuren prüfen: Wir werten Logs, Konten und authorized_keys aus und rotieren bei Verdacht Schlüssel und Zugangsdaten.
• Dauerhaft überwachen: Im Managed-Betrieb gehören Updates und CVE-Monitoring dazu, das Advisories der Hersteller und Distributionen auswertet. Für Docker-Hosts übernimmt die Docker-Server-Betreuung den Linux-Host, die Container-Runtime und den vereinbarten Deployment- und Backup-Umfang. Das Server-Audit prüft bestehende Systeme einmalig.

Wissen Sie, wo in Ihrer Umgebung ein sshd läuft? Im Server-Audit erfassen wir Hosts und Container-Images mit SSH-Zugang und prüfen Basis, Paketstand und Konfiguration. Im Managed-Betrieb gehören Updates und CVE-Monitoring dazu. Erstgespräch buchen (unverbindlich und kostenlos)

Weiterführende Guides

• Coolify CVE-Übersicht 2025/2026, Sicherheitslücken in Coolify und Update-Pflichten.
• Coolify im Betrieb durch WZ-IT, Self-Hosted PaaS auf eigenen Servern.
• Warum Unternehmen CVE-Monitoring brauchen, wie Schwachstellen strukturiert verfolgt werden.
• PHP-Lücken CVE-2026-109618 und CVE-2026-109619, betroffene Software finden und Container-Images neu bauen.
• Linux-Kernel-Schwachstellen 2026, Patch-Management als Führungsaufgabe.
• Linux-Server härten: Checkliste mit CIS und BSI, SSH-Konfiguration als Teil der Härtung.
• Linux-Patch-Management, Prozess, Fristen und Nachweis.
• Managed Server-Betreuung, der Hub für Linux-Server und Docker-Hosts.
• Kernel-TCP-Lücke CVE-2026-98432: Proxmox, Debian, Ubuntu patchen - weiterer aktueller Sicherheitsfall (Stand November 2026)
• APT-Lücke CVE-2026-109518 in Debian und Ubuntu - weiterer aktueller Sicherheitsfall (Stand November 2026)
• CWPdoor: Hintertür im Control Web Panel prüfen - weiterer aktueller Sicherheitsfall (Stand November 2026)
• Node-RED-Editor ohne adminAuth: CVE-2026-58115 (Siemens IoT2050) - weiterer aktueller Sicherheitsfall (Stand November 2026)

sshd-Bestand prüfen lassen? Wir gleichen Hosts und Container-Images mit den Voraussetzungen der Lücke ab, sichern sshd ab und bauen betroffene Images neu. Termin vereinbaren

Quellen

• OpenSSH, Release Notes 10.6p2
• OpenSSH-Entwicklerliste, Ankündigung „urgent security release: 10.6p2“ (Damien Miller)
• OpenSSH Portable, Commit 4353fdc „avoid password authn bypass“
• Alpine Linux, Security Advisory: openssh-server password authentication bypass
• Alpine Linux, Releases und Support-Zeiträume
• Alpine Linux, APKBUILD openssh (3.22-stable)
• Alpine Linux, OpenRC-Dienst sshd (3.22-stable)
• CVE-Programm, CVE-2026-123158
• NVD, CVE-2026-123158
• CISA, Known Exploited Vulnerabilities Catalog
• BSI, Cybersicherheitswarnung zu OpenSSH vom 6. November 2026
• Debian Security Tracker, CVE-2026-123158
• Ubuntu, CVE-2026-123158
• Red Hat, CVE-2026-123158
• Proxmox VE, Installation und Systembasis
• OpenSSH Portable, xcrypt.c mit pick_salt() (V_10_6_P1)
• musl libc, crypt_sha512.c
• OpenBSD, sshd_config(5)
• OpenBSD, sshd(8)
• Linux man-pages, shadow(5)
• cloud-init, Modulreferenz
• FIRST, CVSS v3.1 Specification
• Docker, Storage
• Özgün Kültekin, sshhole.com
• Previdian, CVE-2026-123158
• SANS ISC: Scans for Sshole Vulnerability (CVE-2026-123158)
• Help Net Security, OpenSSH flaw exploited in the wild just hours after disclosure
• The Hacker News, Hackers Target OpenSSH SSHole Flaw Within Hours of Disclosure
• BleepingComputer, OpenSSH flaw lets attackers log into password-disabled Linux accounts
• Field Effect, OpenSSH fix for authentication bypass on Alpine Linux
• Coolify Dokumentation, Installation und unterstützte Betriebssysteme
• Coolify Dokumentation, OpenSSH konfigurieren
• Coolify, install.sh
• Coolify Discussion 12484, Harden Alpine SSH installation against CVE-2026-123158
• Gitea, Dockerfile
• Gitea, sshd_config-Vorlage für Docker
• Forgejo, Dockerfile
• Forgejo, sshd_config-Vorlage für Docker
• OpenSSH, Release Notes 10.0
• panubo/docker-sshd