50% de descuento Todos los planes, tiempo limitado. A partir de $2.48/mo
Quedan 10 minutos
Seguridad y redes

Advertencia: la identificación del host remoto ha cambiado y cómo solucionarlo

Rexa Ciro By Rexa Ciro 10 minutos de lectura Actualizado hace 52 días
Ventana de terminal que muestra un mensaje de advertencia SSH sobre el cambio de identificación del host remoto, con el título de Fix Guide y la marca Cloudzy sobre un fondo verde azulado oscuro.

SSH es un protocolo de red seguro que crea un túnel cifrado entre sistemas. Sigue siendo popular entre los desarrolladores que necesitan acceso remoto a las computadoras sin necesidad de una interfaz gráfica de usuario. Si bien SSH existe desde hace décadas y ha brindado servicios a innumerables usuarios de manera confiable, aún puede verse afectado por ciertos errores.

Muchos de estos errores se han vuelto muy conocidos en la comunidad SSH y sus soluciones están ampliamente documentadas. Estos incluyen incompatibilidad del cortafuegos, Problemas de inyección de clave pública SSH, Problemas con el modo de clave de archivo SSHy el error "Advertencia: la identificación del host remoto ha cambiado".

Este error ocurre en todos los principales sistemas operativos, incluidos Windows, Linux y macOS. La fuente del problema podría ser una preocupación de seguridad legítima en lugar de un simple fallo técnico. En este artículo, explicaremos por qué sucede esto, qué significa para la seguridad de su conexión SSH y cómo resolverlo en cada plataforma principal.

Qué desencadena la advertencia: la identificación del host remoto ha cambiado (¿y debería preocuparse?)

La “Advertencia: La identificación del host remoto ha cambiado” aparece cuando la clave pública SSH almacenada en su hosts_conocidos El archivo no coincide con la clave que presenta actualmente el servidor. Esta discrepancia activa el mecanismo de seguridad integrado de SSH para protegerlo de posibles amenazas.

Razones legítimas para realizar cambios en la clave del host

Varias razones inocentes explican por qué la clave de host de un servidor puede cambiar. A veces verá variaciones como "La clave de host RSA ha cambiado", según el tipo de clave específica que se utilice.

Infografía que muestra los cambios del servidor que modifican las claves del host SSH, incluidas actualizaciones del sistema operativo, reconstrucciones del servidor, restauración de copias de seguridad, migración física a virtual y restablecimientos de la configuración SSH.
Cambios relacionados con el servidor:

  • El sistema operativo del servidor fue reinstalado o actualizado
  • El servidor fue reconstruido o restaurado a partir de una copia de seguridad.
  • Se restableció la configuración SSH del servidor
  • Se reemplazó la máquina física o virtual.
  • Migración del servidor a nuevo hardware

Cambios en la configuración de la red:

  • Los proveedores de la nube reciclan las direcciones IP con el tiempo o su conexión se enruta a través de un equilibrador de carga.
  • DHCP reasignó una dirección IP a una máquina diferente
  • La IP de un servidor fuera de servicio se asignó a un nuevo sistema
  • Los registros DNS se actualizaron para apuntar a un servidor diferente

Diagrama de red que muestra un servidor DHCP que asigna direcciones IP dinámicas a máquinas virtuales, y el desmantelamiento y la reemisión del servidor provocan conflictos con las claves del host SSH.

Acciones clave de gestión:

  • Los administradores del sistema regeneraron manualmente las claves de host por motivos de seguridad.
  • Se reinstaló el software del servidor SSH
  • Las políticas de seguridad requerían rotación de claves

Es importante reconocer que los cambios de contraseña de usuario no afectan las claves del host. Estos representan mecanismos de autenticación separados. Las claves de host cambian solo cuando se modifica el servidor mismo o su configuración SSH.

Cuándo tomar en serio la advertencia

Si bien muchos cambios de clave de host son legítimos, esto podría indicar una amenaza genuina a la seguridad. Debería preocuparse si:

  • No realizó ningún cambio en el servidor ni conoce ningún mantenimiento programado.
  • No puede 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 de producción o servidores que contienen datos confidenciales.


Pantalla dividida que compara los cambios legítimos de SSH que se muestran en verde con los escenarios de amenazas a la seguridad en rojo, con una figura encapuchada que representa los ataques de intermediario.
Los ataques de intermediario, aunque son relativamente raros, ocurren. En tales ataques, un adversario se posiciona entre su computadora y el servidor legítimo, interceptando todo el tráfico.

error humano y la ingeniería social representan el 68% de las violaciones de seguridad, lo que hace que la vigilancia sea clave. Puede proteger aún más sus sistemas si aprende sobre Prevención de ataques de fuerza bruta.

