Ing. Calogero Bono
Op 5 november 2026 verscheen OpenSSH 10.6p2, dat een bug met de naam «*sshole» verhelpt. De bug raakt SSH-servers op Linux die de musl-bibliotheek gebruiken, zoals Alpine Linux, met PAM uitgeschakeld. Wie de SSH-poort bereikt, kan zonder wachtwoord in een account komen door een heel lang wachtwoord te sturen. Dat telt, omdat één verbinding al genoeg is en omdat de officiële Alpine-cloudimages root-toegang kunnen geven.
Een paar termen voordat we naar de feiten gaan. musl is een alternatieve C-bibliotheek voor glibc, gebruikt door Alpine, OpenWrt, Buildroot en Yocto. crypt() is de functie die een wachtwoord omzet in zijn hash. PAM is het modulaire authenticatiesysteem van Linux. /etc/shadow is het bestand dat de wachtwoordhashes bewaart. doas is een hulpprogramma, vergelijkbaar met sudo, om root-rechten te krijgen.
Hoe werkt de *sshole-bug?
Een Linux-account zonder wachtwoord heeft een asterisk in plaats van de hash in /etc/shadow. Geen enkel wachtwoord zou het moeten openen. Volgens BleepingComputer laat een wijziging in OpenSSH uit 2016, bedoeld om CVE-2016-6210 over het opsommen van gebruikers te verhelpen, de hash ook voor deze accounts berekenen.
Hier komt musl in beeld. Zoals de melding van Alpine uitlegt, geeft crypt() van musl * terug als foutsignaal wanneer de sleutel groter is dan 256 bytes. Die asterisk komt overeen met die in het account opgeslagen, en de vergelijking slaagt. De onderzoeker Özgün Kültekin zegt dat het defect sinds 2016 bestaat.
Wie loopt echt risico?
Er moeten meerdere voorwaarden samenvallen. Volgens Alpine is het openssh-server-pakket zonder PAM gecompileerd, of gebruik je openssh-server-pam met UsePAM no. PasswordAuthentication moet aan staan, zoals standaard. Er is een account met * nodig en minstens één ander met een $5$- of $6$-hash. Eén gebruiker met een wachtwoord is genoeg om alle andere bereikbaar te maken.
Alpine heeft de versies 3.21 tot 3.24 en edge gecontroleerd, plus de oudere 3.16-3.20. Niet geraakt worden containers zonder sshd, systemen met PasswordAuthentication no en systemen met PAM actief. Debian, Ubuntu en Fedora, die glibc gebruiken, zijn niet kwetsbaar, schrijft BleepingComputer.
Waarom zijn de Alpine-cloudimages zorgwekkend?
De officiële tiny-cloud-images, van 3.18.11 tot 3.24.3, hebben een gebruiker alpine met wachtwoord * en doas zonder wachtwoord. Alpine preciseert dat ze bij de eerste start veilig zijn. Ze worden uitbuitbaar wanneer er een $6$-hash verschijnt, bijvoorbeeld als een beheerder een consolewachtwoord instelt of als user-data een gebruiker toevoegt met hashed_passwd.
Dan krijgt de aanvaller een shell als alpine en wordt hij met doas root. Images geconfigureerd met cloud-init, die PasswordAuthentication no schrijven, worden niet geraakt. Voor root beschermt de standaardinstelling PermitRootLogin prohibit-password alleen op directe wijze.
Hoe corrigeer je het en hoe controleer je een aanval?
De oplossing zit in OpenSSH 10.6p2. Op Alpine gebruik je apk upgrade -U -a en start je daarna sshd opnieuw, omdat de update de draaiende daemon niet vervangt. Alpine heeft gecorrigeerde pakketten gepubliceerd tot en met 3.16, ook voor niet langer ondersteunde releases.
Als je niet kunt bijwerken, zet dan PasswordAuthentication no en herstart sshd, nadat je hebt gecontroleerd dat inloggen met een sleutel werkt. Om sporen te zoeken, kijk je in /var/log/messages naar de regels «Accepted password» voor accounts zonder wachtwoord. Alpine voegt toe dat je de machine als gecompromitteerd moet beschouwen als je een toegang niet kunt uitsluiten. Voor de rechten op accounts geldt ook de gids over Linux-rechten.
Beperkingen om te kennen
Alpine meldt dat op het moment van publiceren nog geen CVE was toegekend. OpenSSH schrijft dat de oorzaak buiten sshd ligt, maar dat de bug via sshd uitbuitbaar is en daar wordt tegengehouden. Er zijn geen gegevens over echte aanvallen die nu plaatsvinden. De uitspraken over de 17.600 tests met AI-agents komen van de onderzoeker, via BleepingComputer, en zijn niet onafhankelijk geverifieerd.
Wat verandert er voor wie met digitale techniek werkt
Beheer je Alpine-servers, OpenWrt-routers of embedded systemen met Yocto en Buildroot, controleer dan of sshd wachtwoorden toestaat en of er accounts met * zijn. Veel mensen gebruiken Alpine in containers zonder sshd en zijn niet geraakt. Wie cloudmachines draait met de tiny-cloud-images moet elke al draaiende instantie nakijken. Een beheerde server met regelmatige updates beperkt dit soort risico's, we schreven erover op de pagina over hosting en beheerde servers. Het is ook zinvol de verwante zaak van door AI gegenereerde exploits in de gaten te houden, waarover we schreven in dit artikel.
Ons oordeel
Deze zaak laat zien hoe broos de grens is tussen componenten die elkaar vertrouwen. OpenSSH voegde in 2016 een legitieme verdediging toe, musl koos een gangbare foutwaarde, en samen openden ze tien jaar lang een deur. Opvallend is ook dat de bug is gevonden met AI-agents. OpenSSH zelf waarschuwt dat bugs die met AI zijn gevonden vaak door anderen opnieuw worden ontdekt, dus wachten is een risico. De sterkste remedie blijft wat hij altijd was – sleutels in plaats van wachtwoorden.
Veelgestelde vragen
Zijn Debian en Ubuntu kwetsbaar voor *sshole?
Nee. Ze gebruiken glibc en niet de musl-bibliotheek. BleepingComputer bevestigt dat systemen met PAM-authenticatie niet kwetsbaar zijn, maar Alpine preciseert dat openssh-server-pam met UsePAM no het ook niet is, terwijl met UsePAM yes wel.
Is het genoeg het openssh-pakket bij te werken?
Nee, je moet ook sshd herstarten. Alpine preciseert dat de update de daemon die al draait niet vervangt, waardoor de kwetsbare versie actief zou blijven.
Kan ik mezelf beschermen zonder bij te werken?
Ja, tijdelijk. Zet PasswordAuthentication no in de configuratie van sshd en herstart de service. Controleer eerst of inloggen met een sleutel werkt.
Is root ook blootgesteld?
Alleen in bepaalde gevallen. Met PermitRootLogin prohibit-password, de standaardinstelling, is root niet rechtstreeks bereikbaar. Dat verandert als PermitRootLogin yes actief is of als een andere gebruiker root kan worden, bijvoorbeeld via doas.
Bestaat er een CVE voor deze bug?
Nog niet, volgens Alpine. De melding zegt dat er bij het schrijven nog geen identificatie was toegekend. De referentie zijn de release-notes van OpenSSH 10.6p2.
Wat je na OpenSSH 10.6p2 moet volgen
OpenSSH kondigde vaker kleine releases aan om correcties sneller bij gebruikers te krijgen. De bug laat nog een paar vragen open die je moet volgen.
- Controleer of er een CVE wordt toegekend en of je scanners die zullen herkennen.
- Houd in de gaten wanneer fabrikanten van firmware op basis van OpenWrt, Buildroot en Yocto updates publiceren.
- Bereid een routine voor om kleine OpenSSH-releases te installeren zonder op geplande versies te wachten.
