OpenSSH 10.6p2: revisar sistemas musl sin perder el acceso SSH

Estado: 8 de noviembre de 2026. Portable OpenSSH 10.6p2 se publicó el 5 de noviembre con una medida crítica frente a una posible omisión de la autenticación por contraseña en determinados sistemas Linux con musl y sin PAM. Esta guía permite comprobar la exposición y preparar una actualización verificada sin quedarse sin acceso. No es una prueba propia del producto ni de ataque. [1]

Qué sistemas deben revisarse

Hay que identificar el servidor OpenSSH que realmente se ejecuta, no solo la distribución. El aviso de musl señala OpenSSH anterior a 10.6p2 con UsePAM=no y PasswordAuthentication=yes; también deben considerarse compilaciones sin soporte PAM. Alpine es un ejemplo, no una lista completa. El mantenedor excluye de esta vulnerabilidad concreta sistemas no Linux, Linux con glibc y sistemas que utilizan PAM para autenticar contraseñas. El aviso musl excluye Dropbear. No implica una garantía general de seguridad. [2] [4]

Requisitos y recuperación preparada

Se necesita administración autorizada, documentación del paquete/imagen y una consola o recuperación independiente de SSH. Mantenga abierta una sesión existente, pero no la considere una recuperación garantizada. Proteja las copias de configuración, archivos incluidos, versiones y material de recuperación; nunca copie claves privadas del servidor en incidencias o chats. En dispositivos integrados use el firmware admitido, no sustituya ejecutables de forma aislada.

Cinco pasos para verificar el estado

  1. Inventaríe el servidor: determine paquete, libc, soporte PAM y servicio activo mediante registros de paquetes, avisos del fabricante y metadatos de imagen. ssh -V identifica el cliente local, no el servidor. Si está disponible, sshd -V identifica el ejecutable invocado, pero no demuestra qué archivo usa el proceso activo. Evalúe los backports con el aviso del proveedor, no únicamente por la versión. [3]
  2. Lea la configuración efectiva: con el ejecutable correcto y el archivo que utiliza el servicio, use sshd -t para verificar configuración/claves y sshd -T para obtener los ajustes efectivos, respetando permisos y rutas. Con reglas Match, indique parámetros -C apropiados según el manual instalado. Analice conjuntamente compilación PAM, UsePAM y autenticación por contraseña. Una configuración válida no demuestra que la vulnerabilidad esté corregida. [3]
  3. Actúe urgentemente si la combinación está afectada: musl recomienda PasswordAuthentication no como medida provisional. Primero compruebe el acceso por clave en una sesión nueva independiente y la consola de recuperación. Después cambie la configuración efectiva de forma controlada, valídela y reinicie según el proveedor. Sin acceso seguro, no cambie a ciegas: recurra a consola/responsables o limite la exposición mediante el procedimiento de emergencia autorizado. No active PAM ni otros métodos como experimento. [2] [4]
  4. Instale la corrección del proveedor: utilice el paquete/imagen aprobado para el sistema o dispositivo, con la medida de 10.6p2 o un backport documentado, desde una fuente fiable. Prepare recuperación y ventana de mantenimiento; renueve también el servicio en ejecución según las instrucciones. Evite repositorios ajenos, superponer compilaciones manuales o desactivar globalmente protecciones como atajo.
  5. Vuelva a conectar y valide: en una conexión nueva pruebe claves, privilegios administrativos necesarios y procesos SFTP/automatización relevantes. Revise paquete/imagen, reglas efectivas y registros; no necesita intentar explotar la vulnerabilidad. Cierre la sesión original solo tras la aceptación. Si falla, restaure controladamente el estado protegido mediante consola; no deje como solución permanente un servicio sin corregir y nuevamente expuesto con contraseñas.

Cómo confirmar el resultado

La medida queda terminada cuando la corrección documentada está activa en el servicio y funcionan nuevas conexiones y tareas. No bastan un paquete instalado, un banner o una sesión antigua. Si desactivó contraseñas temporalmente, considere reactivarlas solo tras confirmar la corrección y obtener aprobación operativa. Mantener únicamente claves puede ser apropiado, pero es otra decisión de seguridad.

Límites y fuentes

Esta guía no modifica servidores automáticamente ni sustituye el aviso de la distribución o la autorización local. Una versión antigua puede incluir un backport; no todos los dispositivos musl ejecutan OpenSSH. Consulte al proveedor si hay dudas sobre compilación/corrección y priorice la contención. No se afirma una atribución CVE universal, detección de ataques ni una migración realizada.