Ing. Calogero Bono
El 5 de noviembre de 2026 salió OpenSSH 10.6p2, que corrige un fallo bautizado como «*sshole». Afecta a los servidores SSH en Linux que usan la biblioteca musl, como Alpine Linux, con PAM desactivado. Quien llega al puerto SSH puede entrar en una cuenta sin contraseña enviando una contraseña muy larga. Importa porque basta una conexión y porque las imágenes cloud oficiales de Alpine pueden dar acceso como root.
Algunos términos, antes de entrar en los hechos. musl es una biblioteca C alternativa a glibc, usada por Alpine, OpenWrt, Buildroot y Yocto. crypt() es la función que transforma una contraseña en su hash. PAM es el sistema modular de autenticación de Linux. /etc/shadow es el archivo que guarda los hashes de las contraseñas. doas es la herramienta, similar a sudo, para obtener privilegios de root.
¿Cómo funciona el fallo *sshole?
Una cuenta Linux sin contraseña tiene un asterisco en lugar del hash en /etc/shadow. Ninguna contraseña debería abrirla. Según BleepingComputer, un cambio en OpenSSH de 2016, nacido para corregir la CVE-2016-6210 sobre la enumeración de usuarios, hace que se calcule también el hash para estas cuentas.
Aquí entra musl. Como explica el aviso de Alpine, la crypt() de musl devuelve * como señal de error si la clave supera los 256 bytes. Ese asterisco coincide con el guardado en la cuenta, y la comparación tiene éxito. El investigador Özgün Kültekin dice que el defecto existe desde 2016.
¿Quién está realmente en riesgo?
Hacen falta varias condiciones a la vez. Según Alpine, el paquete openssh-server se compila sin PAM, o se usa openssh-server-pam con UsePAM no. PasswordAuthentication debe estar activo, como es el valor predeterminado. Hace falta una cuenta con * y al menos otra con hash $5$ o $6$. Basta un solo usuario con contraseña para hacer alcanzables a todos los demás.
Alpine ha verificado las versiones desde la 3.21 hasta la 3.24 y edge, además de las antiguas 3.16-3.20. No están afectados los contenedores sin sshd, los sistemas con PasswordAuthentication no y los sistemas con PAM activa. Debian, Ubuntu y Fedora, que usan glibc, no son vulnerables, según BleepingComputer.
¿Por qué preocupan las imágenes cloud de Alpine?
Las imágenes oficiales tiny-cloud, de la 3.18.11 a la 3.24.3, tienen un usuario alpine con contraseña * y doas sin contraseña. Alpine precisa que son seguras en el primer arranque. Se vuelven explotables cuando aparece un hash $6$, por ejemplo si un administrador establece una contraseña de consola o si user-data añade un usuario con hashed_passwd.
En ese punto el atacante obtiene una shell como alpine y, con doas, se convierte en root. Las imágenes configuradas con cloud-init, que escribe PasswordAuthentication no, no se ven afectadas. Para root, el valor predeterminado PermitRootLogin prohibit-password lo protege solo de forma directa.
¿Cómo se corrige y cómo se comprueba un ataque?
La corrección está en OpenSSH 10.6p2. En Alpine se usa apk upgrade -U -a, y después se reinicia sshd, porque la actualización no sustituye el demonio ya en ejecución. Alpine ha publicado paquetes corregidos hasta la 3.16, incluso para las versiones que ya no tienen soporte.
Si no puedes actualizar, pon PasswordAuthentication no y reinicia sshd, después de comprobar que el acceso con clave funciona. Para buscar rastros, revisa en /var/log/messages las líneas «Accepted password» de cuentas sin contraseña. Alpine añade que, si no puedes descartar un acceso, la máquina debe considerarse comprometida. Para los permisos de las cuentas también sirve la guía sobre permisos en Linux.
Límites que conviene conocer
Alpine indica que en el momento de la publicación no se había asignado ningún CVE. OpenSSH escribe que la causa está fuera de sshd, pero es explotable a través de sshd y allí se evita. No hay datos sobre ataques reales en curso. Las afirmaciones sobre las 17.600 pruebas con agentes de IA provienen del investigador, citadas por BleepingComputer, y no están verificadas de forma independiente.
Qué cambia para quien trabaja con lo digital
Si gestionas servidores Alpine, routers OpenWrt o sistemas embebidos con Yocto y Buildroot, comprueba si sshd permite contraseñas y si hay cuentas con *. Muchos usan Alpine en contenedores sin sshd y no están afectados. Quien mantenga máquinas cloud con las imágenes tiny-cloud debe verificar cada instancia ya en ejecución. Un servidor gestionado con actualizaciones periódicas reduce este tipo de riesgo, de lo que hablamos en la página sobre alojamiento y servidores gestionados. Conviene también seguir el caso relacionado de los exploits generados por IA, del que escribimos en este artículo.
Nuestra opinión
El caso muestra lo frágil que es la frontera entre componentes que confían unos en otros. OpenSSH añadió una defensa legítima en 2016, musl eligió un valor de error común, y juntos abrieron una puerta durante diez años. También llama la atención que el fallo se encontrara con agentes de IA. La propia OpenSSH advierte de que los fallos hallados con IA suelen ser redescubiertos por otros, así que esperar es un riesgo. La solución más sólida sigue siendo la de siempre – claves en lugar de contraseñas.
Preguntas frecuentes
¿Debian y Ubuntu son vulnerables a *sshole?
No. Usan glibc y no la biblioteca musl. BleepingComputer confirma que los sistemas con autenticación PAM no son vulnerables, pero Alpine precisa que openssh-server-pam con UsePAM no sí lo es, mientras que con UsePAM yes no.
¿Basta con actualizar el paquete openssh?
No, también hay que reiniciar sshd. Alpine precisa que la actualización no sustituye el demonio ya en ejecución, así que la versión vulnerable seguiría activa.
¿Puedo protegerme sin actualizar?
Sí, de forma temporal. Pon PasswordAuthentication no en la configuración de sshd y reinicia el servicio. Antes comprueba que el acceso con clave funciona.
¿También está expuesto root?
Solo en ciertos casos. Con PermitRootLogin prohibit-password, el valor predeterminado, root no es accesible directamente. Lo es si está activo PermitRootLogin yes o si otro usuario puede convertirse en root, por ejemplo con doas.
¿Hay un CVE para este fallo?
Todavía no, según Alpine. El aviso dice que en el momento de escribirlo no se había asignado ningún identificador. La referencia son las notas de OpenSSH 10.6p2.
Qué seguir después de OpenSSH 10.6p2
OpenSSH ha anunciado lanzamientos más frecuentes para llevar las correcciones a los usuarios más rápido. El fallo deja abiertas algunas cuestiones que conviene seguir.
- Comprueba si se asignará un CVE y si tus herramientas de escaneo lo reconocerán.
- Verifica cuándo los fabricantes de firmware basados en OpenWrt, Buildroot y Yocto publicarán actualizaciones.
- Prepara una rutina para instalar las versiones menores de OpenSSH sin esperar a las versiones programadas.
