# *sshole (CVE-2026-123158): la fallada d'OpenSSH a Alpine que deixa entrar sense contrasenya i què cal fer avui - **Publicat el:** 2026-11-05 - **Categoria:** Seguretat - **Pàgina original:** https://linuxgratis.com/ca/articles/openssh-sshhole-cve-2026-123158-alpine-musl OpenSSH 10.6p2 corregeix un bypass de contrasenya en sistemes amb musl i sense PAM, com Alpine. Qui està afectat de debò, quines versions ho arreglen i com revisar els registres. --- 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), `sshd` calcula 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ç](https://github.com/openssh/openssh-portable/commit/4353fdc43ef646c43a8dda7025cc1a898caf1482) 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, o `openssh-server-pam` amb `UsePAM 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'usuari `alpine` de 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.
Demostració de la fallada. L'accés directe com a root que s'hi veu només és possible amb PermitRootLogin yes · Vídeo: systemadministration.net
## 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: ```sh apk upgrade -U -a rc-service sshd restart ``` Si 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: ```sh 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 passwordauthentication ``` Aquest 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í: ```sh grep 'Accepted password' /var/log/messages ``` Si 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](/ca/alpine), i si vols repassar el teu servidor, a la nostra guia de [claus SSH i enduriment de sshd](/ca/articles/claus-ssh-enduriment-sshd-linux). ## Fonts - [Alpine Linux: avís de seguretat d'openssh-server](https://alpinelinux.org/posts/2026-11-05-openssh-password-authentication-bypass/) - [OpenSSH: notes de la versió 10.6p2](https://www.openssh.com/txt/release-10.6p2) - [Damien Miller a openssh-unix-dev: «urgent security release: 10.6p2»](https://marc.info/?l=openssh-unix-dev&m=179388064263131&w=2) - [Commit de la correcció a openssh-portable](https://github.com/openssh/openssh-portable/commit/4353fdc43ef646c43a8dda7025cc1a898caf1482) - [NVD: CVE-2026-123158](https://nvd.nist.gov/vuln/detail/CVE-2026-123158) - [sshhole.com: anàlisi d'Özgün Kültekin](https://sshhole.com/)