Fallo de autenticación en OpenSSH de Alpine: ¿te afecta?

El fallo que permite eludir la autenticación por contraseña en OpenSSH de Alpine no afecta a todos los servidores ni contenedores de Alpine. Comprueba si hay un demonio SSH en ejecución, si permite la autenticación por contraseña, si PAM está activo y si se cumplen las condiciones de las cuentas descritas en el aviso de Alpine. Usar solo claves SSH no basta para determinar que el sistema está a salvo: la autenticación por contraseña puede seguir habilitada junto con ellas. Aviso de Alpine.

OpenSSH publicó la versión portable 10.6p2 el 5 de noviembre de 2026, con una medida correctiva crítica para sistemas Linux que usan musl sin PAM. El proyecto OpenSSH indica que la causa raíz está fuera de sshd. Ya se ha asignado el identificador CVE-2026-123158, aunque el aviso de Alpine decía inicialmente que aún no había ninguno. Notas de la versión de OpenSSH, registro CVE publicado.

La tabla siguiente reúne las condiciones del proveedor para ayudarte a determinar si el fallo te afecta. Es una interpretación del aviso, no un análisis de tu infraestructura ni una reproducción de la vulnerabilidad. Los datos de los paquetes corresponden al 6 de noviembre; consulta el aviso enlazado para conocer los cambios posteriores.

¿Qué servidores SSH de Alpine están afectados?

Para que una configuración esté afectada, deben coincidir varias condiciones. Una etiqueta de Alpine, un paquete OpenSSH instalado o un número de versión que parezca antiguo no bastan para confirmar que se cumplen todas.

Alpine describe una vía de autenticación sin PAM con el acceso por contraseña habilitado, una cuenta que reúna los requisitos y cuyo campo de contraseña contenga *, y otra cuenta local con un hash de contraseña $5$ o $6$. El paquete predeterminado openssh-server utiliza la vía sin PAM. Instalar openssh-server-pam no elimina esa condición si UsePAM sigue en no. Requisitos descritos por el proveedor.

Usa la tabla para este fallo concreto. La clasificación «no afectado» presupone que has comprobado la configuración activa para la cuenta y la conexión correspondientes.

Estas clasificaciones sintetizan el aviso de Alpine. No describen la seguridad general del sistema ni permiten determinar si hubo una intrusión anteriormente.

La distinción entre cuentas es importante. Alpine diferencia el marcador * del bloqueo !; no consideres equivalentes todos los campos de contraseña que parezcan deshabilitados. Comprueba los requisitos de las cuentas mediante tu procedimiento de administración autorizado, sin copiar hashes de contraseñas en incidencias ni chats. No modifiques los campos de contraseña de las cuentas como solución improvisada.

También hay que revisar con cuidado la política de acceso de root. Un ajuste que impida el acceso directo de root mediante contraseña no determina si otra cuenta que reúna los requisitos está expuesta. Del mismo modo, una red privada cambia quién puede acceder a un servicio, pero no si su configuración de autenticación coincide con la del aviso.

¿Te protege usar claves SSH?

«Usamos claves SSH» y PasswordAuthentication no son hechos distintos. Un inicio de sesión correcto con una clave demuestra que la autenticación por clave funciona. No demuestra que el servidor rechace la autenticación por contraseña para ese usuario o para otros.

En un equipo pequeño es fácil pasar por alto esa diferencia. Puede que nadie escriba una contraseña desde hace años, mientras el demonio sigue aceptando intentos de autenticación por contraseña. Revisa el ajuste del servidor en lugar de deducirlo de cómo suele conectarse tu equipo. Alpine incluye expresamente la autenticación por contraseña deshabilitada entre los casos excluidos de este fallo. Indicaciones de configuración de Alpine.

El mismo razonamiento se aplica a PAM, el marco de autenticación que utiliza el paquete de servidor alternativo. Confirma tanto el paquete como el ajuste activo de UsePAM. Un inventario de paquetes que indique «PAM» no es una prueba suficiente si el servicio está configurado para no usarlo.

