Las advertencias «Host key verification failed» y «REMOTE HOST IDENTIFICATION HAS CHANGED» de SSH

Qué es

La página de manual de ssh(1) documenta que el cliente comprueba la clave de host que presenta un servidor contra la entrada guardada para ese host en known_hosts. Si no existe ninguna entrada y la comprobación estricta está activada, o si no se puede mostrar la pregunta de confirmación (BatchMode=yes, sin terminal, como ocurre en la mayoría de las automatizaciones), el cliente aborta con Host key verification failed.. Si la entrada existe pero la clave presentada es distinta, ssh imprime primero una advertencia grande y difícil de pasar por alto que incluye WARNING: REMOTE HOST IDENTIFICATION HAS CHANGED! y una línea sobre un posible ataque de intermediario (man-in-the-middle), indica el archivo y la línea exactos donde está la entrada antigua y termina con el mismo Host key verification failed..

Por qué importa

El mensaje es idéntico tanto si lo causa un ataque real de sustitución de clave como si lo causan varios sucesos totalmente corrientes: un servidor reconstruido o reinstalado desde cero, una IP flotante o un balanceador de carga que ahora apunta a otro host, o una máquina reaprovisionada desde una imagen que regenera sus claves de host en el primer arranque. El texto de la advertencia por sí solo no permite distinguir un ataque de un cambio rutinario de infraestructura, y por eso no es seguro descartarla por reflejo.

Cómo aplicarlo

• Diagnostica antes de cambiar nada: determina si el host puede tener legítimamente una clave nueva. ¿Se reconstruyó, se migró o se redirigió hace poco? Compara las fechas con los cambios de infraestructura conocidos.
• Verifica por un canal independiente: obtén la huella (fingerprint) de la nueva clave por un medio que no sea la propia conexión SSH (el operador del servidor, una función de la consola del proveedor de nube para consultar la clave de un host, o un valor registrado por la gestión de configuración durante el aprovisionamiento) y compárala con la que ssh muestra para la clave recién ofrecida antes de continuar.
• Solo cuando se haya confirmado que la nueva clave es legítima: elimina la entrada obsoleta con ssh-keygen -R hostname, que según ssh-keygen(1) quita de un archivo known_hosts todas las claves pertenecientes al host indicado (para un puerto no estándar la entrada es '[hostname]:2222'; la dirección IP también puede tener su propia entrada). Después vuelve a conectar y acepta la nueva clave.
• Práctica insegura: usar de forma rutinaria ssh -o StrictHostKeyChecking=no, o saltarse la pregunta mediante scripts, como configuración permanente. Eso elimina justamente la protección destinada a detectar una sustitución real de clave, y, en todo caso, debería reservarse para hosts realmente desechables en una red aislada donde el riesgo se haya aceptado de forma explícita, no como solución general a la molestia. Para el primer contacto en automatizaciones, StrictHostKeyChecking=accept-new (OpenSSH 7.6+) registra los hosts desconocidos pero sigue rechazando las claves modificadas; precargar known_hosts con claves verificadas es aún mejor.

Trampas

• Tratar cada aparición como rutinaria porque «normalmente lo es» en tu entorno; ese hábito es justo con lo que cuenta un atacante que confía en que se ignore esta advertencia.
• Borrar el archivo known_hosts completo para «empezar de cero» en lugar de eliminar solo la línea problemática, con lo que se descarta la verificación de todos los demás hosts en los que ya confiabas.