OpenSSH 10.6p2 corrige una omisión de contraseña en Alpine Linux

Alpine Linux y el proyecto OpenSSH publicaron el 5 de noviembre de 2026 correcciones para un fallo que permite entrar por SSH a algunos servidores Alpine sin ninguna contraseña. Quien use el servidor SSH predeterminado de Alpine con el acceso por contraseña activado debe actualizarlo y reiniciarlo hoy.

La falla "requiere una sola conexión, funciona siempre y no necesita reintentos", según el aviso de seguridad de Alpine. La reportó Özgün Kültekin, de Wakefield. No había número CVE asignado cuando Alpine publicó el aviso, y ninguno de los dos proyectos informa de ataques.

Cómo funciona la omisión de contraseña

El fallo está donde OpenSSH se cruza con musl, la pequeña biblioteca de C que Alpine usa en lugar de glibc. Solo aparece cuando sshd, el servidor SSH, funciona sin PAM. PAM es el sistema de inicio de sesión común que usan la mayoría de las distribuciones de Linux.

Sin PAM, sshd calcula el hash del intento de contraseña con crypt(). Luego compara el resultado con la entrada de la cuenta en /etc/shadow. Alpine explica que el crypt() de musl devuelve * como error para claves de más de 256 bytes. Una cuenta sin contraseña guarda ese mismo *. Por eso una contraseña de 257 a 1.024 bytes "coincide". Una cuenta sin una sal utilizable toma prestada la sal de otra cuenta. La sal es el texto aleatorio que hace único cada hash. Por eso una cuenta local necesita un hash real $5$ o $6$.

Las notas de la versión OpenSSH 10.6p2 llaman a la actualización "una solución de seguridad crítica" y sitúan la causa "fuera de sshd". Llega después de OpenSSH 10.6, que salió en octubre con firmas poscuánticas.

El análisis de Kültekin llama al fallo "sshhole" y lo remonta a dos commits de musl de agosto de 2012. De unos 17.600 inicios de sesión de prueba, solo musl sin PAM se comportó de forma distinta. El análisis también nombra OpenWrt, Buildroot y Yocto. Alpine y OpenSSH no los mencionan.

A quién afecta, según el aviso de Alpine

Una máquina solo está expuesta cuando se cumplen las cuatro condiciones:

• sshd viene del paquete openssh-server, compilado sin PAM, o de openssh-server-pam con UsePAM no.
• PasswordAuthentication está en yes, el valor predeterminado.
• Una cuenta tiene * en el campo de contraseña, como root, un usuario que solo usa claves o un usuario de directorio que llega de sssd.
• Al menos una cuenta local tiene un hash $5$ o $6$.

Los contenedores que no ejecutan sshd están a salvo, igual que las cuentas bloqueadas marcadas con !. El ajuste predeterminado PermitRootLogin prohibit-password bloquea el acceso de root con contraseña. Pero no protege una cuenta que puede convertirse en root con doas. Las imágenes tiny-cloud de Alpine, de la 3.18.11 a la 3.24.3, traen justo un usuario alpine así, con * y doas sin contraseña.

Prueba: cinco imágenes de Alpine y sus valores predeterminados

En una prueba de Tech AI Wire del 5 de noviembre, en macOS 26.6.2 con Docker 28.4.0, las imágenes oficiales de alpine instalaron openssh-server desde los espejos actuales de Alpine.

Rama	Versión de la imagen (compilada)	Paquete instalado	Versión corregida de Alpine	sshd -V
3.21	3.21.9 (21 oct.)	9.9_p2-r1	9.9_p2-r1	OpenSSH_9.9p2
3.22	3.22.7 (21 oct.)	10.0_p1-r11	10.0_p1-r11	OpenSSH_10.0p2
3.23	3.23.7 (21 oct.)	10.2_p1-r1	10.2_p1-r1	OpenSSH_10.2p1
3.24	3.24.3 (21 oct.)	10.3_p1-r2	10.3_p1-r2	OpenSSH_10.3p1
edge	3.25.0_alpha20260805 (6 ago.)	10.6_p2-r0	10.6_p2-r0	OpenSSH_10.6p2

Cuatro resultados importan:

• Las instalaciones nuevas reciben la corrección, pero las imágenes son anteriores. Cada una indica una versión inferior a las corregidas 3.21.10, 3.22.8, 3.23.8 y 3.24.4. Las ramas estables llevan la corrección dentro de versiones antiguas de OpenSSH. Así que revise la revisión del paquete, no sshd -V.
• Los valores predeterminados cumplen tres condiciones. Las cinco funcionan con PasswordAuthentication yes y tienen root:*. En 3.24, el sshd predeterminado rechazó UsePAM yes como "Unsupported option". El programa aparte sshd.pam, del paquete openssh-server-pam, seguía mostrando usepam no en 3.21 y 3.24.
• Una imagen nueva no cumple la cuarta. Ninguna cuenta tiene un hash $5$ o $6$ hasta que alguien pone una contraseña. Una sola llamada a chpasswd escribió un hash $6$.
• Hacer que funcione un usuario que solo usa claves crea una cuenta *. En 3.24, adduser -D appuser escribió !, y sshd rechazó su clave: "User appuser not allowed because account is locked". El passwd -u de BusyBox dejó el ! en su sitio. Tras usermod -p '*', el acceso con clave funcionó.

Cómo revisar y corregir un servidor Alpine

Tres comandos muestran en qué estado está un servidor. En 3.24, la prueba mostró:

$ apk list -I "openssh-server*"
openssh-server-10.3_p1-r2 aarch64 {openssh} (SSH-OpenSSH) [installed]
openssh-server-common-10.3_p1-r2 aarch64 {openssh} (SSH-OpenSSH) [installed]
$ sshd -T | grep -i passwordauthentication
passwordauthentication yes
$ awk -F: '$2=="*" {print $1}' /etc/shadow
root

Un paquete más antiguo que la versión corregida de la tabla necesita la actualización. Alpine también corrigió las ramas sin soporte, de la 3.16 a la 3.20. Ejecute apk upgrade -U -a y luego rc-service sshd restart. "Actualizar solo el paquete no reemplaza el demonio en ejecución", advierte el aviso.

Si la actualización tiene que esperar, la solución temporal de Alpine es un archivo, /etc/ssh/sshd_config.d/00-no-passwords.conf, que contenga PasswordAuthentication no. Compruebe antes que el acceso con clave funciona y mantenga abierta la sesión actual. En la prueba, ese archivo cambió sshd -T de yes a no en 3.21 y 3.24. Después, busque en /var/log/messages líneas "Accepted password for" de una cuenta sin contraseña.

Qué significa para los desarrolladores

Busque openssh-server en los Dockerfiles. Las imágenes que ejecutan sshd para runners de CI o desarrollo remoto son las que entran en juego. Reconstrúyalas con docker build --pull --no-cache, para que una capa en caché de antes del 5 de noviembre no traiga de vuelta el paquete antiguo.

Haga de PasswordAuthentication no el valor predeterminado en cualquier máquina Alpine que solo necesite claves. Alpine dice que actualizar o desactivar el acceso por contraseña "cierra el agujero". La prueba muestra por qué importa ese ajuste: la forma habitual de dar acceso a un usuario que solo usa claves crea la cuenta * que este fallo necesita.

Esté atento a un número CVE y a lo que digan OpenWrt, Buildroot y Yocto sobre cuáles de sus compilaciones están expuestas. El equipo de OpenSSH también dice que por ahora publicará versiones con más frecuencia.