OpenSSH 10.6p2 tapa una falla que puede dejar entrar sin clave a servidores Alpine Linux

El 5 de noviembre de 2026 salió OpenSSH 10.6p2, con lo que el proyecto llama un arreglo de seguridad crítico para sistemas Linux que usan la biblioteca musl y tienen PAM desactivado. El caso más expuesto es Alpine Linux: según su aviso de seguridad del mismo día, quien llega al puerto SSH puede entrar a una cuenta que no tiene contraseña (por ejemplo, una que solo usa llaves), si sabe su nombre y se dan ciertas condiciones de configuración, mandando una contraseña muy larga, de 257 a 1024 bytes, sin conocer ninguna clave.

Si tenés un servidor con Alpine y SSH abierto, esto es para hoy: actualizá el paquete openssh y reiniciá sshd. Si no podés actualizar ya, apagá el ingreso por contraseña (PasswordAuthentication no). Alpine dice que cualquiera de las dos cosas cierra el agujero.

Si tus servidores corren Windows, macOS, Ubuntu, Debian o Fedora, respirá: según The Hacker News, Damien Miller, de OpenSSH, dijo que los sistemas que no son Linux, los Linux basados en glibc y los que validan contraseñas por PAM no están afectados. Lo que cuenta es el sistema donde corre el servidor SSH, no la computadora desde la que te conectás. Y si adentro de un servidor Ubuntu corrés un contenedor o una máquina virtual con Alpine y sshd, esa sí cuenta.

A quién le pasa

Según el aviso de Alpine, la falla aparece solo si se cumplen todas estas condiciones a la vez:

• Usás el paquete openssh-server de Alpine, que viene compilado sin PAM, o openssh-server-pam con UsePAM no.
• El ingreso por contraseña está activado (PasswordAuthentication yes), que es lo que trae OpenSSH de fábrica si no lo cambiaste.
• Hay al menos una cuenta sin contraseña (con un asterisco, *, en /etc/shadow): por ejemplo, un usuario que entra solo con llave, creado con adduser sin contraseña o con usermod -p '*'. También cuentan los usuarios que vienen de un directorio por musl-nscd, que no tienen entrada en /etc/shadow.
• Hay al menos otra cuenta local con una contraseña de verdad (un hash $5$ o $6$). Alpine lo resume así: alcanza con un solo usuario con contraseña para que todas las cuentas sin contraseña queden al alcance.

Además, el atacante tiene que conocer el nombre de una cuenta sin contraseña.

Un detalle sobre root: en Alpine viene como root:* desde la 3.16 más o menos, pero la configuración de fábrica de OpenSSH (PermitRootLogin prohibit-password) lo protege salvo que hayas puesto PermitRootLogin yes. El problema es que eso no sirve de mucho si otra cuenta que sí puede entrar puede pasar a root, por ejemplo con doas.

Según Alpine, están afectadas todas las versiones que revisó: de la 3.21 a la 3.24, edge y las viejas, de la 3.16 a la 3.20.

Y fuera de Alpine: el investigador que encontró la falla, Özgün Kültekin, de Wakefield, nombra OpenWrt, Buildroot y Yocto como otros sistemas con musl para revisar. En OpenWrt, de todos modos, el SSH de fábrica es Dropbear, y Kültekin dice que Dropbear no está afectado. Según The Hacker News, en OpenWrt solo importa si alguien instaló el servidor de OpenSSH.

Quién queda afuera

• Los contenedores Docker que no corren sshd adentro.
• Los sistemas con PasswordAuthentication no.
• Los que usan openssh-server-pam con UsePAM yes.
• Las cuentas bloqueadas con ! en lugar de *, y los equipos donde ninguna cuenta tiene una contraseña con hash $.
• Las imágenes de nube configuradas con cloud-init, que escribe PasswordAuthentication no.

Cómo cerrarlo

1. Actualizar y reiniciar

Alpine pide correr apk upgrade -U -a y después reiniciar el servicio con rc-service sshd restart: actualizar el paquete no reemplaza al sshd que ya está corriendo, y si no reiniciás, el agujero sigue abierto hasta el próximo arranque.

Ojo: salvo en edge, Alpine no pasa a la 10.6p2. En las ramas estables aplicó un parche para el mismo problema sobre la versión que ya tenía cada una (por eso la 3.24 queda en 10.3_p1-r2), así que lo que importa es el número de paquete de esta tabla:

Alpine 3.21.10, 3.22.8, 3.23.8 y 3.24.4 ya traen el paquete corregido. Y aunque la 3.21 y las anteriores ya no tienen soporte regular, Alpine publicó paquetes arreglados hasta la 3.16. Sí, incluso para el servidor que nadie se anima a tocar desde 2022.

