Guías de tecnología · GUÍA PRÁCTICA
¿SSH muestra “REMOTE HOST IDENTIFICATION HAS CHANGED”? Verifica el destino y la huella antes de borrar la clave anterior
No borres known_hosts ni desactives la comprobación solo para ocultar el aviso. Identifica el nombre, la dirección, el puerto, la ruta de salto y el archivo de confianza que SSH usó; obtén la huella esperada por un canal fiable independiente y elimina únicamente el registro obsoleto cuando coincida.
Un aviso de clave de host SSH es un fallo de identidad, no un simple error de conexión. Antes de cambiar la confianza local, demuestra a qué servidor llegaste y qué clave debería presentar.
Trata el aviso como prueba, no como obstáculo
OpenSSH guarda la clave pública del servidor en known_hosts. Si el mismo destino presenta otra clave, rechaza la conexión porque no puede saber si hubo reconstrucción, rotación, traslado, sustitución o interceptación. Verifica la identidad antes de limpiar.
Conserva el aviso completo: nombre, IP, puerto, tipo de clave, huella SHA256, archivo y línea. VS Code Remote SSH, Git, rsync o un IDE pueden usar otra configuración, puerto, salto o archivo de confianza.
1. Identifica el destino real de SSH
Revisa `ssh -G host`, en especial `hostname`, `port`, `proxyjump`, `proxycommand`, `userknownhostsfile` y `globalknownhostsfile`. Un alias puede apuntar a otro DNS, una dirección privada tras un bastión o un puerto no estándar.
Resuelve el nombre por la red habitual y compáralo con el aviso, inventario, consola o registro del administrador. DNS dividido por VPN, balanceadores, direcciones reutilizadas y saltos pueden llevar a otra máquina. Si no puedes explicar la ruta, detente.
Comprueba también `hostkeyalias`: si está configurado, sustituye al nombre real para consultar la base de claves. Usa la identidad y el archivo que SSH indique; el alias de la línea de comandos no siempre es el nombre guardado.
2. Obtén la huella esperada fuera de banda
Usa una consola autenticada del proveedor, consola serie/recuperación, registro de configuración o administrador verificado. En la consola del servidor puede ejecutarse `ssh-keygen -lf /etc/ssh/ssh_host_ed25519_key.pub` y comandos equivalentes para otras claves activas.
Pide algoritmo y huella SHA256 completa. Un aviso de mantenimiento explica una rotación, pero no sustituye la huella. `ssh-keyscan` observa lo que presenta la ruta actual; no es prueba independiente de identidad.
3. Compara el mismo algoritmo
Compara ED25519 con ED25519, RSA con RSA y ECDSA con ECDSA. Puede haberse rotado un algoritmo mientras otra clave guardada sigue válida; confirma qué clave negoció el cliente.
Continúa solo si el destino está explicado y la huella coincide exactamente con el valor independiente. Si difiere, contacta al responsable y conserva el registro anterior. La línea indicada diagnostica; no autoriza a confiar.
4. Localiza el registro exacto de known_hosts
Copia el archivo indicado y ejecuta `ssh-keygen -F host`; para puerto no estándar, `ssh-keygen -F '[host]:2222'`. Comprueba también la IP si estaba guardada. `-F` encuentra nombres con hash sin exponer ni borrar otras líneas.
Para otro archivo añade `-f /path/to/file`. Un archivo global puede requerir administrador. Con un salto, decide primero si el aviso pertenece al bastión o al destino final.
5. Elimina solo el destino obsoleto verificado
Tras confirmar coincidencia y causa legítima, ejecuta `ssh-keygen -R host`; para puerto no estándar usa `ssh-keygen -R '[host]:2222'` y añade `-f` si corresponde. Verifica por separado nombre e IP.
Guarda la copia hasta validar la nueva conexión. No borres `~/.ssh/known_hosts`, grupos amplios de líneas ni desactives StrictHostKeyChecking: perderías pruebas y protección para otros servidores.
`ssh-keygen -R` elimina todas las claves del nombre o [nombre]:puerto exacto en el archivo elegido, no solo el algoritmo que cambió. Revisa primero todos los registros coincidentes. Si hay registros administrados o claves de otros algoritmos cuya validez no puedes determinar, pide ayuda al administrador.
6. Reconecta una vez y vuelve a verificar
Reconecta de forma interactiva, confirma destino y algoritmo, y compara otra vez la huella mostrada con el valor fiable antes de aceptarla. Registra causa, fuente, huellas anterior/nueva, hora y aprobador.
Detente si cambia otra vez, distintos servidores tras el mismo nombre muestran claves inexplicables o solo una red/cliente avisa. Puede ser DNS incoherente, balanceador, proxy inesperado, archivos distintos o un incidente.
Cambios legítimos y motivos para escalar
Una VM reconstruida con IP estática, rotación documentada, restauración, sustitución de equipo o alias trasladado puede cambiar legítimamente. Aun así, el responsable debe confirmar destino y huella.
Escala si nadie esperaba el cambio, no se obtiene la huella desde una consola fiable, DNS/ruta cambió, las huellas difieren o la clave cambia repetidamente. No introduzcas credenciales mientras la identidad siga sin resolver.
