OpenSSH corrige un fallo que permitía entrar sin contraseña en Alpine

Una vulnerabilidad de seguridad en OpenSSH ha permitido acceder a determinadas cuentas de servidores Linux sin conocer sus contraseñas, incluso cuando estaban configuradas para impedir ese tipo de acceso. El problema afecta a sistemas que utilizan la biblioteca musl libc sin el sistema de autenticación PAM, una combinación presente en distribuciones como Alpine Linux. Los desarrolladores han publicado una actualización urgente este 5 de noviembre de 2026 para impedir que el fallo siga siendo explotable.

Lo especialmente preocupante es que un atacante podía superar la autenticación introduciendo una contraseña de más de 256 bytes, sin necesidad de conocer la clave legítima de la cuenta. El procedimiento funcionaba cuando coincidían determinadas condiciones de configuración y podía comprometer usuarios preparados para acceder exclusivamente mediante claves SSH. OpenSSH 10.6p2 incorpora una protección frente al problema, mientras que Alpine Linux ha distribuido parches para distintas versiones de su sistema operativo.

La vulnerabilidad, descubierta por el investigador Özgün Kültekin, afecta a una función esencial de la seguridad informática: comprobar que quien intenta conectarse a un servidor está realmente autorizado. No todos los equipos Linux están expuestos, pero el fallo resulta especialmente delicado en servidores accesibles desde Internet, máquinas virtuales y determinadas instalaciones utilizadas para administrar infraestructuras tecnológicas.

El fallo de OpenSSH afecta a Linux con musl y sin PAM

OpenSSH es uno de los programas más utilizados para establecer conexiones cifradas entre ordenadores. Su componente servidor, denominado sshd, permite a los administradores acceder remotamente a sistemas, ejecutar tareas de mantenimiento, gestionar aplicaciones y transferir archivos.

La vulnerabilidad aparece cuando OpenSSH verifica contraseñas directamente, sin recurrir a PAM, el sistema modular de autenticación empleado habitualmente por numerosas distribuciones Linux. En determinados entornos basados en musl, esa comprobación podía interpretar incorrectamente el resultado de una operación criptográfica y autorizar una conexión que debía ser rechazada.

Para que el ataque funcione deben coincidir varias circunstancias. El servidor tiene que utilizar musl sin PAM, mantener habilitada la autenticación mediante contraseña y disponer de una cuenta cuyo campo de contraseña contenga únicamente un asterisco. También debe existir al menos otra cuenta local con una contraseña almacenada mediante un hash de tipo SHA-256 o SHA-512, identificados respectivamente por los prefijos $5$ y $6$.

El atacante necesita conocer el nombre de una de esas cuentas y poder alcanzar el servicio SSH. Si se cumplen las condiciones, una sola conexión puede bastar para acceder. No hacen falta miles de intentos ni descubrir la contraseña auténtica mediante fuerza bruta.

Por qué una contraseña demasiado larga permite superar la autenticación

El origen técnico está en una coincidencia inesperada entre dos mecanismos de seguridad que, por separado, tenían una finalidad legítima.

En sistemas Unix, un asterisco en el campo reservado a la contraseña indica habitualmente que esa cuenta no tiene una contraseña válida para iniciar sesión. Es una configuración frecuente en usuarios que deben autenticarse exclusivamente mediante claves públicas SSH.

Por otra parte, la función crypt() utilizada por musl devuelve precisamente ese mismo carácter cuando determinadas operaciones de cálculo de contraseñas fallan. Esto ocurre, entre otros casos, cuando recibe una entrada de más de 256 bytes con los algoritmos implicados.

Cuando OpenSSH encuentra un campo de contraseña demasiado corto para contener la información necesaria para calcular un hash, puede utilizar los parámetros de otra cuenta para realizar una comprobación. Ese comportamiento se introdujo para dificultar que alguien averiguase qué usuarios existen en un servidor midiendo los tiempos de respuesta.

