Los administradores que mantienen servidores con Alpine Linux ya pueden comprobar desde su propia red si alguno está expuesto a SSHHole (CVE-2026-123158), el fallo de OpenSSH que afecta a versiones anteriores a la 10.6p2 compiladas con musl y sin PAM (Pluggable Authentication Modules): SSHamble, el escáner de exposiciones SSH de runZero, incorpora desde su versión v0.5.1, publicada el 05/11/2026, la comprobación «vuln-sshhole». El blog OpenSecurity ha explicado cómo usar SSHamble para comprobar servidores frente a SSHHole, y esta guía se queda con la parte operativa: descargar la herramienta, escanear solo lo propio, dejar el control programado y decidir qué hacer con un positivo.
Las claves de la comprobación de SSHHole con SSHamble en 30 segundos
- SSHHole afecta a OpenSSH anterior a 10.6p2 con musl y sin PAM, en cuentas con «*» en el campo de contraseña.
- Alpine lo ha corregido de la 3.16 a edge; mientras se actualiza, la mitigación es PasswordAuthentication no.
- SSHamble v0.5.1, de runZero, trae la comprobación vuln-sshhole activada por defecto y guarda los resultados en JSONL.
- El escaneo deja intentos de autenticación en los registros y puede activar fail2ban, así que conviene avisar al equipo y poner el origen en lista blanca.
SSHamble no es nuevo. HD Moore y Rob King lo presentaron en Black Hat USA 2024 con la charla «Secure Shell in Shambles», en la que runZero repasó problemas de exposición en implementaciones SSH, y el código se distribuye con licencia BSD de 2 cláusulas. La prueba específica para SSHHole llegó con la petición de cambios (pull request) número 53, que HD Moore fusionó el 05/11/2026. Sus primeros commits los firma Paul Asadoorian e incluyen la línea «Co-Authored-By: Claude Opus 5.5».
Antes de lanzar nada conviene fijar el perímetro. La herramienta solo debe apuntar a sistemas propios o a sistemas sobre los que exista una autorización por escrito. Un escáner que intenta autenticarse contra servidores SSH ajenos es, para quien los administra, indistinguible de un ataque.
Descargar SSHamble y lanzar el primer escaneo
El proyecto está en GitHub, en el repositorio runZeroInc/sshamble, y la versión v0.5.1 es la que publica binarios ya compilados con la nueva comprobación. Basta con descargar el que corresponda al sistema operativo y la arquitectura de la máquina desde la que se va a escanear, extraerlo si viene empaquetado y dejarlo en una ruta del sistema con permisos de ejecución:
sudo install -m 0755 sshamble /usr/local/bin/sshambleEl escaneo se lanza con el subcomando scan. Las opciones que importan aquí son cuatro: -u o –users para las cuentas que se van a probar, -p o –ports para los puertos, –checks para elegir comprobaciones y -o o –output para el fichero de resultados. Un ejemplo sobre una red 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. El ejemplo prueba root, alpine y nobody, y cada equipo puede ajustar la lista a las cuentas que existen en sus imágenes. La comprobación vuln-sshhole ya viene activada por defecto, pero indicarla con –checks deja el escaneo centrado en lo que interesa en este caso. Si algún servidor escucha en un puerto distinto del 22, hay que reflejarlo en -p.
La salida es JSONL (JSON Lines, un objeto JSON por línea), un formato cómodo para filtrarlo con jq, cargarlo en una hoja de cálculo o enviarlo a un SIEM (sistema de gestión de información y eventos de seguridad). Lo prudente es empezar por un segmento pequeño, revisar el resultado a mano y ampliar después al resto del direccionamiento.
Un inventario periódico sin provocar bloqueos
Una comprobación aislada sirve hoy, pero las imágenes de contenedor y las máquinas nuevas siguen llegando. Por eso tiene sentido programarla, igual que se hizo con el inventario de servidores afectados por el fallo de APT esta misma semana.
El escaneo genera intentos de autenticación reales. Quedan en los registros de cada servidor y pueden activar fail2ban, SSHGuard u otros mecanismos de bloqueo, de modo que el propio escáner acabe vetado o salten alertas en el turno de guardia. Lo razonable es avisar al equipo, lanzar siempre desde una máquina con IP fija y añadir esa dirección a la lista blanca. En fail2ban se hace con la directiva ignoreip del fichero jail.local:
ignoreip = 127.0.0.1/8 ::1 10.20.0.15Para la programación, un temporizador de systemd es más fácil de vigilar que una línea de cron, porque deja registro en el journal y permite repartir la hora de arranque. Basta con un servicio de tipo oneshot en /etc/systemd/system/sshamble-sshhole.service:
[Unit]
Description=Inventario SSHHole con SSHamble
[Service]
Type=oneshot
StateDirectory=sshamble
ExecStart=/usr/local/bin/sshamble scan -u root,alpine,nobody -p 22 --checks vuln-sshhole -o /var/lib/sshamble/sshhole.jsonl 10.20.0.0/24Lenguaje del código: JavaScript (javascript)Y su temporizador en /etc/systemd/system/sshamble-sshhole.timer, en este caso semanal y fuera de horas punta:
[Unit]
Description=Inventario semanal SSHHole
[Timer]
OnCalendar=Mon *-*-* 06:40:00
RandomizedDelaySec=20min
Persistent=true
[Install]
WantedBy=timers.targetLenguaje del código: JavaScript (javascript)Se activa con systemctl daemon-reload y systemctl enable –now sshamble-sshhole.timer, y systemctl list-timers muestra la próxima ejecución. Quien prefiera cron puede usar una línea equivalente que empiece por 40 6 * * 1 seguida del mismo comando. En ambos casos el fichero de salida se sobrescribe en cada pasada, así que si se quiere histórico hay que copiarlo a otra ruta con un pequeño script. También conviene no lanzar a la vez todos los rangos de la organización: repartirlos en varios temporizadores reduce la carga y hace más fácil explicar cualquier alerta.
Qué hacer si aparece un host afectado
Ante un positivo, el orden lógico es mitigar primero y actualizar después. La mitigación es la que indica el aviso de Alpine Linux: fijar PasswordAuthentication no en /etc/ssh/sshd_config y reiniciar el servicio (en Alpine con OpenRC, rc-service sshd restart). Antes de hacerlo hay que confirmar que el acceso por clave funciona, para no quedarse fuera de la máquina.
Después llega la corrección, disponible en Alpine de la 3.16 a edge:
apk update && apk upgrade opensshEn contenedores, actualizar el que está en marcha no basta. Hay que reconstruir las imágenes basadas en Alpine, por ejemplo con docker build –pull, y volver a desplegarlas; de lo contrario el siguiente arranque recupera la versión vulnerable. También toca revisar las cuentas sin contraseña o con «*» en /etc/shadow y decidir si deben existir:
awk -F: '$2 == "*" {print $1}' /etc/shadowLenguaje del código: JavaScript (javascript)Si el host ha estado expuesto a redes que no son de confianza, merece una revisión de los registros de autenticación en busca de accesos inesperados con esas cuentas. Los datos históricos de actividad ayudan a reconstruir lo ocurrido, y la guía de sar para investigar incidentes en Linux explica cómo consultarlos. El último paso es repetir el escaneo sobre ese host y confirmar que ya no aparece.
Preguntas frecuentes
¿Qué servidores pueden estar afectados por SSHHole?
Los que ejecutan OpenSSH anterior a la 10.6p2 compilado con musl y sin PAM, como ocurre en Alpine Linux. El fallo afecta a cuentas con «*» en el campo de contraseña.
¿Qué versión de SSHamble incluye la comprobación vuln-sshhole?
La v0.5.1, publicada el 05/11/2026 con binarios en GitHub. La comprobación viene activada por defecto y se puede seleccionar de forma explícita con –checks vuln-sshhole.
¿Puede el escaneo bloquear la IP desde la que se lanza?
Sí. Los intentos de autenticación quedan registrados y pueden activar fail2ban u otros bloqueos, por lo que conviene avisar al equipo y añadir el origen del escaneo a la lista blanca.
¿Cómo se corrige un host Alpine vulnerable?
Con apk update y apk upgrade openssh, reconstruyendo además las imágenes de contenedor basadas en Alpine. Mientras tanto, PasswordAuthentication no en sshd_config mitiga el problema.
Fuentes:
