Hay decisiones que tomamos para mejorar la seguridad de un sistema y que, sobre el papel, parecen difíciles de cuestionar. Una de ellas consiste en impedir que determinadas cuentas acepten contraseñas, de manera que solo puedan utilizarse otros métodos de autenticación. Es una práctica que tiene sentido en entornos donde el acceso debe estar especialmente controlado. El problema aparece cuando esa restricción, diseñada para impedir una entrada no autorizada, permite lo contrario. Entonces podemos encontrarnos con una situación desconcertante: una cuenta protegida frente al uso de contraseñas que termina aceptando un acceso que debería rechazar.La paradoja tiene ya un nombre: *sshole. Así se ha bautizado una vulnerabilidad, identificada como CVE-2026-123158, que permite entrar a distancia en determinadas cuentas de sistemas Linux sin conocer una contraseña válida. El problema se ha confirmado en configuraciones de Alpine Linux que combinan OpenSSH con musl, una biblioteca básica del sistema, y prescinden de PAM, un mecanismo utilizado para gestionar la autenticación. Otras plataformas podrían verse afectadas si reúnen las mismas condiciones. El investigador Özgün Kültekin, de Wakefield, descubrió el fallo y, el 5 de noviembre, tanto OpenSSH como Alpine publicaron correcciones para impedir ese acceso.Para entender cómo es posible algo así, primero debemos conocer una herramienta muy utilizada para administrar equipos a distancia: SSH. Este protocolo permite conectarse de forma segura a un ordenador a través de la red, por ejemplo, para gestionar un servidor sin estar físicamente delante de él. OpenSSH es una de sus implementaciones y permite identificarse mediante contraseñas o claves criptográficas, que acreditan la identidad del usuario de otra manera. En Linux, el archivo /etc/shadow almacena información utilizada para verificar las contraseñas de las cuentas. Cuando el campo correspondiente contiene un asterisco (*), la autenticación ordinaria por contraseña debería quedar bloqueada, aunque puedan seguir utilizándose otros métodos.El problema de una contraseña que nunca debería funcionarComo explica Kültekin en su investigación, el fallo aparece cuando OpenSSH comprueba una contraseña para una cuenta que no debería aceptarlas. Al no encontrar en ella los datos necesarios, utiliza información de otra cuenta para efectuar la verificación. Si la contraseña introducida tiene entre 257 y 1.024 bytes, la función encargada de procesarla en musl devuelve un asterisco para indicar un error. El problema es que ese mismo símbolo figura en la cuenta protegida: el servidor interpreta ambos valores como coincidentes y permite el acceso. {"videoId":"x7ztx9j","autoplay":false,"title":"Ransomware qué es, cómo infecta y cómo protegerse", "tag":"ransomware", "duration":"165"} La historia de este problema se remonta bastante más atrás de lo que parece. Según reconstruye el investigador, en 2012 musl modificó la forma de comunicar determinados errores y estableció un límite de longitud al procesar contraseñas para evitar ataques de denegación de servicio. Cuatro años después, OpenSSH introdujo cambios para impedir que alguien pudiera averiguar qué usuarios existían en un sistema midiendo sus tiempos de respuesta. En 2022, Alpine también ajustó la configuración de su cuenta de administrador para permitir el acceso mediante claves SSH. Eran soluciones a problemas diferentes que terminaron interactuando de una forma imprevista.La pregunta inevitable es qué equipos pueden estar afectados. En primer lugar, utilizar Alpine Linux no significa necesariamente ser vulnerable. Como explica la firma de ciberseguridad Check Point, el fallo exige que se cumplan varias condiciones simultáneamente, entre ellas que OpenSSH funcione sin PAM, admita contraseñas y encuentre una cuenta con el asterisco mencionado anteriormente. También debe existir otra cuenta local activa con un hash de contraseña generado mediante SHA-256 o SHA-512. Los sistemas que desactivan la autenticación por contraseña quedan fuera de este escenario, igual que aquellos que utilizan PAM para gestionarla. En Xataka La llegada de las IA con "automejora recursiva": qué significa que Astra haya ayudado a modificar otro modelo de IA Las consecuencias pueden ser especialmente graves cuando la cuenta comprometida dispone de permisos elevados. Alpine pone como ejemplo determinadas imágenes oficiales utilizadas en la nube, donde el usuario alpine puede ejecutar comandos de administrador mediante doas sin introducir una contraseña. Aunque estas imágenes son seguras en su primer arranque, pueden volverse vulnerables si posteriormente se configura una cuenta con un hash de contraseña compatible. En ese escenario, un atacante podría llegar a controlar el sistema. Y ya existen indicios de explotación: la firma Previdian asegura haber detectado ocho intentos desde una misma dirección IP y confirmado un acceso con privilegios de administrador en uno de sus servidores señuelo utilizados para detectar ataques.La respuesta al descubrimiento no se ha hecho esperar. OpenSSH publicó el 5 de noviembre la versión 10.6p2 para corregir el fallo, mientras que Alpine distribuyó actualizaciones para distintas ramas de su sistema, incluidas algunas antiguas. Sus responsables advierten de que instalar los parches no basta: también es necesario reiniciar el servicio SSH para que utilice el código corregido. Si todavía no es posible actualizar, recomiendan desactivar la autenticación mediante contraseña y reiniciar también el servicio para aplicar el cambio, comprobando antes que el acceso mediante claves funciona.Imágenes | LukasEn Xataka | Groenlandia se convierte en la pieza clave del internet europeo: Bruselas planea un cable submarino que esquive a EEUU - La noticia Algunos sistemas Linux permiten entrar sin conocer la contraseña: el fallo llevaba una década escondido fue publicada originalmente en Xataka por Javier Marquez .