SSH es un protocolo de red seguro que crea un túnel cifrado entre sistemas. Sigue siendo una opción habitual entre los desarrolladores que necesitan acceso remoto a equipos sin interfaz gráfica. Aunque SSH lleva décadas en uso y ha dado un servicio fiable a multitud de usuarios, todavía puede verse afectado por ciertos errores.
Muchos de estos errores son bien conocidos en la comunidad de SSH y sus soluciones están ampliamente documentadas. Entre ellos se encuentran incompatibilidad con el firewall, problemas de inyección de clave pública en SSH, problemas con el modo de clave de archivo en SSH, y el error «Warning: Remote Host Identification Has Changed».
Este error aparece en todos los sistemas operativos principales, incluidos Windows, Linux y macOS. La causa puede ser un problema de seguridad real, no un simple fallo técnico. En este artículo explicamos por qué ocurre, qué implica para la seguridad de tu conexión SSH y cómo resolverlo en cada plataforma.
¿Qué provoca el aviso «Warning: Remote Host Identification Has Changed» y deberías preocuparte?
El aviso «Warning: Remote Host Identification Has Changed» aparece cuando la clave pública SSH almacenada en tu archivo known_hosts no coincide con la clave que el servidor presenta en ese momento. Esta discrepancia activa el mecanismo de seguridad integrado de SSH para protegerte de posibles amenazas.
Motivos legítimos para el cambio de clave de host
Existen varias razones inofensivas por las que la clave de host de un servidor puede cambiar. En algunos casos verás variaciones como «RSA host key has changed», según el tipo de clave en uso.
Cambios en el servidor:
- El sistema operativo del servidor fue reinstalado o actualizado
- El servidor fue reconstruido o restaurado desde una copia de seguridad
- La configuración SSH del servidor fue restablecida
- La máquina física o virtual fue reemplazada
- Migración del servidor a nuevo hardware
Cambios en la configuración de red:
- Los proveedores cloud reutilizan direcciones IP con el tiempo, o tu conexión pasa por un balanceador de carga.
- El servidor DHCP reasignó una dirección IP a una máquina diferente
- La IP de un servidor dado de baja fue asignada a un nuevo sistema
- Los registros DNS fueron actualizados para apuntar a un servidor diferente
Gestión de claves:
- Los administradores de sistemas regeneraron manualmente las claves de host por motivos de seguridad
- El software del servidor SSH fue reinstalado
- Las políticas de seguridad exigían la rotación de claves
Es importante tener en cuenta que los cambios de contraseña de usuario no afectan a las claves del host. Son mecanismos de autenticación independientes. Las claves del host solo cambian cuando se modifica el propio servidor o su configuración SSH.
Cuándo tomarse la advertencia en serio
Aunque muchos cambios de clave de host son legítimos, en algunos casos pueden indicar una amenaza de seguridad real. Deberías preocuparte si:
- No realizaste ningún cambio en el servidor ni tienes conocimiento de ningún mantenimiento programado
- No puedes verificar el motivo del cambio de clave con el administrador del servidor
- Se accede al servidor a través de redes públicas o conexiones no confiables
- Te estás conectando a sistemas en producción o servidores que contienen datos sensibles
Los ataques de intermediario, aunque relativamente poco frecuentes, ocurren. En este tipo de ataque, un atacante se sitúa entre tu equipo y el servidor legítimo, interceptando todo el tráfico.
El error humano y la ingeniería social representan el 68 % de las brechas de seguridad, lo que hace que la vigilancia sea clave. Puedes proteger tus sistemas aún más aprendiendo sobre prevención de ataques de fuerza bruta.
Estadísticas recientes de IBM muestran que el coste medio global de una brecha de datos fue de 4,44 millones de dólares en 2025, con tiempos de detección que promedian ocho meses. Esto explica por qué existe el mecanismo de verificación de claves de host de SSH y por qué nunca debes ignorar estas advertencias sin investigar.
Cómo verificar si la advertencia es segura
Antes de proceder a resolver el problema, sigue estos pasos de verificación:
- Consulta con tu equipo: Si compartes el acceso al servidor, pregunta a tus compañeros si realizaron algún cambio
- Revisa los registros del servidor: Comprueba los registros de mantenimiento o de cambios para detectar actividad reciente
- Contacta con tu proveedor de alojamiento: Si usas servicios en la nube, verifica si se realizó algún mantenimiento
- Usa un canal seguro: Si es posible, conéctate a través de una red segura conocida para verificar la huella digital
- Compara las huellas digitales: Algunos proveedores de hosting muestran las huellas digitales actuales de SSH en sus paneles de control
Si puedes confirmar que el cambio de clave fue legítimo, puedes eliminar la clave antigua y aceptar la nueva sin problema.
Si quieres evitar la reasignación dinámica de IPs o los conflictos de claves de host, la infraestructura que elijas tiene un peso importante.
Cloudzy ofrece Hosting SSH VPS con IPs estáticas dedicadas. Funciona sobre procesadores AMD Ryzen 9 con almacenamiento NVMe para una ejecución de comandos instantánea. Nuestra red alcanza los 40 Gbps en 12 ubicaciones a nivel global. Además, incluimos protección DDoS gratuita para mantener tu conexión segura.
Cómo solucionar el error «Remote Host Identification Has Changed»
La solución es sencilla: elimina el registro de clave antiguo de tu sistema. Esto resuelve el conflicto y te permite guardar la nueva clave la próxima vez que te conectes. Consulta nuestra guía sobre clientes SSH para más herramientas.
Además, puedes hacerlo con un solo comando o editando el archivo manualmente.
Método 1: La línea de comandos (más rápido)
Este método funciona en macOS, Linux y Windows 10+ (con OpenSSH). Es la forma más rápida de resolver el error. Para más información, puedes consultar la página man de ssh-keygen.
- Abre tu terminal.
- Ejecuta este comando (reemplaza hostname con la IP o el dominio de tu servidor):
ssh-keygen -R hostnameSi prefieres un editor visual, puedes eliminar la clave tú mismo. El mensaje de error suele indicarte exactamente qué número de línea debes borrar.
Abre tu terminal y edita el archivo con Nano:
nano ~/.ssh/known_hosts
Localiza la línea que indica el mensaje de error. Bórrala y pulsa Ctrl + X y Y para guardar.
Solución para Windows
Los usuarios de Windows suelen utilizar el cliente OpenSSH integrado o PuTTY.
Opción 1: Windows OpenSSH (Windows 10/11)
En Windows 10 y 11, OpenSSH es una característica opcional. Puedes añadirla desde Configuración > Aplicaciones > Características opcionales. Server 2025 incluye el cliente, pero hay que activarlo manualmente.
Si usas PowerShell o el Símbolo del sistema, el comando ssh-keygen del Método 1 también funciona aquí.
Para editar el archivo manualmente:
- Pulsa Windows + R.
- Tipo %USERPROFILE%\.ssh y pulsa Enter.
- Abre el archivo known_hosts archivo con el Bloc de notas.
- Elimina la línea que causa el error y guarda el archivo.
Para gestionar las claves correctamente, consulta nuestra guía sobre cómo generar claves SSH en Windows.
Opción 2: Usar PuTTY
PuTTY almacena las claves en el Registro de Windows, no en un archivo.
- Abre el Editor del Registro (pulsa Windows + R, escribe regedity presiona Enter).
- Navega a: HKEY_CURRENT_USER\Software\SimonTatham\PuTTY\SshHostKeys\
- Busca la entrada que corresponda al nombre de host o la IP de tu servidor.
- Haz clic derecho y selecciona Eliminar.
Solución para Linux
El ssh-keygen comando que vimos en Método 1 es la forma estándar de resolver esto en Linux. Es rápido y tiene soporte nativo.
Edición manual
Si prefieres ver el contenido del archivo, puedes editarlo con un editor de texto como Nano.
- Abre tu terminal.
- Tipo nano ~/.ssh/known_hosts y pulsa Enter.
- Busca el número de línea que aparece en el mensaje de error.
- Elimina la línea y pulsa Ctrl + X y Y para guardar.
También puedes usar Vim (vim ~/.ssh/known_hosts) si estás familiarizado con él.
Advertencia sobre la desactivación de verificaciones
Puedes forzar la conexión de SSH sin verificación, pero conlleva riesgos. Omite la protección contra ataques de tipo man-in-the-middle.
Usa este método solo para pruebas locales en redes de confianza. En macOS y Linux, escribe lo siguiente:
ssh -o StrictHostKeyChecking=no -o UserKnownHostsFile=/dev/null [email protected]Si estás en Windows, la ruta Unix no funciona. Debes usar NUL para que el bypass funcione:
ssh -o StrictHostKeyChecking=no -o UserKnownHostsFile=NUL [email protected]No ejecutes estas configuraciones en conexiones públicas ni en servidores en producción.
Corregir discrepancias de claves es mantenimiento habitual, pero puedes hacer más para proteger tu conexión. Los bots suelen atacar el puerto por defecto 22 con ataques de fuerza bruta. Puedes evitar la mayor parte de este tráfico no deseado cambiando los puertos de SSH en Linux por uno menos predecible.
Nunca uses este método en servidores en producción ni en redes que no sean de confianza.
Cómo evitar el mensaje «Remote Host Identification Has Changed» en el futuro
No siempre es posible prevenir cambios legítimos en las claves de host, pero sí puedes reducir las interrupciones y mantener mejores prácticas de seguridad.
Guía de referencia rápida
| Tu Rol | Estrategias Clave |
| Administradores de Sistemas | Haz copias de seguridad de las claves, documenta los cambios, usa certificados y rota las claves periódicamente |
| Usuarios Habituales | Mantén un inventario, verifica a través de canales seguros y supervisa los registros |
| Entorno en la Nube
Usuarios |
Usa nombres DNS, aprovecha las herramientas del proveedor e implementa infraestructura como código |
Para Administradores de Sistemas
Haz copias de seguridad de las claves de host: Guarda las claves de /etc/ssh/ antes de reinstalar el sistema operativo. Restáuralas después para evitar advertencias a tus usuarios.
Documenta los cambios planificados: Avisa a los usuarios antes de cambiar las claves y comparte las nuevas huellas digitales por un canal seguro. Así podrán verificar la conexión.
Usa certificados SSH: Los equipos grandes deben usar una autoridad de certificación centralizada. Esta firma las claves de host y elimina la necesidad de verificación manual.
Implementa la rotación de claves: Planifica los cambios de claves de host con antelación. Las actualizaciones predecibles son más fáciles de gestionar para tu equipo que los cambios inesperados.
Para Usuarios Habituales
Mantén un inventario: Lleva un registro personal de las huellas digitales de los servidores o usa la documentación segura de tu equipo.
Verifica por un canal alternativo: Confirma las claves contra una fuente de confianza, como la consola de la nube, no a través de mensajes informales.
Monitoriza los logs: Revisa regularmente los logs locales de SSH en busca de patrones de conexión inusuales o errores repetidos.
Usa gestión de configuración: Utiliza los archivos de configuración de SSH para gestionar entornos de desarrollo dinámicos sin reducir la seguridad.
Para entornos cloud dinámicos
Usa nombres DNS: Conéctate mediante nombres de host en lugar de IPs. Así se mantiene la consistencia cuando cambia la dirección subyacente.
Usa las herramientas cloud: Consulta las consolas de tu proveedor para obtener las huellas digitales actuales. Verifica las claves con estas herramientas antes de aceptar cualquier cambio.
Infraestructura como código: Automatiza la verificación de claves con herramientas como Terraform. Para configuraciones avanzadas, también puedes usar proxies SOCKS5 de SSH.
Hosts bastión: Configura servidores de salto con claves estables. Actúan como puntos de entrada seguros a tu infraestructura dinámica.
Conclusión
El aviso «Warning: Remote Host Identification Has Changed» es una función de seguridad importante de SSH, no un fallo que ignorar. Aunque este aviso suele aparecer por motivos legítimos como el mantenimiento del servidor o cambios de configuración, desempeña un papel clave en la protección frente a ataques de intermediario y accesos no autorizados.
Cuando aparezca este aviso, verifica la causa antes de continuar. En la mayoría de los casos, la solución es directa: elimina la clave de host antigua mediante los métodos descritos para tu sistema operativo y acepta la nueva clave en la siguiente conexión.
Entender cómo funcionan las claves de host de SSH y seguir las buenas prácticas te permite mantener tanto la seguridad como la comodidad en tus flujos de acceso remoto. Para más información sobre la transferencia segura de archivos, consulta copiar archivos mediante SSH.