Estadísticas recientes de IBM muestran que el costo promedio global de un violación de datos fue de 4,44 millones de dólares en 2025, con tiempos de detección promedio de ocho meses. Esto demuestra por qué existe el mecanismo de verificación de clave de host de SSH y por qué nunca se deben ignorar estas advertencias sin investigar.

Cómo verificar si la advertencia es segura

Antes de proceder a solucionar el problema, siga estos pasos de verificación:

Diagrama de flujo que muestra cinco métodos de verificación para confirmar cambios legítimos en la clave de host SSH, incluida la consulta del equipo, el contacto con el proveedor de alojamiento, los canales seguros y la comparación de huellas digitales.

  1. Consulta con tu equipo: Si comparte el acceso al servidor, pregunte a sus colegas si hicieron cambios
  2. Revisar los registros del servidor: Verifique los registros de mantenimiento o cambie los registros para detectar actividad reciente
  3. Póngase en contacto con su proveedor de alojamiento: Si utiliza servicios en la nube, verifique si se realizó mantenimiento
  4. Utilice un canal seguro: Si es posible, conéctese a través de una red segura conocida para verificar la huella digital.
  5. Comparar huellas dactilares: Algunos proveedores de hosting muestran huellas digitales SSH actuales en sus paneles de control

Si puede confirmar que el cambio de clave fue legítimo, puede proceder con seguridad a eliminar la clave anterior y aceptar la nueva.

Si desea evitar la reasignación dinámica de IP o conflictos de claves de host, la infraestructura que elija juega un papel importante.

Cloudzy proporciona Alojamiento VPS SSH con IP estáticas dedicadas. Se ejecuta en procesadores AMD Ryzen 9 con almacenamiento NVMe para la ejecución instantánea de comandos. Nuestra red alcanza 40 Gbps en 12 ubicaciones globales. Además, incluimos protección DDoS gratuita para mantener segura tu conexión.

Cómo solucionar el error "La identificación del host remoto ha cambiado"

La solución es simple: elimine el registro de clave antiguo de su sistema. Esto elimina la discrepancia y le permite guardar la nueva clave la próxima vez que se conecte. Consulte 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 comando (más rápida)

Este método funciona para macOS, Linux y Windows 10+ (usando OpenSSH). Es la forma más rápida de resolver el error. Para más información, puedes leer el página de manual de ssh-keygen

  1. Abre tu terminal.
  2. Ejecute este comando (reemplace nombre de host con la IP o dominio de su servidor): 
ssh-keygen -R hostname
This command automatically finds the old key in your known_hosts file and deletes it.  Method 2: Manual File Editing (macOS)

Si prefiere un editor visual, puede eliminar la clave usted mismo. El mensaje de error generalmente le indica exactamente qué número de línea debe eliminar.

Abra su terminal y edite el archivo con nano:

nano ~/.ssh/known_hosts

Busque la línea de su mensaje de error. Bórralo y luego presiona Ctrl+X y Y para ahorrar.

Ventana de terminal de macOS que muestra el editor de texto nano abierto con el archivo conocido_hosts, resaltando la línea para eliminar con pasos numerados y guardando las instrucciones mostradas.

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. Agréguelo a través de Configuración > Aplicaciones > Funciones opcionales. Server 2025 incluye el cliente, pero debes activarlo.

Si usa PowerShell o el símbolo del sistema, el ssh-keygen El comando del Método 1 también funciona aquí.

Para editar el archivo manualmente:

  1. Prensa Tecla Windows + R.
  2. Tipo %PERFIL DE USUARIO%\.ssh y presione Ingresar.
  3. Abre el hosts_conocidos archivo con el Bloc de notas.
  4. Elimine la línea que causa el error y guarde el archivo.

Para administrar las claves correctamente, consulte nuestra guía sobre generando claves SSH en Windows.

Opción 2: usar PuTTY

PuTTY almacena claves en el Registro de Windows en lugar de en un archivo.

  1. Abra el Editor del Registro (presione Tecla Windows + R, tipo regedit, y golpe Ingresar).
  2. Navega a: HKEY_CURRENT_USER\Software\SimonTatham\PuTTY\SshHostKeys\
  3. Busque la entrada que coincida con el nombre de host o la IP de su servidor.
  4. Haga clic derecho y seleccione Borrar.

Comando de Windows PowerShell que elimina la clave de host SSH con el Explorador de archivos que muestra el archivo conocido_hosts actualizado y el Editor del Registro PuTTY que muestra el cuadro de diálogo de confirmación de eliminación de la clave de host.

Solución para Linux

El ssh-keygen comando que cubrimos Método 1 es la forma estándar de solucionar este problema en Linux. Es rápido y soportado de forma nativa.

Edición manual

