Alpine Linux: fallo en OpenSSH permite login sin clave

Alpine Linux publicó el 5 de noviembre de 2026 un aviso de seguridad crítico: un fallo en openssh-server permite a un atacante iniciar sesión sin conocer ninguna contraseña. Basta una sola conexión, funciona siempre y no necesita reintentos. Si tu equipo corre sshd sobre Alpine, la ventana de exposición no se cierra solo con actualizar el paquete: el demonio en ejecución sigue siendo el viejo hasta que lo reinicies.

Para un founder con infraestructura en producción, el problema no es solo técnico. Es la diferencia entre un servidor con llaves SSH y un servidor con las puertas abiertas, sin logs de intentos fallidos que delaten el acceso.

¿Qué hace exactamente esta vulnerabilidad de OpenSSH?

El atacante que puede alcanzar el puerto SSH entra sin contraseña. Las condiciones son dos y son comunes en servidores reales:

¿Y esto cómo se aplica en tu negocio?

Dueños de negocio de Latinoamérica y España usan un agente de IA para ganar más y recuperar su tiempo. El Kit «tu mano derecha con IA» te muestra cómo en un video de 11 minutos, con una ficha para armar el tuyo. CAR está cerrada por ahora; al anotarte, te avisamos cuando abra.

👥 Quiero el Kit →

Necesita el nombre de una cuenta cuyo campo de contraseña sea *, es decir una cuenta sin contraseña configurada, algo habitual en cuentas de solo llave.
Necesita que la máquina tenga al menos otra cuenta con un hash de contraseña $5$ o $6$ .

Con eso, envía una contraseña muy larga, de entre 257 y 1024 bytes. Una sola cuenta con contraseña alcanza para que todas las cuentas sin ella queden accesibles. Alpine aclara que no se había asignado un identificador CVE al momento de publicar el aviso; los detalles técnicos están en las notas de la versión OpenSSH 10.6p2.

¿Está tu servidor Alpine afectado? Las condiciones exactas

Estás afectado solo si se cumplen todas estas condiciones a la vez:

Corres el paquete openssh-server de Alpine, que se compila sin PAM, o corres openssh-server-pam con UsePAM no.
PasswordAuthentication está en yes, que es el valor por defecto de OpenSSH salvo que lo hayas cambiado.
La máquina tiene una cuenta con el campo de contraseña en *. Esto incluye a root, que viene como root:* en la imagen base desde aproximadamente Alpine 3.16; también cualquier usuario de solo llave creado con adduser sin contraseña o con usermod -p '*'; los usuarios que llegan por un servicio de directorio a través de musl-nscd (nslcd, winbind, sssd), que no tienen entrada en shadow; y el usuario alpine de las imágenes oficiales tiny-cloud.
Al menos una cuenta local tiene un hash de contraseña $5$ o $6$ .

Ojo con un detalle que suele leerse mal: el valor por defecto PermitRootLogin prohibit-password de OpenSSH protege a root, así que root solo es alcanzable si pusiste PermitRootLogin yes. Eso no ayuda si otra cuenta que sí puede entrar es capaz de escalar a root, por ejemplo a través de doas.

Las ramas afectadas son todas las que Alpine revisó: 3.21 a 3.24 y edge, más las versiones antiguas que ya no reciben actualizaciones regulares, de 3.16 a 3.20.

¿Quién no está afectado?

Usuarios de Docker y otros contenedores que no corren sshd dentro del contenedor.
Sistemas con PasswordAuthentication no.
Sistemas con openssh-server-pam y UsePAM yes.
Cuentas bloqueadas, las que tienen ! como campo de contraseña en /etc/shadow (una línea que empieza user:!:): no pueden entrar ni con contraseña ni con llave.
Sistemas donde ninguna cuenta tiene un hash de contraseña con formato $.
Imágenes de nube configuradas con cloud-init, que escribe PasswordAuthentication no.

Cómo parchear Alpine Linux: los dos caminos

1. Actualizar y reiniciar el demonio

El comando es apk upgrade -U -a. Las versiones 3.21.10, 3.22.8, 3.23.8 y 3.24.4 contienen el paquete corregido. Las versiones fijas por rama son: 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 y 3.16 9.0_p1-r6.

Después hay que reiniciar con rc-service sshd restart. Actualizar el paquete no reinicia un sshd que ya está corriendo, y ese es el error más fácil de cometer en un despliegue apurado.

2. Si no puedes actualizar: desactivar la autenticación por contraseña

Antes de tocar nada, verifica que tu acceso por llave SSH funciona y mantén la sesión actual abierta hasta haber probado un login nuevo. Los comandos, como root, crean un archivo drop-in, reescriben cada línea PasswordAuthentication en /etc/ssh/sshd_config y guardan el original como respaldo:

mkdir -p /etc/ssh/sshd_config.d
echo 'PasswordAuthentication no' > /etc/ssh/sshd_config.d/00-no-passwords.conf
sed -i.bak -e '1i PasswordAuthentication no' \
  -e 's/^\(\s*PasswordAuthentication[^y#]*\)yes/\1no/i' \
  /etc/ssh/sshd_config
sshd -t && rc-service sshd restart
sshd -T | grep -i passwordauthentication

El último comando debe imprimir passwordauthentication no. Alpine advierte que el directorio drop-in se lee por defecto desde la 3.19 en adelante; en releases anteriores se ignora, y por eso el sed sobre el archivo principal es parte del procedimiento. Para revertir, borra el drop-in y restaura el respaldo.

Imágenes tiny-cloud: el riesgo que aparece después del primer arranque

Las imágenes oficiales tiny-cloud (artefactos qcow2, VHD y AMI) desde 3.18.11 hasta 3.24.3 incluyen un usuario alpine con campo de contraseña * y doas sin contraseña. Son seguras en el primer arranque, pero se vuelven explotables en cuanto existe cualquier hash $6$ en la máquina: por ejemplo, cuando un administrador define una contraseña de consola o cuando los datos de usuario agregan una cuenta con hashed_passwd. A partir de ahí, el atacante obtiene una shell como alpine y puede usar doas para llegar a root.

Las imágenes construidas desde 3.21.10, 3.22.8, 3.23.8, 3.24.4 y posteriores ya traen el paquete corregido. En instancias que ya están corriendo con versiones anteriores, hay que actualizar o desactivar la autenticación por contraseña.

Vale la pena un matiz de soporte: 3.21 alcanzó su fin de soporte el 1 de noviembre de 2026, pero Alpine publicó paquetes corregidos para todas las ramas, hasta la 3.16.

¿Cómo saber si alguien ya entró en tu servidor?

Busca en /var/log/messages las líneas de sshd que digan Accepted password for sobre una cuenta que no tiene contraseña: alpine, root o cualquier usuario de solo llave. Revisa el uso de doas y los usuarios, archivos y claves autorizadas creados recientemente en las máquinas expuestas. Si no puedes descartar un login, Alpine es directa: trata la máquina como comprometida.

La causa técnica: musl, crypt() y el asterisco

Cuando sshd se compila sin PAM, verifica una contraseña calculando su hash con crypt() y comparando el resultado con el campo almacenado. Para una cuenta cuyo campo guardado es demasiado corto para contener un salt, el prefijo aleatorio del hash, sshd toma prestado el salt de otra cuenta. El crypt() de musl devuelve la cadena * como indicador de error cuando la clave supera los 256 bytes. Y * es exactamente lo que contiene el campo almacenado de toda cuenta sin contraseña, así que el «hash» coincide y el login pasa.

Es un fallo de composición, no de una sola pieza: la lógica de préstamo de salt de OpenSSH más el valor de retorno de musl. OpenSSH 10.6p2 evita el problema en sshd, y los paquetes de ramas estables de Alpine llevan un parche equivalente. El hallazgo lo reportó Özgün Kültekin, de Wakefield.

¿Qué significa esto para tu startup?

Para la mayoría de equipos latinoamericanos y españoles, la infraestructura crítica vive en pocos servidores y muchos de ellos exponen SSH a internet. Eso convierte un aviso como este en una tarea de hoy, no de la semana que viene.

Acciones concretas:

Inventaría antes de parchear. Corre sshd -T | grep -i passwordauthentication en cada host con Alpine y confirma en cuáles el resultado es no. Ese comando es la diferencia entre saber y suponer.
Arregla en orden de exposición. Primero los hosts con el puerto 22 abierto a internet; después los internos. Actualiza, reinicia sshd y recién entonces pasa al siguiente.
Audita cuentas con * y con hash $5$ / $6$ . El riesgo no es la cuenta sin contraseña por sí sola, es la combinación: una sola cuenta con hash alcanza para exponer a todas las demás.
Arregla tus imágenes base, no solo tus servidores. Si tu golden image hereda PasswordAuthentication yes por defecto, cada instancia nueva nace expuesta y vas a repetir el incidente en el próximo autoescalado.
Automatiza la verificación. Un chequeo de configuración en el pipeline de despliegue, que falle si passwordauthentication no es no, cuesta menos que una revisión manual después de cada aviso de seguridad.

Si además tienes instancias creadas desde imágenes tiny-cloud anteriores a 3.21.10, revísalas con prioridad: son las que pasan de seguras a explotables sin que nadie toque la configuración de SSH.