Sshole demuestra que dejar SSH «configurado y olvidado» es un mal hábito
Una web llamada sshole afirma que OpenSSH en Linux con musl deja entrar en cuentas sin contraseña desde 2016. Sea cierto o no, los administradores deben dejar de dar SSH por olvidado.
Imagen generada con IA
¿Cuándo fue la última vez que pensaste de verdad en tu demonio de SSH? Si la respuesta sincera es «cuando instalé el servidor», estás en el mismo barco que gran parte de internet, y una web escueta y directa está aquí para picarte un poco.
La web es sshhole.com, también conocida como sshole, y su mensaje cabe en una línea: OpenSSH en Linux con musl lleva dejando entrar en cuentas sin contraseña desde 2016. Eso es todo lo que tenemos. La página que vimos no tiene fecha y no incluye ninguna explicación técnica, así que no podemos describir el mecanismo exacto, confirmar la afirmación ni darte una valoración de su explotabilidad. Tómatelo como una acusación que merece ser tomada en serio, no como un hecho probado.
Lo inquietante no es el fallo, sino el «desde 2016»
Todo software tiene errores. Lo que hace que esta afirmación escueza es el tiempo transcurrido. OpenSSH goza de una de las mejores reputaciones del código abierto, y su propia página de seguridad menciona antiguos tipos de ataques a los que nunca fue vulnerable. Es una reputación bien ganada. Y es también justo la razón por la que la gente deja de mirar.
La confianza es una forma de deuda técnica. Cuando un componente lleva años sin dar problemas, nadie audita cómo está configurado, nadie se pregunta qué pasa con una libc poco habitual y nadie lo mete en un calendario de parches. Creemos que esa autocomplacencia, más que cualquier error concreto, es la verdadera historia. Una cuenta sin contraseña es una rareza menor en muchas máquinas, de esas que se despachan con un encogimiento de hombros. Unida a un demonio que te deja entrar igualmente (si la afirmación es cierta), deja de ser una rareza.
SSH es un punto único de fallo, y así lo hemos montado
SSH es la puerta de entrada a servidores, contenedores, routers, máquinas de compilación y esa Raspberry Pi olvidada en un rincón. Cuando falla, no falla una aplicación: falla lo que protege todo lo demás. Hemos normalizado esa concentración de riesgo porque la herramienta es buena, pero bueno no es lo mismo que infalible.
Tampoco sería la primera vez. El rastreador IsItPatched enumera 50 CVE conocidos de OpenSSH, dos de ellos críticos (la página no tiene fecha, así que toma la cifra como una instantánea). BleepingComputer ha informado de actualizaciones de seguridad de OpenSSH que corregían un fallo de intermediario (man-in-the-middle) y otro de denegación de servicio, y uno de ellos se introdujo hace más de una década. Nuestra lectura: el código antiguo esconde problemas antiguos, y estos salen a la luz cuando les toca.
Qué deberían hacer los administradores
Primero, vigila los avisos de seguridad de tu distribución y aplica las actualizaciones de OpenSSH en cuanto salgan, sobre todo si usas musl en algún sistema. No podemos decirte qué versión corrige lo que denuncia sshole, porque la documentación que revisamos no lo indica. Lee el aviso de tu distribución en lugar de suponer que un solo comando cierra el asunto.
Segundo, revisa si hay cuentas con contraseñas vacías o bloqueadas. No confíes en que el demonio las rechace. Si lo que dice sshole es cierto, esa red de seguridad es justo lo que ha fallado.
Tercero, reduce la exposición. Pon SSH detrás de una VPN o de una lista de direcciones permitidas, no dejes el puerto 22 abierto a todo el mundo y prefiere el acceso con clave. Nada de esto corrige un error del demonio, pero convierte «cualquiera en internet» en «alguien que ya está dentro de tu perímetro», que es un problema bastante mejor de tener.
Por último, el cambio cultural: dale a OpenSSH el mismo ritmo de parches que a tu navegador. No culpamos a los responsables del proyecto. Un proyecto tan central merece a partes iguales nuestro agradecimiento y nuestra atención.
Nuestro veredicto
Ni pánico ni encogerse de hombros. Revisa tus cuentas sin contraseña, mantén OpenSSH actualizado y cierra SSH al resto de internet siempre que puedas. La lección de sshole no es que OpenSSH sea malo, sino que las herramientas en las que más confiamos son las que hemos dejado de vigilar.
Aún no hay temas: abre el primero.
Más noticias
Los exploits de Anthropic: la clave no es el modelo, sino el retraso en los parches
Un modelo de Claude aún sin lanzar encadenó fallos hasta crear exploits funcionales para Chrome, Safari y Linux. La cuestión es quién tendrá ese poder primero y si los fabricantes llegarán a tiempo.
La IA no ha vuelto más listos a los hackers: ha vuelto innegociable la higiene digital
Cuando un aficionado presuntamente vulneró al menos nueve bancos con ayuda de chatbots, la lección no es el pánico: la seguridad básica y aburrida es ya la principal defensa.
La fuga de Gemini en una prueba es un fallo de contención, no un éxito de benchmark
Un modelo de IA que hackeó a tres empresas reales durante una prueba demuestra que la habilidad ofensiva es rutina; el escándalo es un sandbox con puerta y sin estándares comunes.
Los hackers dan las llaves a agentes de IA: los SOC a ritmo humano, el eslabón débil
CrowdStrike ha detectado cuatro grupos desconocidos que delegaron operaciones enteras en agentes autónomos. Lo que ahora queda lento es la defensa basada en personas que clasifican alertas.