La combinación resulta problemática: musl devuelve el asterisco para indicar un error y OpenSSH puede comparar ese resultado con el mismo carácter almacenado en la cuenta de destino. Ambos valores coinciden y el sistema interpreta que la autenticación ha tenido éxito.

En las configuraciones afectadas, el fallo admite entradas de 257 a 1.024 bytes. No se trata, por tanto, de que cualquier contraseña sirva para acceder a cualquier servidor Linux, sino de un error concreto en la interacción entre la biblioteca del sistema y el mecanismo de autenticación de OpenSSH.

Alpine Linux y las cuentas que pueden quedar expuestas

Alpine Linux figura entre las distribuciones más directamente afectadas porque utiliza musl y su paquete estándar openssh-server se compila sin soporte PAM.

El riesgo alcanza especialmente a las cuentas creadas para utilizar únicamente claves SSH. Aunque sus administradores hayan evitado asignarles una contraseña, estas pueden resultar accesibles mediante el procedimiento descrito cuando el servidor reúne las demás condiciones.

También pueden verse implicados usuarios procedentes de servicios de directorio y determinadas cuentas administrativas. En Alpine Linux, por ejemplo, la cuenta root utiliza un asterisco como marcador de contraseña en sus imágenes base desde la rama 3.16.

Eso no significa que cualquier atacante pueda entrar directamente como administrador. La configuración predeterminada de OpenSSH, PermitRootLogin prohibit-password, impide el acceso de root mediante contraseña. Sin embargo, el peligro reaparece cuando otra cuenta vulnerable dispone de permisos suficientes para elevar privilegios.

Una situación especialmente delicada afecta a determinadas imágenes oficiales de Alpine para servicios en la nube. Algunas versiones incluyen un usuario denominado alpine, configurado sin contraseña y con capacidad para ejecutar órdenes administrativas mediante doas sin introducir una clave adicional.

Estas imágenes no son necesariamente vulnerables desde su primera ejecución. El problema aparece cuando se incorpora al sistema una cuenta con el tipo de contraseña cifrada necesario para activar el fallo. En esas circunstancias, el acceso inicial como alpine podría terminar proporcionando privilegios de administrador.

El problema también merece atención en proyectos basados en musl, como OpenWrt, Buildroot o Yocto, siempre que empleen una configuración de OpenSSH que reúna las condiciones descritas. En cambio, utilizar Alpine dentro de un contenedor Docker no implica por sí mismo estar expuesto: si el contenedor no ejecuta un servidor SSH, esta vía de ataque no existe.

Qué sistemas Linux no están afectados

Los responsables de OpenSSH han precisado que esta vulnerabilidad no afecta a los sistemas Linux que utilizan glibc, la biblioteca habitual de distribuciones como Debian, Ubuntu o Fedora.

Tampoco afecta a los equipos donde la comprobación de contraseñas se realiza mediante PAM, ni a los servidores que tienen desactivada la autenticación por contraseña con PasswordAuthentication no.

En Alpine, las cuentas cuyo campo de contraseña comienza con el signo de exclamación tampoco son vulnerables por esta vía. Ese marcador bloquea el acceso de una forma distinta a la utilizada por las cuentas que contienen un asterisco.

Conviene distinguir entre disponer de OpenSSH instalado y mantener una configuración realmente explotable. La presencia del programa no basta para considerar vulnerable un servidor. Importan la biblioteca utilizada, las opciones de autenticación, el estado de las cuentas y la existencia de determinados tipos de contraseñas cifradas.

OpenSSH 10.6p2 y las actualizaciones urgentes para Alpine

La respuesta de los desarrolladores ha sido publicar OpenSSH 10.6p2, una versión extraordinaria que incorpora una protección para evitar que el servidor acepte una autenticación basada en este resultado incorrecto.

El equipo de OpenSSH considera que el origen del problema está fuera del propio programa, concretamente en la interacción con la biblioteca del sistema. Aun así, ha decidido introducir una corrección directamente en sshd para bloquear el acceso indebido.

