Ciberseguridad
Redacción Teknosfera
Ciberseguridad

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.

Publicado
5 de noviembre de 2026
Lectura
3 min
Categorías
Ciberseguridad

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.

Temas de debate

Aún no hay temas: abre el primero.

Más noticias