Mandar una contraseña de 300 caracteres es la llave: el bypass de OpenSSH en Alpine

El 5 de noviembre del 2026 Alpine publicó un aviso que suena a chiste: un atacante que puede llegar a tu puerto SSH entra al servidor sin saber ninguna contraseña. Una sola conexión, funciona siempre, sin reintentos y sin CVE asignado. Nada de fuerza bruta ni diccionarios: el bug simplemente abrió la puerta.

El webeo del asterisco

El meollo no está en OpenSSH sino en musl, la libc que usa Alpine. Ahí sshd se compila sin PAM y valida la contraseña a la antigua: calcula el hash de lo que envías con crypt() y lo compara con el campo guardado en /etc/shadow. Ahora, si le pasas a crypt() una contraseña de más de 256 bytes, musl no lanza un error como corresponde: devuelve el string *. Y ahí está la coincidencia criminal: * es exactamente lo que llenan en el campo de contraseña las cuentas sin contraseña — el root de las imágenes base, los usuarios que dependen de llave, los que vienen desde un directorio LDAP. El «hash» calculado es un string, el guardado es un string, coinciden, y sesiona.

Las condiciones exactas

No es un exploit universal, pero las condiciones son típicamente las de un servidor self-hosted: sshd sin PAM (el paquete normal de Alpine), PasswordAuthentication yes — que sigue siendo el default de OpenSSH —, alguna cuenta con * en el shadow y al menos una con hash real, $5$ o $6$. Lo último es lo más injusto: basta que tú o cualquier admin ponga una contraseña normal en el equipo para que todas las cuentas sin contraseña queden alcanzables. Y en las imágenes tiny-cloud de Alpine había algo peor: el usuario alpine con campo * y doas sin contraseña, así que con un hash en la máquina el atacante llega derecho a root.

Lo que hice al enterarme

En mi flota de VPS hace años que apagué el login por contraseña y muevo SSH a un puerto no estándar, con fail2ban encima. Este caso es la confirmación de que las capas baratas valen oro. Lo que conviene revisar ahora son dos cosas. Primero: si corres Alpine con sshd, apk upgrade arregla el paquete, pero no reinicia el demonio: hay que hacer rc-service sshd restart a mano, porque actualizar sin reiniciar deja al sshd vulnerable corriendo con el código viejo. Si aún no puedes actualizar, PasswordAuthentication no y reiniciar cierra el agujero igual — y antes de tocar nada, comprueba que tu llave funciona y deja la sesión abierta hasta probar un login nuevo. Segundo: ¿te entró alguien? En /var/log/messages busca líneas Accepted password for para cuentas que no tienen contraseña. Si aparecen y no puedes descartar que hayan sido tuyas, trátalo como servidor comprometido: revisa doas, usuarios nuevos y authorized_keys.

Lo que me queda dando vueltas es el default. Ya en 2026, con todo lo que se ha escrito sobre servidores SSH expuestos, PasswordAuthentication sigue en yes salvo que tú lo apagues. Y una librería que devuelve un error como un string que coincide con el marcador de «cuenta sin contraseña» es del nivel de webeo que solo se descubre cuando alguien lo usa de verdad. Mi conclusión va para quien arma un homelab o sube una caja a internet mañana: llave SSH, contraseña desactivada, puerto no estándar y firewall no son paranoia. Acá, justamente esas cuatro cosas baratas eran lo que te salvaba la vida.

Fuente de inspiración: Security advisory: openssh-server password authentication bypass | Alpine Linux