Si prefieres ver el contenido del archivo, puedes editarlo con un editor de texto como Nano.

  1. Abre tu terminal.
  2. Tipo nano ~/.ssh/known_hosts y presione Ingresar.
  3. Busque el número de línea mencionado en su mensaje de error.
  4. Elimine la línea, luego presione Ctrl+X y Y para ahorrar.

También puedes usar Empuje (vim ~/.ssh/known_hosts) si está familiarizado con él.

Terminal de Linux que muestra comandos ssh-keygen para eliminar claves de host SSH por nombre de host y dirección IP, con confirmación de éxito y ejemplos de archivosknown_hosts.
Una advertencia sobre la desactivación de controles

Puede forzar la conexión de SSH sin verificación, pero esto es arriesgado. Omite la protección contra ataques de intermediario.

Utilice este enfoque únicamente para pruebas locales en redes confiables. Para macOS y Linux, escriba esto:

ssh -o StrictHostKeyChecking=no -o UserKnownHostsFile=/dev/null [email protected]

Si está en Windows, la ruta de Unix falla. debes usar NUL para que el bypass funcione:

ssh -o StrictHostKeyChecking=no -o UserKnownHostsFile=NUL [email protected]

No ejecute estas anulaciones en conexiones públicas o servidores activos.

Arreglar las discrepancias de claves es un mantenimiento de rutina, pero puedes hacer más para proteger tu conexión. Los bots suelen atacar el puerto 22 predeterminado con ataques de fuerza bruta. Puede evitar la mayor parte de este ruido de fondo si cambiar los puertos SSH en Linux a algo menos predecible.

Diagrama de un ataque de intermediario a SSH: atacante interceptando la conexión cliente-servidor, clave del atacante versus clave del servidor, robo de datos y pérdida financiera resaltados.

Nunca utilice este método para servidores de producción o en redes que no sean de confianza.

Cómo evitar que la próxima vez aparezca el mensaje "La identificación del host remoto ha cambiado"

Si bien no siempre es posible evitar cambios legítimos en la clave del host, sí se pueden minimizar las interrupciones y mantener mejores prácticas de seguridad.

Guía de referencia rápida

Tu papel Estrategias clave
Administradores del sistema Realice copias de seguridad de claves, documente cambios, utilice certificados y rote claves periódicamente
Usuarios habituales Mantenga el inventario, verifique a través de canales seguros y supervise los registros.
Entorno de nube 

Usuarios

Utilice nombres DNS, aproveche las herramientas del proveedor e implemente infraestructura como código

Infografía que muestra las mejores prácticas de administración de claves SSH: usar certificados SSH, nombres DNS, infraestructura como código, realizar copias de seguridad de claves de host, documentar cambios y considerar hosts bastión.

Para administradores de sistemas

Copia de seguridad de claves de host: Guardar claves de /etc/ssh/ antes de reinstalar el sistema operativo. Restáurelos después para evitar advertencias para sus usuarios.

Documentar los cambios planificados: Alerte a los usuarios antes de cambiar las claves y comparta las nuevas huellas digitales de forma segura. Esto les permite verificar la conexión.

Utilice certificados SSH: Los equipos grandes deben utilizar una autoridad de certificación central. Esto firma las claves del host y elimina la necesidad de verificación manual.

Implementar rotación de claves: Programe los cambios de clave de host. Las actualizaciones predecibles son más fáciles de manejar para su equipo que las sorpresa.

Para usuarios habituales

Mantener un inventario: Mantenga un registro personal de las huellas digitales del servidor o utilice la documentación segura de su equipo.

Verificar vía fuera de banda: Confirme las claves con una fuente confiable como la consola en la nube, no con mensajes casuales.

Monitorear registros: Verifique sus registros SSH locales con regularidad para detectar patrones de conexión extraños o errores repetidos.

Utilice la gestión de configuración: Utilice archivos de configuración SSH para manejar entornos de desarrollo dinámicos sin reducir la configuración de seguridad.

Para entornos dinámicos de nube

Utilice nombres DNS: Conéctese utilizando nombres de host en lugar de IP. Esto mantiene la coherencia cuando cambia la dirección subyacente.

Aproveche las herramientas de la nube: Utilice las consolas del proveedor para recuperar las huellas digitales actuales. Verifique las claves con estas herramientas antes de aceptar cambios.

Infraestructura como código: Automatice la verificación de claves con herramientas como Terraform. Para configuraciones avanzadas, también puede utilizar servidores proxy SSH SOCKS5.

Anfitriones bastión: Configure servidores de salto con claves estables. Estos actúan como puntos de entrada seguros a su infraestructura dinámica.

Conclusión

La “Advertencia: la identificación del host remoto ha cambiado” sirve como una característica de seguridad importante de SSH, no como una falla que deba ignorarse. Si bien esta advertencia suele aparecer por motivos legítimos, como mantenimiento del servidor o cambios de configuración, desempeña un papel clave a la hora de protegerle contra ataques de intermediarios y accesos no autorizados.

