OpenSSH corrige un fallo que permite saltarse la autenticación en ciertos sistemas Linux con musl

El anuncio de OpenSSH del 5 de noviembre de 2026 califica la actualización como una corrección de seguridad crítica. El equipo explica que el fallo puede aprovecharse a través de sshd cuando el soporte de PAM está desactivado y acredita el hallazgo a Özgün Kültekin, de Wakefield. La urgencia está en revisar el servidor que admite conexiones, no simplemente en actualizar el cliente SSH del ordenador desde el que se administra.

Qué configuraciones están expuestas

El aviso de Rich Felker en la lista de musl identifica la combinación de OpenSSH anterior a 10.6p2, musl, UsePAM no y PasswordAuthentication yes. Felker señala que Dropbear y otros programas ajenos a OpenSSH con acceso por contraseña no están afectados por este problema.

El boletín de Alpine Linux añade dos condiciones: una cuenta con el campo de contraseña establecido en * y otra con un hash de tipo $5$ o $6$. Una contraseña excesivamente larga provoca que la función crypt() devuelva un indicador de error que puede coincidir con ese asterisco almacenado.

Cuándo puede convertirse en acceso de administrador

Alpine distingue el acceso a una cuenta de la obtención de privilegios de administrador. La configuración predeterminada PermitRootLogin prohibit-password protege el acceso directo a root por esta vía, pero otra cuenta accesible podría disponer de permisos para elevar privilegios con doas. Por eso, revisar únicamente la entrada de root no basta.

El nombre de una distribución tampoco describe por sí solo la exposición de cada equipo. Un contenedor sin servidor SSH en ejecución y una máquina que acepta conexiones remotas presentan superficies distintas. La revisión debe centrarse en el servicio, sus opciones efectivas y los permisos de sus cuentas.

Actualizar y reiniciar el servicio

Alpine pide actualizar el paquete openssh y reiniciar sshd: instalarlo no sustituye el proceso que ya está funcionando. Sus ramas estables reciben el arreglo mediante paquetes parcheados, aunque conserven una versión base anterior a 10.6p2. Conviene consultar el boletín de la distribución antes de decidir si un número de versión está corregido.

Si la actualización debe esperar, Felker recomienda establecer PasswordAuthentication no y reiniciar el servidor después de comprobar que el acceso mediante clave pública funciona. En una administración remota, esa comprobación previa evita perder el canal necesario para terminar la intervención.

Aplicar el arreglo y revisar una posible intrusión son tareas distintas. Si aparecen accesos inesperados, deben conservarse los registros y analizarse las cuentas y sus privilegios; una actualización no permite concluir, por sí sola, que nadie haya entrado antes.