Alpine Linux también ha reaccionado distribuyendo paquetes de seguridad. Las versiones 3.21.10, 3.22.8, 3.23.8 y 3.24.4, publicadas el 5 de noviembre, incluyen la protección. El proyecto ha preparado igualmente correcciones para ramas anteriores, hasta Alpine 3.16, aunque algunas hayan dejado de recibir mantenimiento ordinario.

Los administradores pueden actualizar los paquetes de Alpine mediante apk upgrade -U -a. Después deben reiniciar el servidor SSH con rc-service sshd restart, puesto que instalar la actualización no sustituye automáticamente el proceso que sigue ejecutándose.

Es importante comprobar la versión corregida correspondiente a cada rama. No todas las actualizaciones de Alpine llevan el número OpenSSH 10.6p2, porque las distribuciones estables han incorporado el parche a versiones anteriores del programa.

Para los sistemas que no puedan actualizarse inmediatamente, la medida de protección consiste en desactivar la autenticación por contraseña estableciendo PasswordAuthentication no en la configuración de sshd.

Antes de modificar esa opción hay que comprobar que el acceso mediante claves SSH funciona correctamente. También conviene mantener abierta la sesión administrativa hasta verificar una nueva conexión, para evitar perder el acceso remoto al servidor.

El resultado puede comprobarse mediante sshd -T | grep -i passwordauthentication, que debe mostrar passwordauthentication no. Si existen reglas específicas Match, también es necesario revisar que ninguna vuelva a habilitar las contraseñas para determinados usuarios o conexiones.

Cómo detectar posibles accesos indebidos a un servidor

La publicación del parche no permite determinar automáticamente si una máquina fue comprometida antes de actualizarse.

En Alpine Linux, una primera comprobación consiste en revisar los registros de autenticación, especialmente el archivo /var/log/messages, buscando entradas de sshd con el texto Accepted password for.

Si aparece una autenticación de ese tipo asociada a una cuenta que no debería aceptar contraseñas, existe un indicio importante de acceso no autorizado. Es necesario analizar el contexto de la conexión, las direcciones de origen y las operaciones realizadas después.

También deben revisarse las modificaciones recientes de usuarios, las claves autorizadas, los archivos del sistema y las operaciones efectuadas con herramientas de elevación de privilegios como doas.

La ausencia de entradas sospechosas no demuestra que nunca se produjera un ataque, especialmente si los registros se han eliminado o han dejado de conservarse. Cuando no sea posible descartar una intrusión, resulta prudente considerar el servidor potencialmente comprometido y aplicar el procedimiento de respuesta correspondiente.

En el momento de publicarse la alerta, no se habían acreditado públicamente campañas de explotación de esta vulnerabilidad. Eso no elimina el riesgo: los detalles técnicos del fallo son conocidos y las configuraciones expuestas pueden comprobarse.

Un error arrastrado durante años que obliga a revisar SSH

Lo llamativo del descubrimiento es que la vulnerabilidad no procede de una tecnología recién incorporada. Su origen se remonta a decisiones técnicas adoptadas hace años: cambios en el comportamiento de crypt() en musl durante 2012 y modificaciones en OpenSSH introducidas en 2016 para proteger frente a la identificación de cuentas mediante tiempos de respuesta.

Durante mucho tiempo, ambos mecanismos coexistieron sin que se detectara públicamente esta combinación peligrosa. El investigador Özgün Kültekin la identificó al examinar diferentes configuraciones de autenticación, incluidas combinaciones de bibliotecas y sistemas PAM.

El propio proyecto OpenSSH ha explicado que pretende acelerar la publicación de correcciones de seguridad ante la posibilidad de que herramientas de inteligencia artificial permitan redescubrir vulnerabilidades en intervalos cada vez más cortos. La rapidez con la que pueden difundirse y reproducirse estos errores reduce el margen disponible para proteger los sistemas afectados.

Para los administradores de Alpine y otros entornos Linux basados en musl, la consecuencia es inmediata: actualizar OpenSSH, reiniciar el servicio y verificar la configuración real de autenticación. Una cuenta preparada para rechazar contraseñas no debería convertirse, por un error de comprobación, en una puerta de entrada al servidor.