2. Si no podés actualizar todavía: apagar las contraseñas

Antes de tocar nada, comprobá que tu ingreso con llave funciona y dejá abierta la sesión actual hasta probar una nueva; si no, te podés quedar afuera de tu propio servidor. Después, poné PasswordAuthentication no en la configuración de sshd. Alpine propone dos cambios a la vez: un archivo dentro de /etc/ssh/sshd_config.d/ (que Alpine lee desde la 3.19) y cambiar a no todas las líneas PasswordAuthentication de /etc/ssh/sshd_config, incluidas las que están dentro de un bloque Match. Después reiniciá el servicio. Para confirmar, sshd -T | grep -i passwordauthentication tiene que responder passwordauthentication no. El aviso de Alpine trae los comandos completos, incluida la forma de deshacer el cambio.

Las imágenes de nube de Alpine

Ojo con esto si tenés máquinas en la nube: las imágenes oficiales tiny-cloud de Alpine (los archivos qcow2, VHD y AMI) de la 3.18.11 a la 3.24.3 traen un usuario alpine sin contraseña y con doas sin contraseña. Alpine aclara que en el primer arranque son seguras, pero que se vuelven explotables apenas aparece en la máquina cualquier contraseña con hash $6$, por ejemplo cuando alguien le pone una contraseña a la consola. Desde ahí, según Alpine, un atacante consigue una sesión como alpine y pasa a root con doas. Las imágenes de 3.21.10, 3.22.8, 3.23.8, 3.24.4 y posteriores ya vienen corregidas; las anteriores no, así que en cada instancia que ya está corriendo hay que actualizar o apagar las contraseñas.

Cómo saber si alguien entró

Alpine recomienda buscar en /var/log/messages las líneas de sshd que dicen Accepted password for para una cuenta que no tiene contraseña (alpine, root o cualquier usuario que entra solo con llave). También pide revisar el uso de doas y los usuarios, archivos y llaves autorizadas creados hace poco en las máquinas expuestas. Y si no podés descartar un ingreso, tratá la máquina como comprometida.

Al publicarse los avisos no había ataques reportados con esta falla, según The Hacker News, y tampoco había un identificador CVE asignado, según Alpine.

Cómo pasó

Sin PAM, sshd valida una contraseña pasándola por la función crypt() y comparando el resultado con lo que hay guardado. Según Alpine, la crypt() de musl devuelve un asterisco como señal de error cuando la contraseña pasa de 256 bytes, y ese mismo asterisco es justo lo que tiene guardado cada cuenta sin contraseña. Resultado: el «hash» coincide y el ingreso pasa. OpenSSH considera que la raíz del problema está fuera de sshd, pero que se puede explotar a través de él y por eso lo evitó ahí. Kültekin cuenta que la encontró con agentes de IA que probaron unas 17.600 combinaciones de ingreso.

OpenSSH aprovechó las notas de la versión para anunciar un cambio de ritmo: recibió muchos reportes de seguridad, buena parte hechos con IA o con su ayuda, y vio casos de fallas encontradas por herramientas de IA que después otro investigador descubrió por su cuenta. Por eso, dice, por ahora va a sacar versiones más seguido en lugar de juntar los arreglos para la próxima versión planificada.

Fuentes

• OpenSSH, notas de la versión 10.6p2 (en inglés), 5 de noviembre de 2026. El arreglo crítico para Linux con musl y PAM desactivado, y el cambio de ritmo de versiones. Traducción de TCD.
• Alpine Linux, «Security advisory: openssh-server password authentication bypass» (en inglés), 5 de noviembre de 2026. Las condiciones, las versiones corregidas, las imágenes de nube y cómo revisar los registros. Traducción de TCD.
• The Hacker News, «OpenSSH Issues Emergency Fix for Flaw Letting Long Passwords Bypass SSH Auth on Alpine Linux» (en inglés), 5 de noviembre de 2026. Lo que dijo Damien Miller sobre los sistemas no afectados, lo de OpenWrt y Dropbear, y que no había ataques reportados.
• BleepingComputer, «OpenSSH flaw lets attackers log into password-disabled Linux accounts» (en inglés), 5 de noviembre de 2026. Cómo dice el investigador que la encontró.
• Créditos de imagen: la portada y la infografía son fotomontajes editoriales asistidos por IA con los logos oficiales de OpenSSH y de Alpine Linux; los datos de la infografía son del aviso de Alpine.