OpenSSH

Host key verification failed

SSH se niega a conectar y avisa de que la identificación del servidor ha cambiado. El cliente guarda la huella de cada servidor la primera vez y compara en cada conexión.

Este mensaje es una advertencia de seguridad, no un fallo de configuración. Borrar la entrada sin pensar es exactamente lo que haría falta para que un ataque de intermediario pasara desapercibido, así que primero conviene explicar por qué ha cambiado.

Qué comprobar, y en qué orden

En el orden en que lo miramos nosotros. No es un ranking de frecuencia: no publicamos estadísticas que no hemos medido.

  1. 1

    El servidor se ha reinstalado o reconstruido, y al reinstalar se generan claves de host nuevas. Es el motivo habitual y es legítimo.

    Comprobar

    ssh-keygen -F servidor

    Corregir

    ssh-keygen -R servidor
# Y comparar la huella nueva con la que muestre la consola del proveedor antes de aceptarla.
  2. 2

    La IP se ha reasignado a otra máquina. Frecuente con direcciones dinámicas y con instancias efímeras.

    Comprobar

    ssh-keygen -F 203.0.113.10

    Corregir

    ssh-keygen -R 203.0.113.10
  3. 3

    Conectas a través de un balanceador o un proxy que reparte entre varias máquinas, cada una con su clave.

    Comprobar

    for i in 1 2 3; do ssh-keyscan -t ed25519 servidor 2>/dev/null; done | sort -u

    Corregir

    # Unificar las claves de host entre los nodos, o fijar HostKeyAlias por nodo en ~/.ssh/config.

Un detalle que ahorra tiempo

La huella que devuelve ese comando en el servidor es la que tiene que coincidir con la que el cliente muestra al conectar. Compararlas es la única comprobación que descarta un intermediario; si no cuadran y nadie ha reinstalado nada, no sigas.

Los comandos de esta página se ejecutan en tu servidor y algunos modifican la configuración: léelos antes de pegarlos. Las rutas y los nombres de servicio varían entre distribuciones. Así se elabora este catálogo.