Los administradores que quieran saber si alguno de sus servidores está expuesto a SSHHole (CVE-2026-123158) ya pueden comprobarlo con SSHamble, el escáner de código abierto de runZero, que incorpora la prueba vuln-sshhole desde la versión v0.5.1 publicada el 05/11/2026. La herramienta permite revisar de una pasada una red propia y localizar los equipos que necesitan la actualización de OpenSSH.
Las claves de la comprobación de SSHHole con SSHamble en 20 segundos
- SSHamble, de runZero, añade la comprobación vuln-sshhole en la versión v0.5.1.
- Viene activada por defecto y deja los resultados en un fichero JSONL.
- SSHHole afecta a OpenSSH anterior a 10.6p2 compilado con musl y sin PAM.
- Alpine ya lo ha corregido en todas sus ramas, de la 3.16 a edge.
- Solo debe usarse sobre sistemas propios o autorizados.
El fallo ya se explicó en detalle en SSHHole, el fallo de OpenSSH con musl que afecta a Alpine. En resumen, afecta a OpenSSH (la implementación más extendida del protocolo SSH, Secure Shell) en versiones anteriores a la 10.6p2 cuando está compilado con la biblioteca musl y sin PAM (Pluggable Authentication Modules, el sistema de módulos de autenticación de Linux), y solo en cuentas que tienen un asterisco en lugar de contraseña. Es una combinación que se da sobre todo en Alpine Linux y en las muchas imágenes de contenedor construidas sobre esa distribución. Se tienen que cumplir varias condiciones a la vez, así que no hay motivo para el alarmismo, pero sí para revisar el inventario.
Qué es SSHamble y qué aporta a una auditoría
SSHamble es un escáner de exposiciones en servicios SSH desarrollado por runZero, empresa especializada en inventario de activos. HD Moore y Rob King lo presentaron en Black Hat USA 2024 con la charla «Secure Shell in Shambles». La nota de prensa de runZero sobre aquella investigación es del 07/08/2024.
El código está publicado en GitHub con licencia BSD de 2 cláusulas. A fecha de 06/11/2026 el repositorio rondaba las 1.200 estrellas y sumaba 15 autores en su historial de commits. En una auditoría, su papel es el de una herramienta de inventario: recorre un rango de direcciones, identifica los servicios SSH que encuentra y les pasa una batería de comprobaciones conocidas, de modo que el equipo de sistemas obtiene una lista de máquinas a revisar en lugar de tener que entrar en cada una.
La comprobación de SSHHole llegó a través de la PR (pull request, la petición de cambios en GitHub) número 53, que HD Moore fusionó el 05/11/2026. Ese mismo día se publicó la versión v0.5.1, la primera con binarios que la incluye. La etiqueta v0.5.0 también contiene el cambio, pero no ofrece ejecutables ya compilados.
Cómo comprobar la exposición a SSHHole paso a paso
Descargar la versión v0.5.1
La forma más directa es descargar el binario desde la página de releases del repositorio en GitHub, eligiendo el que corresponda al sistema operativo y la arquitectura del equipo desde el que se va a lanzar el escaneo.
Lanzar el escaneo sobre la red propia
La ayuda de la versión v0.5.1 recoge las opciones necesarias: -u o –users para la lista de usuarios, -p o –ports para los puertos, –checks para elegir las comprobaciones y -o o –output para el fichero de resultados. Un ejemplo sobre una red doméstica o de laboratorio sería este:
sshamble scan -u root,alpine,nobody -p 22 --checks vuln-sshhole -o resultados.jsonl 192.168.1.0/24Los usuarios van separados por comas y sin espacios; si se prefiere usar espacios, la lista tiene que ir entre comillas. Los nombres del ejemplo son cuentas habituales en sistemas Alpine, pero cada administrador debe adaptarlos a las cuentas que existan en sus propias máquinas. La comprobación viene activada por defecto, así que la opción –checks no es obligatoria; sirve para limitar el escaneo a esta prueba y obtener un informe más corto y rápido de leer.
Leer el fichero de resultados
SSHamble guarda la salida en formato JSONL (JSON Lines), es decir, un objeto JSON por línea. Aunque el fichero se llame .json, no es un único documento JSON. Lo práctico es tratarlo línea a línea: cada línea corresponde a un resultado asociado a un host y un puerto.
Para una primera revisión basta con filtrar las líneas que hacen referencia a la comprobación y anotar qué direcciones aparecen marcadas:
grep vuln-sshhole resultados.jsonlCon jq u otra herramienta similar se pueden agrupar los resultados por host hasta tener una lista concreta de máquinas que requieren actuación. Un detalle menor: el código de SSHamble todavía describe el fallo como «no CVE yet», pero el identificador CVE (Common Vulnerabilities and Exposures, el catálogo público de vulnerabilidades) ya está asignado como CVE-2026-123158.
Qué hacer con un sistema afectado y cómo escanear sin causar problemas
Si un servidor aparece como expuesto, la solución pasa por actualizar el paquete de OpenSSH. Alpine ha publicado la corrección en todas sus ramas mantenidas, de la 3.16 a edge, y en un sistema de esa distribución basta con:
apk update && apk upgrade opensshMientras se programa la actualización, la mitigación recomendada es desactivar la autenticación por contraseña con la directiva PasswordAuthentication no en el fichero de configuración del servidor SSH y reiniciar el servicio.
Los contenedores merecen un apartado propio. Actualizar el sistema anfitrión no corrige nada dentro de una imagen basada en Alpine que lleve su propio servidor SSH: hay que reconstruir esas imágenes con la versión corregida y volver a desplegarlas. Por último, conviene revisar qué cuentas del sistema no tienen contraseña y si alguna de ellas necesita de verdad acceso remoto.
El escaneo también tiene sus normas de uso. SSHamble solo debe lanzarse contra sistemas propios o sobre los que se cuente con una autorización por escrito del responsable; escanear redes de terceros sin permiso no es una auditoría. Antes de empezar es recomendable avisar al equipo de sistemas y al de seguridad, porque la herramienta realiza intentos de autenticación que quedan en los registros del servidor y pueden disparar alertas, bloqueos de fail2ban u otros mecanismos de protección.
La comprobación tiene además un componente curioso. Los primeros commits de la PR número 53 son de Paul Asadoorian e incluyen la línea «Co-Authored-By: Claude Opus 5.5», la fórmula con la que se acredita a Claude, el asistente de Anthropic, como coautor del cambio. Después, HD Moore la unificó con una comprobación equivalente que había preparado él. El código pasó, como cualquier otra contribución, por la revisión del mantenedor antes de fusionarse.
Preguntas frecuentes
¿Qué versión de SSHamble incluye la comprobación de SSHHole?
La comprobación vuln-sshhole está en la versión v0.5.1, publicada el 05/11/2026 con binarios precompilados. La etiqueta v0.5.0 también la incluye, pero no trae binarios.
¿Hay que indicar algo especial para activar la comprobación?
No. Viene activada por defecto, aunque la opción –checks vuln-sshhole permite limitar el escaneo a esa única prueba y obtener un informe más corto.
¿Qué hago si SSHamble marca un servidor como afectado?
Actualizar openssh con apk update && apk upgrade openssh, desactivar la autenticación por contraseña mientras tanto y reconstruir las imágenes de contenedor basadas en Alpine. Conviene revisar también las cuentas que no tienen contraseña.
¿Puedo usar SSHamble para escanear cualquier servidor de Internet?
No. Solo debe usarse sobre sistemas propios o con una autorización por escrito del responsable, porque genera intentos de autenticación que quedan registrados en el servidor.
Fuentes:
- Repositorio de SSHamble en GitHub (runZeroInc/sshamble)
- Release v0.5.1 de SSHamble
- runZero: nota de prensa sobre la investigación de exposiciones en SSH (07/08/2024)
- Alpine Linux: aviso sobre OpenSSH (05/11/2026)
- OpenSecurity: SSHHole, un fallo de OpenSSH con musl abre cuentas sin contraseña en Alpine
