OpenSSH-lek *sshole (CVE-2026-123158): controleer uw Alpine-servers

Op 5 november 2026 bracht OpenSSH versie 10.6p2 uit, met een fix voor een lek met de bijnaam *sshole. Op Alpine Linux en andere systemen met de C-bibliotheek musl accepteerde sshd elk wachtwoord van 257 tot 1.024 tekens voor een account dat helemaal geen wachtwoord heeft. De fout zit er sinds 2016 in. Het lek staat bekend als CVE-2026-123158. Draait u sshd op Alpine, controleer het dan vandaag. De meeste Docker-images zijn veilig; hieronder leest u waarom.

Hoe een lang wachtwoord een account zonder wachtwoord opent

Een account zonder wachtwoord heeft meestal * in /etc/shadow. Geen enkel wachtwoord levert als hash * op, dus niemand komt erin. Behalve op musl: de functie crypt() stopt bij wachtwoorden langer dan 256 bytes en geeft dan de tekst * terug. sshd hasht het lange wachtwoord, krijgt * terug, vergelijkt dat met de * in het shadow-bestand en laat de gebruiker binnen.

Een wijziging in sshd uit 2016 maakte dit mogelijk. Om te voorkomen dat aanvallers aan de inlogtijd zien welke gebruikersnamen bestaan, hasht sshd elke poging, zo nodig met de salt van een ander account. De ontdekker, Özgün Kültekin van Wakefield, beschrijft de hele geschiedenis op sshhole.com. Volgens de release notes ligt de oorzaak volgens OpenSSH buiten sshd, maar het project heeft toch een oplossing uitgebracht.

Wie loopt risico

Volgens Alpine moet alles hieronder kloppen:

• sshd draait op musl: Alpine, maar ook OpenWrt, Buildroot of Yocto met OpenSSH.
• sshd gebruikt geen PAM. Het standaardpakket openssh-server van Alpine heeft geen PAM.
• Inloggen met een wachtwoord staat aan. Dat is de standaard.
• Een account heeft precies * als wachtwoordveld. Een account dat met ! is vergrendeld, loopt geen risico.
• Minstens één ander account heeft een echte wachtwoordhash ($5$ of $6$).

Root heeft op Alpine sinds versie 3.16 een *, maar de standaardinstelling PermitRootLogin prohibit-password blokkeert inloggen als root met een wachtwoord. Het grootste risico zit in de officiële cloudimages van Alpine voor AWS en Azure (versies 3.18.11 tot en met 3.24.3). Daar heeft de gebruiker alpine een * en mag die zonder wachtwoord doas gebruiken, dus wie daar inlogt, is root. Bij de eerste start zijn deze images veilig. Ze worden kwetsbaar zodra een account een echt wachtwoord krijgt.

Let ook op als u alleen met sleutels werkt. Op Alpine weigert sshd zonder PAM een sleutellogin voor een account dat met ! is vergrendeld. Wij hebben dat getest: de login mislukt met “account is locked”. De gebruikelijke oplossing is de ! vervangen door *, en dat is precies de instelling waar dit lek op draait.

Geen risico lopen Debian, Ubuntu, Fedora en andere glibc-systemen, alles wat via PAM inlogt, Dropbear, en servers waarop inloggen met een wachtwoord uit staat.

Zijn Docker-images zoals python:alpine kwetsbaar?

Meestal niet, want de meeste images draaien geen SSH-server. Wij hebben de huidige images alpine, python:3-alpine, node:lts-alpine, nginx:alpine, redis:alpine en postgres:alpine bekeken. Ze gebruiken allemaal musl en hebben root:*, maar in geen ervan is sshd geïnstalleerd. python:3-slim is gebaseerd op Debian met glibc en loopt dus ook geen risico. Het veelgebruikte image linuxserver/openssh-server zet inloggen met een wachtwoord standaard uit.

Risico loopt u wel als u zelf een image bouwt met apk add openssh om in een container in te loggen. Ook dat hebben we getest: het pakket staat standaard open voor wachtwoorden en gebruikt geen PAM. Bouw zulke images opnieuw met het gerepareerde pakket. Beter nog: haal sshd eruit en gebruik docker exec.

Zo controleert u uw servers

Voer dit uit op elke Alpine-server of -container waarop sshd draait:

# Staat inloggen met een wachtwoord aan, en PAM uit?
sshd -T | grep -iE '^(passwordauthentication|usepam)'

# Accounts met precies * als wachtwoord
awk -F: '$2=="*"{print $1}' /etc/shadow

# Accounts met een echte wachtwoordhash
awk -F: '$2 ~ /^\$[56]\$/{print $1}' /etc/shadow

# Geïnstalleerde pakketversie
apk info -v openssh-server

Toont het eerste commando passwordauthentication yes en usepam no, en staan er in beide lijsten namen, dan is de server kwetsbaar tot u patcht. Alpine heeft de fix teruggezet in alle versies vanaf 3.16, bijvoorbeeld 10.3_p1-r2 op 3.24 en 10.2_p1-r1 op 3.23. De volledige tabel staat in de melding van Alpine. Vertrouw niet op sshd -V: de gepatchte pakketten van Alpine houden het oude versienummer.

Wilt u weten of iemand het lek al heeft gebruikt, zoek dan in de logs (op Alpine meestal /var/log/messages) naar Accepted password voor een account zonder wachtwoord. Elke zo’n regel betekent dat het account is overgenomen. Er zijn nog geen aanvallen gemeld, maar er staat al voorbeeldcode online.

Wat u nu doet

1. Zet inloggen met een wachtwoord uit. Dat blokkeert het lek direct, ook vóór de patch:

   echo 'PasswordAuthentication no' > /etc/ssh/sshd_config.d/00-no-passwords.conf
   sshd -t && rc-service sshd restart

   Houd uw huidige sessie open tot u hebt gecontroleerd dat een nieuwe login met uw sleutel werkt.

2. Update en herstart. Voer apk upgrade -U -a uit en daarna rc-service sshd restart. De draaiende sshd gebruikt de oude code tot hij opnieuw start.

3. Bouw images opnieuw die openssh of openssh-server installeren, en rol ze opnieuw uit.

4. Controleer de logs op wachtwoordlogins bij accounts zonder wachtwoord.

Houd SSH van het internet

Dit lek is alleen een probleem als een aanvaller uw SSH-poort kan bereiken. Is die poort niet bereikbaar, dan is een lek als dit een gewone update in plaats van een incident.

• SSH alleen via een privénetwerk. Gebruik Tailscale of WireGuard, laat sshd alleen op die interface luisteren of blokkeer poort 22 verder in de firewall. Tailscale SSH kan ook het sleutelbeheer overnemen.
• Geen inkomende poorten voor webapps. Publiceer openbare applicaties via een Cloudflare Tunnel. cloudflared legt zelf een uitgaande verbinding, dus de server heeft geen open poorten nodig. Zet beheerpagina’s achter Cloudflare Access.
• Alleen sleutels. Zet PasswordAuthentication no en KbdInteractiveAuthentication no op elke server, ook op glibc-systemen, en beperk logins met AllowUsers.
• Geen sshd in containers. Gebruik docker exec of kubectl exec.
• Test van buitenaf. Voer vanaf een ander netwerk, bijvoorbeeld de hotspot van uw telefoon, nc -vz -w 3 <publiek-ip> 22 uit. Komt er verbinding, dan staat uw SSH-poort open voor iedereen.
• Patch automatisch, en herstart. Een beveiligingsupdate helpt pas als de dienst opnieuw start.