OpenSSH 10.6p2: evasión de contraseña en Alpine

OpenSSH 10.6p2 se publicó el 5 de noviembre de 2026. Sus notas de versión anuncian la corrección de una evasión de la autenticación por contraseña, explotable a través de sshd, en ciertos sistemas Linux compilados sin PAM. Ese mismo día, Alpine Linux publicó un aviso que detalla el mecanismo, las condiciones y los paquetes corregidos. El fallo fue comunicado por Özgün Kültekin, de Wakefield.

Dos precisiones útiles antes de actuar. Primero, no se había asignado ningún identificador CVE en la fecha del aviso de Alpine; algunos artículos de prensa citan uno, y no lo recogemos por falta de fuente primaria. Segundo, los mantenedores de OpenSSH consideran que la causa raíz está fuera de sshd y han esquivado el problema dentro de sshd: la corrección está, por tanto, en el paquete OpenSSH, no en la biblioteca C. En el momento de escribir, no conocemos ningún informe público de explotación, pero el detalle técnico es público: dé por hecho que habrá escaneos.

Sin PAM, sshd calcula el hash de la contraseña introducida con crypt() y compara el resultado con el campo almacenado en /etc/shadow. Para las cuentas cuyo campo es demasiado corto para contener una sal, sshd toma prestada la de otra cuenta, para no revelar por el tiempo de respuesta que un nombre de usuario no tiene contraseña.

En musl, crypt() devuelve la cadena * como valor de error cuando la clave supera los 256 bytes. Pues bien, * es también, en /etc/shadow, el valor de una cuenta sin contraseña. La comparación tiene éxito: la conexión pasa sin que nadie haya adivinado nada. El aviso de Alpine indica la ventana explotable: una contraseña de 257 a 1024 bytes. No es un defecto criptográfico ni una corrupción de memoria, es un error de lógica: un valor de error tomado por un resultado.

No, no por este fallo: exige musl. Aun así, la objeción merece plantearse, porque la pregunta útil para un parque de servidores está en otra parte: ¿dónde hay Alpine sin haberlo elegido? Una imagen de contenedor que incluye un sshd para depuración, un equipo de red, un router con OpenWrt, una imagen construida con Buildroot o Yocto: todos pueden apoyarse en musl, según cómo se hayan construido. En un VPS con sistema Debian o Ubuntu, la exposición procede de un contenedor Alpine con sshd que usted ejecute en él, no del sistema anfitrión.

Un inventario cabe en dos comandos por máquina: ls /lib/ld-musl* indica si el sistema usa musl, y ps aux | grep sshd indica si hay un servicio SSH en marcha. Hágalo también en sus contenedores, porque una imagen reconstruida el año pasado puede incluir todavía el paquete antiguo.

Una corrección suprime el fallo; no borra lo que un atacante haya hecho antes. El aviso de Alpine recomienda buscar, en /var/log/messages, las líneas Accepted password for que afecten a cuentas que se supone que no tienen contraseña: alpine, root o un usuario reservado a las conexiones con clave. Una línea así es un indicio fuerte, ya que esas cuentas nunca deberían conectarse con contraseña.

Para las cuentas que aparezcan, revise después el uso de doas, los usuarios creados recientemente, los archivos modificados y el contenido de cada authorized_keys. El aviso no deja dudas sobre la conducta a seguir: si no puede descartar una conexión, trate la máquina como comprometida, reconstrúyala y renueve los secretos que contenía. En las imágenes cloud oficiales el riesgo es mayor: el usuario alpine dispone allí de doas sin contraseña, lo que permite pasar a root una vez dentro.

Los mensajes siguientes son los de OpenSSH; aparecen en el cliente, en el terminal, y en el servidor, en el registro del servicio.

No procede de una mala práctica espectacular: una cuenta sin contraseña, otra con contraseña, un valor por defecto. Cada una de esas decisiones es habitual, y es su combinación en un sistema poco frecuente lo que crea la exposición. La respuesta duradera es la misma de antes del fallo: en todo servidor accesible desde Internet, autentíquese con clave, desactive las contraseñas y sepa qué imágenes y qué contenedores incluyen un sshd.

Si ya ha reforzado sus accesos, esta alerta se resuelve en diez minutos por máquina. Si no, es la ocasión de hacerlo: el procedimiento completo se describe en nuestra guía del primer acceso SSH, y la actualización de OpenSSH 10.6 sin perder el acceso, en el artículo dedicado a esa versión. Un VPS ServOrbit le da acceso root y la elección del sistema, lo que le deja el control de estos parámetros.