Cuando encuentre esta advertencia, verifique la causa antes de continuar. En la mayoría de los casos, la solución es sencilla: elimine la clave de host anterior utilizando los métodos descritos para su sistema operativo y luego acepte la nueva clave en su próxima conexión.

Al aprender cómo funcionan las claves de host SSH y seguir las mejores prácticas, podrá mantener tanto la seguridad como la comodidad en sus flujos de trabajo de acceso remoto. Para obtener más información sobre la transferencia de archivos de forma segura, consulte copiar archivos a través de SSH.

 

Preguntas frecuentes

¿Debo tomar en cuenta la advertencia: la identificación del host remoto ha cambiado seriamente?

Sí, tómalo en serio. Significa que la identidad del servidor cambió, lo que podría indicar un ataque de intermediario o simplemente un mantenimiento de rutina. Verifique siempre el cambio con su administrador o proveedor antes de aceptar la nueva clave para garantizar la seguridad.

¿Qué causa la advertencia: la identificación del host remoto ha cambiado?

Esta advertencia ocurre cuando la huella digital actual del servidor no coincide con la del archivo conocido_hosts. Las causas comunes incluyen reinstalaciones del sistema operativo, reasignaciones de IP o restablecimientos de la configuración de SSH. En casos raros, indica una intercepción activa de un ataque de intermediario.

¿Puede ocurrir este error en diferentes sistemas operativos?

Sí, esta advertencia afecta a todos los sistemas operativos que utilizan SSH, incluidos Windows, macOS y Linux. Surge de la verificación de seguridad del protocolo SSH. Si bien los métodos de reparación varían según la plataforma, el activador de seguridad subyacente sigue siendo idéntico en todos los sistemas.

¿Cómo sé si el cambio de clave de host es legítimo o un ataque?

Para confirmar la legitimidad, verifique el mantenimiento reciente, las actualizaciones del sistema operativo o los cambios de IP. Debe verificar la nueva huella digital con una fuente confiable, como la consola de su proveedor de nube o una confirmación del administrador del sistema, antes de conectarse.

¿Deshabilitar la verificación de claves de host hará que SSH sea más conveniente?

Agrega comodidad pero elimina seguridad. Deshabilitar las comprobaciones anula la protección contra ataques de intermediarios, dejando las conexiones vulnerables. Sólo debe utilizar esta configuración en entornos de prueba aislados, nunca en servidores de producción o redes públicas que involucren datos confidenciales.

¿Con qué frecuencia se deben cambiar las claves del host SSH?

Las claves de host generalmente no requieren una rotación regular. Por lo general, debe cambiarlos solo después de una reconstrucción del servidor, una reinstalación del sistema operativo o una seguridad comprometida. Los cambios frecuentes perturban a los usuarios, así que priorice la estabilidad y la comunicación clara cuando sean necesarias actualizaciones.

Compartir

Más del blog

Sigue leyendo.

Una imagen de título de Cloudzy para una guía de VPN MikroTik L2TP, que muestra una computadora portátil que se conecta a un rack de servidores a través de un túnel digital azul y dorado brillante con íconos de escudo.
Seguridad y redes

Configuración de MikroTik L2TP VPN (con IPsec): Guía de RouterOS (2026)

En esta configuración de VPN MikroTik L2TP, L2TP maneja el túnel mientras IPsec maneja el cifrado y la integridad; emparejarlos le brinda compatibilidad con el cliente nativo sin la edad de terceros

Rexa CiroRexa Ciro 9 minutos de lectura
Ilustración de la guía de solución de problemas del servidor DNS con símbolos de advertencia y servidor azul sobre fondo oscuro para errores de resolución de nombres de Linux
Seguridad y redes

Fallo temporal en la resolución de nombres: ¿Qué significa y cómo solucionarlo?

Mientras usa Linux, puede encontrar una falla temporal en el error de resolución de nombres al intentar acceder a sitios web, actualizar paquetes o ejecutar tareas que requieren una conexión a Internet.

Rexa CiroRexa Ciro 12 minutos de lectura
Cómo apuntar un dominio a VPS: una guía rápida
Seguridad y redes

Cómo apuntar un dominio a VPS: una guía rápida

Es necesario apuntar un dominio a un servidor privado virtual para alojar sitios web y aplicaciones. Esta guía cubre todo lo que necesita saber sobre cómo conectar su dominio a su

Rexa CiroRexa Ciro 16 minutos de lectura

¿Listo para implementar? Desde $2,48/mes.

Nube independiente, desde 2008. AMD EPYC, NVMe, 40 Gbps. Devolución de dinero en 14 días.