known_hosts de SSH y verificación de claves de host en automatización: ssh-keyscan más una comprobación fuera de banda

Objetivo

Rellenar known_hosts para un servidor al que un proceso automatizado (un agente, un pipeline de despliegue) debe conectarse por SSH, sin dejar la primera conexión expuesta a un ataque de intermediario (machine-in-the-middle) y sin el aviso interactivo "yes/no" que interrumpe las ejecuciones desatendidas.

Requisitos previos

Acceso de red al puerto SSH del host de destino y una forma de obtener la huella (fingerprint) de la clave del host por un canal distinto de la propia conexión SSH: la salida de consola del proveedor de nube, el inventario de la herramienta de gestión de configuración o el registro de aprovisionamiento del propio host.

Pasos

1. Obtén la clave en un archivo temporal, no directamente en known_hosts: ssh-keyscan -H targethost > targethost.keys (añade -p <port> si el puerto no es el predeterminado). La opción -H almacena el nombre del host como hash en la entrada, de modo que un archivo filtrado no revele en qué hosts se confía. La página del manual advierte de que un archivo known_hosts construido con ssh-keyscan sin verificar las claves deja a los usuarios expuestos a ataques de intermediario, porque registra la clave que el host presente, sea cual sea.
2. Verifica fuera de banda y solo después añade la clave: ssh-keygen -lf targethost.keys muestra las huellas de exactamente lo que se escaneó; compáralas con una huella obtenida de forma independiente y, únicamente si coinciden, ejecuta cat targethost.keys >> ~/.ssh/known_hosts. Fuentes independientes posibles: el registro de la consola de la instancia en el proveedor de nube, un valor anotado durante el aprovisionamiento o un registro DNS SSHFP si la zona está firmada. El RFC 4255 define el registro de recursos SSHFP precisamente para esto: publicar en el DNS la huella de la clave de host para que el cliente pueda comprobarla sin una decisión de confianza manual previa; ssh puede configurarse para consultarlo mediante VerifyHostKeyDNS.
3. Configura en ssh_config el comportamiento del cliente para conexiones desatendidas: StrictHostKeyChecking accept-new (OpenSSH 7.6 y posteriores, documentado en ssh_config(5)) añade sin preguntar las claves de hosts que aún no están en known_hosts, pero se niega a conectar si un host conocido presenta una clave distinta. Esto es diferente de StrictHostKeyChecking no, que además permite continuar la conexión con un host cuya clave ha cambiado (con una advertencia y algunas restricciones) y que no debe usarse en automatización.
4. Establece HashKnownHosts yes (también en ssh_config(5)) para que, si un archivo known_hosts se filtra o se sube por error a un repositorio, no enumere los nombres de host de la infraestructura. El valor predeterminado del proyecto original es no (el /etc/ssh/ssh_config que distribuyen Debian y Ubuntu lo establece en yes), y solo afecta a las entradas nuevas; ssh-keygen -H aplica el hash a un archivo existente.

Resultado esperado

La primera conexión a un host recién aprovisionado funciona de forma no interactiva una vez que su clave se ha registrado y verificado fuera de banda. Una conexión posterior a la misma dirección, si la clave del host cambia de forma inesperada (el host se reinstaló o hay un intermediario real), falla de manera visible en lugar de actualizarse en silencio.

Límites y base de verificación

accept-new protege frente a una clave que cambia después de la primera confianza, no frente a una clave falsa aceptada la primera vez; la comprobación fuera de banda del paso 2 es lo que el paso 3 no puede ofrecer por sí solo. La verificación SSHFP es tan fiable como la zona DNS. VerifyHostKeyDNS tiene como valor predeterminado no; con yes, según ssh_config(5), se confía implícitamente en las claves que coinciden con una huella segura (validada con DNSSEC), mientras que las huellas no seguras se tratan como si la opción fuera ask, es decir, la respuesta solo se muestra y StrictHostKeyChecking sigue decidiendo. Un resultado solo cuenta como seguro si un resolvedor con validación activa la bandera AD y el cliente la acepta; con glibc 2.31 y posteriores esto requiere options trust-ad en /etc/resolv.conf.