Cómo solucionar el error REMOTE HOST IDENTIFICATION HAS CHANGED en SSH

El aviso REMOTE HOST IDENTIFICATION HAS CHANGED aparece cuando el cliente SSH detecta que la clave de identidad del servidor no coincide con la que tenía registrada para ese destino. Puede ocurrir después de reconstruir un servidor o reasignar una IP, pero también puede señalar que estás conectando con otro equipo.

La solución consiste en verificar la nueva identidad y actualizar la entrada correspondiente en known_hosts. No borres el archivo completo ni desactives las comprobaciones de seguridad para hacer desaparecer el mensaje.

Verifica la nueva huella del servidor antes de cambiar known_hosts

Lee el aviso completo y comprueba el destino, el tipo de clave, la nueva huella y el archivo donde aparece la entrada conflictiva. Confirma también que estás utilizando el nombre, la dirección IP y el puerto esperados.

Para contrastar la huella, utiliza una vía independiente de la conexión que está mostrando la advertencia: una consola del proveedor a la que ya tengas acceso autorizado, una consola física o un administrador identificado por un canal conocido.

En un servidor Linux con una clave de host Ed25519 en su ubicación habitual, puedes consultar su huella desde esa consola:

ssh-keygen -l -E sha256 -f /etc/ssh/ssh_host_ed25519_key.pub

Compara el resultado completo con el que muestra el cliente. Si el aviso corresponde a una clave RSA o ECDSA, consulta la clave pública de ese mismo tipo. Las ubicaciones pueden cambiar según la configuración del servidor.

Si no puedes verificar el cambio, no aceptes la nueva identidad. Solicita confirmación al administrador o al proveedor antes de continuar.

Qué significa REMOTE HOST IDENTIFICATION HAS CHANGED

En el uso habitual de OpenSSH, el cliente conserva las claves públicas de los servidores conocidos y las comprueba en conexiones posteriores. La huella es un resumen de una clave, utilizado para facilitar su comparación.

Estas claves identifican al servidor y son distintas de las claves personales que utilizas para iniciar sesión. Por eso, cambiar tu contraseña o generar una nueva clave de usuario no repara este aviso.

La advertencia no demuestra por sí sola que exista un ataque, pero impide dar por válida la identidad anterior. Ignorarla podría hacer que confiaras en una máquina que está suplantando al destino esperado.

Qué cambios legítimos pueden provocar el aviso

Comprueba si se ha producido alguna de estas situaciones:

• Reconstrucción o reinstalación: el servidor puede haber generado claves nuevas.
• Sustitución de una máquina: otro servidor puede haber recibido la misma dirección IP.
• Rotación de claves: el administrador puede haber reemplazado las claves de host.
• Cambio del destino: un nombre DNS, un alias o una IP local pueden estar apuntando a otro equipo.

En plataformas cloud, reconstruir una instancia o reutilizar una IP puede provocar este conflicto. Aun así, el cambio administrativo debe acompañarse de la comprobación de la nueva huella.

Una actualización del sistema no implica necesariamente que las claves cambien. Si nadie reconoce el cambio, investiga el destino antes de modificar la información guardada.

Elimina únicamente la entrada antigua del destino verificado

Una vez verificada la identidad, ejecuta el comando en el equipo cliente que muestra el aviso, utilizando el destino correspondiente:

ssh-keygen -R servidor.ejemplo.com

Si conectas mediante una IP, utiliza esa IP:

ssh-keygen -R 203.0.113.10

Para un puerto distinto del habitual, incluye el destino entre corchetes y el puerto:

ssh-keygen -R "[servidor.ejemplo.com]:2222"

El comando elimina las claves registradas para ese destino en el archivo de hosts conocidos que corresponda. No verifica la nueva clave ni cambia las claves del servidor.

No elimines entradas de otros equipos. Si alternas entre nombre e IP, comprueba cuál está implicado en el aviso antes de modificar ambos.

Dónde está known_hosts en Windows, macOS y Linux

En una configuración habitual del cliente OpenSSH, encontrarás el archivo del usuario en estas ubicaciones:

• Linux y macOS: ~/.ssh/known_hosts.
• OpenSSH en Windows: %USERPROFILE%\.ssh\known_hosts.

La ruta que aparece en la advertencia es la referencia que debes comprobar. Puede existir una configuración personalizada o un archivo global administrado por tu organización.

Para consultar una entrada, incluso si el nombre está almacenado mediante hash, utiliza:

ssh-keygen -F servidor.ejemplo.com

Si el aviso señala otro archivo, puedes especificarlo con -f. Por ejemplo:

ssh-keygen -R servidor.ejemplo.com -f "/ruta/indicada/known_hosts"

Las aplicaciones que utilizan otros clientes, como PuTTY, pueden guardar la confianza de los servidores de otra forma. Este procedimiento corresponde a OpenSSH.

Vuelve a conectar y compara la huella antes de aceptar

Repite la conexión con el nombre y el puerto correctos:

ssh [email protected]

O, si utilizas un puerto personalizado:

ssh -p 2222 [email protected]

En la configuración habitual, SSH solicitará confirmación para la nueva clave. Acepta únicamente si su huella coincide con la que has verificado. Si no coincide, detén la conexión.

Si vuelve a aparecer el conflicto, revisa si has modificado el archivo correcto, si conectas con otro usuario local o si la configuración utiliza un alias de clave de host. En entornos gestionados, solicita la actualización del registro de confianza al administrador.

Qué no debes hacer para quitar la advertencia

No borres todo known_hosts: perderías las referencias de identidad de otros servidores. Tampoco utilices StrictHostKeyChecking=no como arreglo general, porque rebaja la comprobación que ha detectado el cambio.

ssh-keyscan permite obtener las claves que presenta un destino, pero no demuestra que pertenezcan al servidor legítimo. Añadir su salida directamente a los hosts conocidos sin contrastarla conserva el mismo problema de confianza.

Para una rotación planificada, el administrador puede estudiar mecanismos como UpdateHostKeys, que permite aprender claves adicionales desde una conexión ya autenticada. Eso no sustituye la verificación de un cambio inesperado.