# *sshole (CVE-2026-123158): el fallo de OpenSSH en Alpine que deja entrar sin contraseña y qué hacer hoy - **Publicado el:** 2026-11-05 - **Categoría:** Seguridad - **Página original:** https://linuxgratis.com/articulos/openssh-sshhole-cve-2026-123158-alpine-musl OpenSSH 10.6p2 corrige un bypass de contraseña en sistemas con musl y sin PAM, como Alpine. Quién está afectado de verdad, qué versiones lo arreglan y cómo revisar tus logs. --- Si tienes un Alpine Linux con `sshd` accesible desde fuera, deja esto para luego y actualiza primero: `apk upgrade -U -a` y `rc-service sshd restart`. Lo segundo no es opcional, porque actualizar el paquete no sustituye al demonio que ya está en marcha. OpenSSH publicó el 5 de noviembre de 2026 la versión 10.6p2 con un arreglo urgente, y Alpine sacó el mismo día su aviso y paquetes corregidos para todas sus ramas desde la 3.16. El fallo se ha bautizado como *sshole, tiene el identificador CVE-2026-123158 y permite iniciar sesión sin conocer la contraseña en ciertas cuentas. Lo descubrió Özgün Kültekin, de Wakefield. ## Qué falla No hay una sola línea culpable, sino tres decisiones razonables que llevan años encajando mal: - La biblioteca musl limita a 256 bytes la clave que aceptan sus funciones SHA-crypt y, cuando algo falla, `crypt()` devuelve la cadena `*` en lugar de un puntero nulo. Viene de 2012. - En Unix, un `*` en el campo de contraseña significa desde hace décadas «esta cuenta no entra con contraseña». Se asumía que nunca podría coincidir con un hash real. - Desde 2016, para no delatar qué usuarios existen (CVE-2016-6210), `sshd` calcula un hash también en esos casos usando la sal de otra cuenta del sistema. Juntas, esas piezas hacen que en un sistema con musl y sin PAM el resultado de error de `crypt()` pueda compararse con el `*` almacenado y darse por bueno. De ahí salen los diez años del titular: la pieza de OpenSSH es de 2016. El aviso de Alpine sitúa la longitud problemática entre 257 y 1024 bytes, y el registro del CVE habla de 256 a 1024. OpenSSH considera que la causa raíz está fuera de su código, pero lo ha resuelto en su lado: el [parche](https://github.com/openssh/openssh-portable/commit/4353fdc43ef646c43a8dda7025cc1a898caf1482) exige que el hash guardado tenga una longitud mínima antes de aceptar la comparación, de modo que un `*` ya no puede coincidir. ## A quién afecta de verdad Alpine considera vulnerable una máquina solo si se cumple todo esto a la vez: - Usa el paquete `openssh-server`, compilado sin PAM, o `openssh-server-pam` con `UsePAM no`. - Tiene `PasswordAuthentication yes`, que es el valor por defecto. - Hay una cuenta con `*` en el campo de contraseña: usuarios solo con clave, usuarios de directorio vía musl-nscd o el usuario `alpine` de las imágenes tiny-cloud. - Otra cuenta local tiene un hash `$5$` o `$6$`. Fuera de Alpine, las fuentes mencionan otros sistemas con musl como OpenWrt, Buildroot o Yocto, siempre según cómo estén compilados y configurados. Si mantienes un firmware propio, compruébalo en lugar de suponer. **No están afectados** los sistemas con glibc (Debian, Ubuntu, Fedora y compañía), los que usan PAM, los que tienen `PasswordAuthentication no`, los contenedores que no ejecutan `sshd`, las cuentas bloqueadas con `!` y las imágenes cloud configuradas con cloud-init, que desactiva las contraseñas. ## ¿De verdad da root? Eso se ha repetido mucho en redes y conviene matizarlo. En Alpine, `root` tiene `*` desde la 3.16, pero el `PermitRootLogin prohibit-password` por defecto lo protege salvo que hayas puesto `PermitRootLogin yes`. El problema real está en las cuentas que pueden llegar a root. Las imágenes tiny-cloud oficiales de 3.18.11 a 3.24.3 traen un usuario `alpine` con `*` y `doas` sin contraseña. Son seguras en el primer arranque, pero dejan de serlo en cuanto aparece cualquier hash `$6$` en la máquina, por ejemplo al poner una contraseña de consola. Tampoco es cierto que baste con cualquier Alpine: una instalación sin ningún hash `$5$` o `$6$` queda fuera, y el vector CVSS 3.1 lo puntúa con 8,1 (alto) y complejidad alta. Dicho esto, Alpine advierte de que el ataque no necesita reintentos y que basta con alcanzar el puerto, así que no conviene relajarse. CISA registra que ya hay pruebas de concepto públicas.
Demostración del fallo. El acceso directo como root que se ve solo es posible con PermitRootLogin yes · Vídeo: systemadministration.net
## Versiones corregidas | Rama de Alpine | Paquete `openssh` corregido | |---|---| | 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 y 3.24.4 ya incluyen el paquete corregido. Si compilas OpenSSH por tu cuenta, necesitas 10.6p2 o posterior. ## Qué hacer ahora Actualiza y reinicia el servicio: ```sh apk upgrade -U -a rc-service sshd restart ``` Si no puedes actualizar todavía, desactiva las contraseñas. Antes, comprueba que tu clave funciona y deja una sesión abierta hasta probar un acceso nuevo: ```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 ``` Ese directorio solo se lee por defecto desde Alpine 3.19. En versiones anteriores cambia la directiva en `/etc/ssh/sshd_config`, y revisa también los bloques `Match`. La última orden debe devolver `passwordauthentication no`. ## Cómo saber si te han entrado Las cuentas sin contraseña no deberían aparecer jamás con un acceso por contraseña, así que empieza por ahí: ```sh grep 'Accepted password' /var/log/messages ``` Si salen cuentas solo con clave, o `alpine`, revisa el uso de `doas`, los usuarios creados, los ficheros recientes y los `authorized_keys`. Si no puedes descartar el acceso, Alpine recomienda tratar la máquina como comprometida, y la vía segura es reinstalarla y rotar sus credenciales. ## Cómo lo hemos probado Hemos comprobado el comportamiento de la biblioteca, no el ataque: no hemos lanzado ningún intento de acceso contra `sshd`. Con un pequeño programa en C que llama a `crypt()` con una sal `$6$`, en `alpine:3.24` (musl 1.2.6-r3) una clave de 256 bytes da un hash normal y una de 257 devuelve `*`. En `debian:13` (glibc), la de 257 bytes sigue dando un hash normal y la de 1024 devuelve `*0`, un error que no coincide con el `*` de la cuenta. Eso encaja con lo que dicen los avisos sobre glibc. Lo que dice este artículo sobre versiones y condiciones sale del aviso de Alpine, de las notas de OpenSSH y del código del parche. Más sobre la distribución en la ficha de [Alpine Linux](/alpine), y si quieres repasar tu servidor, en nuestra guía de [claves SSH y endurecimiento de sshd](/articulos/claves-ssh-endurecer-sshd-linux). ## Fuentes - [Alpine Linux: aviso de seguridad de openssh-server](https://alpinelinux.org/posts/2026-11-05-openssh-password-authentication-bypass/) - [OpenSSH: notas de la versión 10.6p2](https://www.openssh.com/txt/release-10.6p2) - [Damien Miller en openssh-unix-dev: «urgent security release: 10.6p2»](https://marc.info/?l=openssh-unix-dev&m=179388064263131&w=2) - [Commit del arreglo en 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álisis de Özgün Kültekin](https://sshhole.com/)