Las imágenes para la nube necesitan su propia comprobación. El aviso de Alpine trata tiny-cloud y cloud-init por separado, así que evita asumir que todas las imágenes para la nube tienen la misma configuración. Identifica la configuración de la imagen y los cambios posteriores en las cuentas; después, compáralos con las notas del proveedor sobre imágenes para la nube. El nombre de una imagen base no indica qué cambios hizo un administrador después del arranque.

¿Qué paquetes de Alpine incluyen la corrección?

Alpine ha adaptado la corrección a ramas anteriores de sus paquetes. Compara tu rama y la revisión completa del paquete con la tabla del proveedor, en lugar de exigir que todas las máquinas muestren la versión 10.6p2 del proyecto OpenSSH.

Selección de paquetes corregidos, comprobada el 6 de noviembre:

Fuente: tabla de paquetes corregidos de Alpine. Es un extracto, no una relación completa de las versiones con mantenimiento. Consulta el aviso para otras ramas. Adaptar una corrección a una versión cuyo mantenimiento ha terminado no renueva su periodo de mantenimiento.

Si el servicio está afectado, sigue las instrucciones de actualización de paquetes de Alpine y reinicia sshd. Para un servicio de Alpine gestionado por OpenRC, el aviso indica:

rc-service sshd restart

Utiliza el procedimiento de tu supervisor de procesos si el demonio está controlado por un contenedor u otro gestor de servicios. Si no puedes actualizar de inmediato, Alpine documenta como mitigación deshabilitar la autenticación por contraseña y reiniciar el servicio. Sigue las instrucciones de mitigación del proveedor en lugar de copiar una modificación de configuración en un entorno que no conoces bien.

Antes de modificar el acceso remoto, mantén abierta una sesión funcional con clave y conserva el acceso a la consola de recuperación. Comprueba el acceso legítimo en otra sesión para que un error de configuración no te deje fuera del servidor.

¿Qué debes comprobar después de actualizar?

Comprueba la configuración en el mismo contexto que el servicio y confirma después que el cambio ha surtido efecto. Las comprobaciones de configuración y un nuevo inicio de sesión responden a preguntas distintas.

El manual oficial documenta sshd -t para comprobar la configuración y las claves, y sshd -T para mostrar la configuración efectiva tras procesarla. Añade -C al evaluar reglas Match que dependan de la conexión. Por ejemplo:

sshd -t
sshd -T -C user=example,addr=192.0.2.10,host=example.test

El usuario, la dirección y el nombre de host son valores ilustrativos. Sustitúyelos por los de una conexión pertinente y revisa otros contextos en los que las reglas sean distintas. Utiliza el mismo ejecutable, archivo de configuración y opciones de inicio que el servicio en ejecución. Manual oficial de sshd.

Estos comandos inician un proceso nuevo. No consultan los ajustes que ya tiene cargados el demonio en ejecución. Por tanto, que se ejecuten correctamente no sustituye la comprobación de que el reinicio previsto ha terminado y el servicio corregido está en marcha.

Tras el cambio, abre otra sesión autorizada con clave sin cerrar tu acceso actual. Confirma que la cuenta que quieres comprobar sigue funcionando y que el servicio tiene los ajustes de autenticación esperados. No intentes explotar el fallo en producción para quedarte tranquilo. Un nuevo inicio de sesión correcto comprueba el acceso; no demuestra que la autenticación por contraseña esté deshabilitada ni que no haya habido una intrusión anterior.

Asigna las comprobaciones de configuración pendientes

Mantén visible cualquier requisito sin resolver. «Ajuste de PAM desconocido» o «reinicio sin confirmar» indican al siguiente ingeniero qué falta por comprobar; una etiqueta genérica como «Alpine revisado» oculta ese trabajo.

Si recibes un informe de vulnerabilidad sobre un servicio afectado, Kit Security permite mantener juntos la persona asignada, la evaluación, la conversación interna y el registro de la verificación de la corrección. Quien administra el sistema sigue siendo responsable de aportar las pruebas del host y del servicio; el flujo de gestión de informes no descubre servidores Alpine ni verifica automáticamente el estado del demonio.

Empieza por el servicio que tu equipo pueda revisar ahora. Determina su vía de autenticación, compara el paquete con la corrección de Alpine para esa rama y confirma el cambio necesario en el servicio. Mantén un responsable para cada duda de configuración pendiente hasta que quede resuelta.