Si tens un Alpine Linux amb sshd accessible des de fora, deixa això per després i actualitza primer: apk upgrade -U -a i rc-service sshd restart. El segon pas no és opcional, perquè actualitzar el paquet no substitueix el dimoni que ja està en marxa.
OpenSSH va publicar el 5 de novembre de 2026 la versió 10.6p2 amb una correcció urgent, i Alpine va treure el mateix dia el seu avís i paquets corregits per a totes les branques des de la 3.16. La fallada s’ha batejat com a *sshole, té l’identificador CVE-2026-123158 i permet iniciar sessió sense conèixer la contrasenya en certs comptes. La va descobrir Özgün Kültekin, de Wakefield.
Què falla
No hi ha una sola línia culpable, sinó tres decisions raonables que fa anys que encaixen malament:
- La biblioteca musl limita a 256 bytes la clau que accepten les seves funcions SHA-crypt i, quan alguna cosa falla,
crypt()retorna la cadena*en lloc d’un punter nul. Ve del 2012. - A Unix, un
*al camp de contrasenya vol dir des de fa dècades «aquest compte no entra amb contrasenya». Se suposava que mai no podria coincidir amb un hash real. - Des del 2016, per no delatar quins usuaris existeixen (CVE-2016-6210),
sshdcalcula un hash també en aquests casos fent servir la sal d’un altre compte del sistema.
Juntes, aquestes peces fan que en un sistema amb musl i sense PAM el resultat d’error de crypt() es pugui comparar amb el * emmagatzemat i donar-se per bo. D’aquí surten els deu anys del titular: la peça d’OpenSSH és del 2016. L’avís d’Alpine situa la longitud problemàtica entre 257 i 1024 bytes, i el registre del CVE parla de 256 a 1024.
OpenSSH considera que la causa arrel és fora del seu codi, però ho ha resolt al seu costat: el pedaç exigeix que el hash desat tingui una longitud mínima abans d’acceptar la comparació, de manera que un * ja no pot coincidir.
A qui afecta de debò
Alpine considera vulnerable una màquina només si es compleix tot això alhora:
- Fa servir el paquet
openssh-server, compilat sense PAM, oopenssh-server-pamambUsePAM no. - Té
PasswordAuthentication yes, que és el valor per defecte. - Hi ha un compte amb
*al camp de contrasenya: usuaris només amb clau, usuaris de directori via musl-nscd o l’usuarialpinede les imatges tiny-cloud. - Un altre compte local té un hash
$5$o$6$.
Fora d’Alpine, les fonts esmenten altres sistemes amb musl com OpenWrt, Buildroot o Yocto, sempre segons com estiguin compilats i configurats. Si mantens un firmware propi, comprova-ho en lloc de suposar-ho.
No hi estan afectats els sistemes amb glibc (Debian, Ubuntu, Fedora i companyia), els que fan servir PAM, els que tenen PasswordAuthentication no, els contenidors que no executen sshd, els comptes blocats amb ! i les imatges cloud configurades amb cloud-init, que desactiva les contrasenyes.
De debò dona root?
Això s’ha repetit molt a les xarxes i convé matisar-ho. A Alpine, root té * des de la 3.16, però el PermitRootLogin prohibit-password per defecte el protegeix llevat que hagis posat PermitRootLogin yes.
El problema real són els comptes que poden arribar a root. Les imatges tiny-cloud oficials de la 3.18.11 a la 3.24.3 porten un usuari alpine amb * i doas sense contrasenya. Són segures en la primera arrencada, però deixen de ser-ho tan bon punt apareix qualsevol hash $6$ a la màquina, per exemple en posar una contrasenya de consola.
Tampoc no és cert que n’hi hagi prou amb qualsevol Alpine: una instal·lació sense cap hash $5$ o $6$ queda fora, i el vector CVSS 3.1 la puntua amb 8,1 (alt) i complexitat alta. Dit això, Alpine adverteix que l’atac no necessita reintents i que n’hi ha prou amb arribar al port, així que no convé relaxar-se. CISA registra que ja hi ha proves de concepte públiques.
Versions corregides
| Branca d’Alpine | Paquet openssh corregit |
|---|---|
| edge | 10.6_p2-r0 |
| 3.24 | 10.3_p1-r2 |
| 3.23 | 10.2_p1-r1 |
| 3.22 | 10.0_p1-r11 |
| 3.21 | 9.9_p2-r1 |
| 3.20 | 9.7_p1-r6 |
| 3.19 | 9.6_p1-r3 |
| 3.18 | 9.3_p2-r4 |
| 3.17 | 9.1_p1-r7 |
| 3.16 | 9.0_p1-r6 |
Alpine 3.21.10, 3.22.8, 3.23.8 i 3.24.4 ja inclouen el paquet corregit. Si compiles OpenSSH pel teu compte, necessites la 10.6p2 o posterior.
Què cal fer ara
Actualitza i reinicia el servei:
apk upgrade -U -a
rc-service sshd restartSi encara no pots actualitzar, desactiva les contrasenyes. Abans, comprova que la teva clau funciona i deixa una sessió oberta fins a provar un accés nou:
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 | grep -i passwordauthenticationAquest directori només es llegeix per defecte des d’Alpine 3.19. En versions anteriors canvia la directiva a /etc/ssh/sshd_config, i revisa també els blocs Match. L’última ordre ha de retornar passwordauthentication no.
Com saber si t’han entrat
Els comptes sense contrasenya no haurien d’aparèixer mai amb un accés per contrasenya, així que comença per aquí:
grep 'Accepted password' /var/log/messagesSi hi surten comptes només amb clau, o alpine, revisa l’ús de doas, els usuaris creats, els fitxers recents i els authorized_keys. Si no pots descartar l’accés, Alpine recomana tractar la màquina com a compromesa, i la via segura és reinstal·lar-la i rotar-ne les credencials.
Com ho hem provat
Hem comprovat el comportament de la biblioteca, no l’atac: no hem llançat cap intent d’accés contra sshd. Amb un petit programa en C que crida crypt() amb una sal $6$, a alpine:3.24 (musl 1.2.6-r3) una clau de 256 bytes dona un hash normal i una de 257 retorna *. A debian:13 (glibc), la de 257 bytes continua donant un hash normal i la de 1024 retorna *0, un error que no coincideix amb el * del compte. Això encaixa amb el que diuen els avisos sobre glibc.
El que diu aquest article sobre versions i condicions surt de l’avís d’Alpine, de les notes d’OpenSSH i del codi del pedaç.
Més sobre la distribució a la fitxa d’Alpine Linux, i si vols repassar el teu servidor, a la nostra guia de claus SSH i enduriment de sshd.