la identificación del host remoto ssh ha cambiado

619

He reinstalado mi servidor y recibo estos mensajes:

[user@hostname ~]$ ssh root@pong
@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@
@    WARNING: REMOTE HOST IDENTIFICATION HAS CHANGED!     @
@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@
IT IS POSSIBLE THAT SOMEONE IS DOING SOMETHING NASTY!
Someone could be eavesdropping on you right now (man-in-the-middle attack)!
It is also possible that a host key has just been changed.
The fingerprint for the RSA key sent by the remote host is
6e:45:f9:a8:af:38:3d:a1:a5:c7:76:1d:02:f8:77:00.
Please contact your system administrator.
Add correct host key in /home/hostname /.ssh/known_hosts to get rid of this message.
Offending RSA key in /var/lib/sss/pubconf/known_hosts:4
RSA host key for pong has changed and you have requested strict checking.
Host key verification failed.

He probado varias soluciones que encontré en Internet. Mi known_hostsarchivo (normalmente en ~/.ssh/known_hosts) está en /var/lib/sss/pubconf/known_hosts. Intenté editarlo, pero permanece en un estado. He instalado ipa-client y tengo Fedora 19. ¿Cómo resuelvo esta advertencia?

Todas las respuestas respondidas hasta ahora funcionan solo si no tiene Freeipa instalado.

La respuesta correcta para freeipa en los comentarios a continuación de adrin está aquí .

Filip Dobrovolný
fuente
1
Acaba de enterarse de las malas que este problema también puede ocurrir si usted tiene conflicto de direcciones IP nslookup su IP a depurar este tema más
sharrajesh
1
Hay un punto muerto aquí. Este está marcado como duplicado para que nadie pueda agregar respuesta y el que vincula está marcado fuera del tema para que nadie pueda agregar respuesta allí también. Si eliminas conocido_hosts, también solucionará el problema.
zar
1
Yo tuve el mismo problema. En aras de la mina y otros, aquí está la pregunta y mi respuesta a ella: superuser.com/questions/1071204/...
adrin
3
Como alguien que busca verificar su clave primero, encontré esta respuesta útil. askubuntu.com/a/83499/620623
Declan McKenna
Como menciona sharrajesh: verifique sus entradas de DNS (en FreeIPA para mí) y vea que no tiene múltiples entradas A con IP a las que no se puede acceder desde la red.
th3penguinwhisperer

Respuestas:

1071

Aquí está la solución más simple.

ssh-keygen -R <host>

Por ejemplo,

ssh-keygen -R 192.168.3.10

Desde la ssh-keygenpágina del manual :

  • -R hostnameElimina todas las claves que pertenecen al nombre de host de un archivo conocido_hosts. Esta opción es útil para eliminar hosts hash (consulte la opción -H más arriba).
Kashif Nazar
fuente
Estoy en Windows y esta solución, ni la eliminación de claves funciona, ¿qué más puedo probar?
jaycode
55
Bien, resulta que en Windows necesito usar el terminal de git bash para esto (o cualquier terminal MingW32). Difícil.
jaycode
25
tenga en cuenta que si se conectó a través de un puerto específico, es posible que deba eliminarlo con una sintaxis similar ssh-keygen -R [127.0.0.1]:3022. Simplemente revise su archivo .ssh / known_hosts para saber qué dice explícitamente.
Adam Johns
44
Cuando intento esto, aparece el error "<nombrehost> no encontrado en ~ / .ssh / known_hosts"
Nodeocrat
3
¿Por qué ocurre esta advertencia?
Vilas Joshi
199

Utilizar

ssh-keygen -R [hostname]

El ejemplo con una dirección IP / nombre de host sería:

ssh-keygen -R 168.9.9.2

Esto actualizará la ofensa de su host desde los conocidos_hosts. También puede proporcionar la ruta de los hosts_conocidos con el indicador -f.

ravi ranjan
fuente
1
Eliminar la clave correspondiente $ ssh-keygen -R {server.name.com}| $ ssh-keygen -R {ssh.server.ip.address}El | $ ssh-keygen -R server.example.com
DaddyMoe
55
¿Cómo una respuesta sin explicación recibe tantos votos positivos? Sin preocupaciones de seguridad, sin explicación ... -1
Daniel W.
44
También parece una copia de la otra respuesta a continuación. Por favor, un mod limpia este desastre ...
Daniel W.
115

Tuve el mismo error después de recrear una imagen de Ubuntu Digital Ocean. Usé el siguiente comando con la dirección IP de mi servidor en lugar de[IP_ADDRESS]

ssh-keygen -R [IP_ADDRESS]
Ben
fuente
Muchas gracias! Estaba usando el nombre de host y solo funcionaba con IP_ADDRESS :)
J. Lopes
1
Esto lo hizo por mí y debería ser la respuesta aceptada. No sé por qué hay dos copias de esta respuesta que llegaron más tarde y ambas tienen más votos a favor.
Wylliam Judd
El tuyo no fue el mismo error; su servidor no estaba ejecutando SSSD. Ver el OP.
Mercury00
39

Cuando reinstala el servidor, su identidad cambia y comenzará a recibir este mensaje. Ssh no tiene forma de saber si ha cambiado el servidor al que se conecta o si se ha agregado un servidor en el medio a su red para detectar todas sus comunicaciones, por lo que le llama la atención.

Simplemente elimine la clave de known_hosts eliminando la entrada correspondiente:

sed '4d' -i /var/lib/sss/pubconf/known_hosts

El 4destá en la cuenta deOffending RSA ...known_hosts:4

interfaz ficticia
fuente
1
Gracias, pero no sé por qué, pero lo elimino y está en él nuevamente. Tengo intentos de detener el servicio sssd y este efecto desapareció, pero después de iniciar sssd, aparece nuevamente.
Filip Dobrovolný
Haga una copia de seguridad de su directorio ~ / .ssh y luego bórrelo. ¿Su servicio sigue volviendo a agregar las claves después de que ~ / .ssh desapareció?
mockinterface
He cambiado el nombre de .ssh a .ssh_old, después de un nuevo intento de conectarlo, simplemente crea un directorio vacío .ssh. Y todavía no puedo hacer / var / lib / sss / pubconf / known_hosts "editable".
Filip Dobrovolný
44
La forma más portátil de hacer esto: sed -i -e 4d /var/lib/sss/pubconf/known_hosts
Pierz
2
¿Cómo hace una copia de seguridad del servidor identificationen caso de que desee reconstruir el servidor sin causar interrupciones como este mensaje de error?
Ninjaxor
38

El mazo es eliminar cada host conocido de una sola vez:

rm ~/.ssh/known_hosts

Me encuentro con esto cuando utilizamos pequeñas subredes de servidores de corta duración desde una caja de salto, y con frecuencia tenemos la reutilización de la dirección IP interna de los servidores que comparten la misma clave ssh.

Andy Hayden
fuente
Me funcionó en una máquina virtual vagabunda cuando la respuesta aceptada no funcionó.
100pic
1
Herramienta útil para tener en el cinturón, pero esto podría abrirlo para un ataque MitM (exactamente lo que known_hostsestá destinado a prevenir). Solo haga esto si está seguro de que todos los hosts están seguros.
Freedom_Ben
26

El problema es que previamente ha aceptado una conexión SSH a una computadora remota y la huella digital digital de esa computadora remota o la clave hash SHA256 ha cambiado desde la última vez que se conectó. Por lo tanto, cuando intente SSH nuevamente o use github para extraer el código, que también usa SSH, obtendrá un error. ¿Por qué? Porque está utilizando la misma dirección de computadora remota que antes pero la computadora remota responde con una huella digital diferente. Por lo tanto, es posible que alguien esté falsificando la computadora a la que se conectó anteriormente. Este es un problema de seguridad.

Si está 100% seguro de que la computadora remota no se ve comprometida, pirateada, falsificada, etc., entonces todo lo que necesita hacer es eliminar la entrada en su archivo conocido_hosts para la computadora remota. Eso resolverá el problema ya que ya no habrá una falta de coincidencia con las ID de huella digital SHA256 al conectarse.

En Mac esto es lo que hice:

1) Encuentre la línea de salida que lee RSA host key for servername:port has changed and you have requested strict checking.Necesitará tanto el nombre del servidor como el puerto potencial de esa salida de registro.

2) Haga una copia de seguridad del archivo de hosts conocidos de SSH cp /Users/yourmacusername/.ssh/known_hosts /Users/yourmacusername/.ssh/known_hosts.bak

3) Busque la línea donde está almacenada la huella digital anterior de la computadora y elimínela. Puede buscar la huella digital de la computadora remota infractora específica utilizando el nombre del servidor y el puerto del paso 1.nano /Users/yourmacusername/.ssh/known_hosts

4) CTRL-X para salir y elegir Y para guardar los cambios

Ahora escriba ssh -p port servernamey recibirá el mensaje original que recibió cuando intentó enviar SSH a esa computadora. Luego se le dará la opción de guardar la huella digital SHA256 actualizada de esa computadora remota en su archivo conocido_hosts. Si está utilizando SSH sobre el puerto 22, entonces el argumento -p no es necesario.

Cualquier problema que pueda restaurar el archivo conocido de host_hosts original: cp /Users/yourmacusername/.ssh/known_hosts.bak /Users/yourmacusername/.ssh/known_hosts

anon58192932
fuente
3
Eso debe marcarse como respuesta aceptada. Seguir esos pasos solucionó mi problema mientras ssh-keygen -R [IP_ADDRESS]no funcionaba para mí. ¡Gracias!
Yusuf Kamil AK
Sí, uno de esos casos que no es justo, la mejor respuesta es segura. Las respuestas segunda y tercera simplemente repiten lo que dijo la primera, y todas tienen una solución incompleta.
brasofilo
16

Como muchos ya han dicho, use ssh-keygen, es decir

ssh-keygen -R pong

Además, puede considerar desactivar temporalmente la comprobación de la clave del host:

ssh -oStrictHostKeyChecking=no root@pong
Stephen Quan
fuente
lo que estoy usando para el .ssh / config : Host ???? CheckHostIP no StrictHostKeyChecking no(3 líneas, tabuladas a partir del 2)
XXL
15

¡Funciona para mi!

Error: Ofrecer clave RSA en / var / lib / sss / pubconf / known_hosts: 4

Esto indica que tiene una clave RSA infractora en la línea no. 4 4

Solución 1 :

1) vi /var/lib/sss/pubconf/known_hosts

2 remove line no: 4 ..

3 Save and Exit, and Retry ..

Solución 2:

ssh-keygen -R "you server hostname or ip"

O

Solución 3:

sed -i '4d' /root/.ssh/known_hosts

Esto eliminará la 4thlínea de /root/.ssh/known_hostsin place ( -i).

Sahil Gulati
fuente
1
Esto funciona para el archivo raíz .ssh known_hosts. No para / var / lib / sss / pubconf / known_hosts, que es un archivo administrado por SSSD y poblado por un servidor remoto.
Mercury00
1
en mi caso, por alguna razón, el problema ocurrió en conocido_hosts * 2 *. Seguir estos pasos me ayudó a descubrirlo, ¡gracias @Sahil Gulati!
Lucas
11

Usé la solución de mockinterface, aunque el sed -i no funcionó del todo, lo resolví eliminando la línea a mano con vim:

sudo vim /var/lib/sss/pubconf/known_hosts

Puede usar cualquier otro editor de texto que desee, pero probablemente tendrá que mostrar sus privilegios administrativos

3nrique0
fuente
1
Sí, eliminar el registro de la misma IP en el archivo known_hosts resolverá el problema.
wherby
La entrada es recreada instantáneamente por SSSD cuando intenta ssh nuevamente. tenga en cuenta que sss pubconf known_hosts es un archivo administrado, no un repositorio local poblado por el servidor local.
Mercury00
9

Para usuarios de Mac, puede usar la -Rbandera del ssh-keygencomando. Ejemplo rápido:

ssh-keygen -R THE_IP_ADDRESS

THE_IP_ADDRESSsiendo la IP en la que estás intentando ingresar. Y luego puedes conectarte bien.

Nick Rameau
fuente
8

Esto se debe a que la configuración de su computadora remota ha cambiado. Elimina tus claves actuales para eso.

vim /root/.ssh/known_hosts

Elimine la línea de la IP que está conectando.

miota85
fuente
7

Edite /home/hostname /.ssh/known_hostsy elimine las 4 líneas y guárdelo.

Luego ejecute ssh root@pongnuevamente, verá un mensaje como este: Are you sure you want to continue connecting (yes/no)? yessimplemente imprima yes.

Nota: Si tiene algún problema, lea primero las sugerencias, lo ayudará.

Bruce
fuente
La mejor respuesta que realmente explica lo que está sucediendo.
Prometeo
6

Las otras respuestas aquí son buenas y funcionan, de todos modos, resolví el problema eliminando ~/.ssh/known_hosts. Esto ciertamente resuelve el problema, pero probablemente no sea el mejor enfoque.

tjespe
fuente
6

En mi caso, sucedió porque anteriormente tenía conexión ssh con una máquina con la misma ip (por ejemplo, 192.152.51.10) y el sistema estaba considerando la clave RSA (almacenada en /home/user_name/.ssh/known_hosts) del host anterior que resultó en desajuste

Para resolver este problema, debe eliminar la clave RSA previamente almacenada para la ip 192.152.51.10 .

ssh-keygen -f "/home/user_name/.ssh/known_hosts" -R 192.152.51.10
Prateek Joshi
fuente
5

Solución simple de una línea, probada en mac:

sed '/212.156.48.110/d' ~/.ssh/known_hosts > ~/.ssh/known_hosts

Elimina solo la IP del host ssh de destino de los hosts conocidos.

donde 212.156.48.110 se reemplaza por la dirección IP del host de destino.

Causa : sucedió porque la IP de destino ya era conocida para una máquina diferente debido al reenvío de puertos. Eliminar la IP de destino antes de conectarse solucionará el problema.

Helton Malambane
fuente
4

Usa este comando:

truncate -s 0 /home/SYSTEM_NAME/.ssh/known_hosts
Muktesh Kumar
fuente
Agregue una explicación de lo que hace el comando y lo que no hace.
Daniel W.
66
¿Por qué querrías truncar el archivo? Pierde toda la información, incluso la información que ya ha verificado. Este es un mal método para actuar contra una única clave de host pública modificada.
Daniel W.
1
este es un truco total: D pero funciona: D
Benjamin
Sugerencia: Esto también elimina toda la otra información del host. Si está ejecutando scripts automatizados desde su máquina (como implementaciones), podrían romperse porque debe volver a confirmar manualmente todas las claves de host. Solo para dar una advertencia a otros usuarios que están ansiosos por usar la solución más fácil.
Mateng
3

Elimina esa entrada de known_hosts usando:

ssh-keygen -R *ip_address_or_hostname*

Esto eliminará la IP problemática o el nombre de host del archivo known_hosts e intentará conectarse nuevamente.

De las páginas del manual:

-R hostname
Elimina todas las claves que pertenecen al nombre de host de un archivo conocido_hosts. Esta opción es útil para eliminar hosts hash (consulte la opción -H más arriba).

Chaminda Bandara
fuente
3

Solo haz:

cd /home/user/.ssh/-> aquí userestará tu nombre de usuario, es decir, /home/jon/por ejemplo.

Entonces

gedit known_hosts & y elimine el contenido dentro de él.

Ahora de sshnuevo, debería funcionar.

El depredador
fuente
3

Si está intentando conectarse al contenedor de Docker en ejecución en el puerto 2222 con el comando y obtiene el error

mian@tdowrick2~$ ssh pos@localhost -p 2222

Luego, para resolver este problema, en su computadora local (es decir, la máquina host no el contenedor) vaya cd ~/.ssh/y abra el known_hostsarchivo con el editor de texto. Elimine la línea que comienza con [localhost]:2222y guarde el archivo. Ahora intenta ssh nuevamente

mian@tdowrick2~$ ssh pos@localhost -p 2222

El error desaparecerá, pero debe hacerlo cada vez que se reinicie el contenedor.

Mian Asbat Ahmad
fuente
2

Mi solución es:

  1. vi ~/.ssh/known_hosts
  2. elimine la línea que contiene su IP conectada deseada.

Esto es mejor que eliminar todos los known_hosts

aeronave
fuente
Esta es la misma respuesta que miota85 a continuación.
Daniel W.
2

Solo problema del lado del cliente (clave duplicada para ip):

Resolver variantes:

Para clear one ip (puerto predeterminado 22):

ssh-keygen -f -R 7.7.7.7

Para una ip ( puerto no predeterminado ):

ssh-keygen -f -R 7.7.7.7:333

Borre rápidamente todos los ips:

cd ~; rm .ssh/known_hosts

7.7.7.7 - ssh su servidor ip connect

333 - puerto no estándar

Fortran
fuente
2

A veces, si por alguna razón, necesita reinstalar un servidor, cuando se conecte por ssh descubriremos que su servidor dice que la identificación ha cambiado. Si sabemos que no se trata de un ataque , pero que hemos restablecido el sistema, podemos eliminar la identificación anterior de conocido_hosts usando ssh-keygen:

ssh-keygen -R <host/ip:hostname>
root/.ssh/known_hosts updated.
Original contents retained as /root/.ssh/known_hosts.old

Al volver a conectarse, le pediremos que valide la nueva huella digital:

ssh -l user <host/ip:hostname>
The authenticity of host '<host/ip:hostname>' can't 
be established.
RSA key fingerprint is 3f:3d:a0:bb:59:24:35:6d:e5:a0:1a:3f:9c:86:81:90.
Are you sure you want to continue connecting (yes/no)? yes
BrennQuin
fuente
1

Tuve este problema, y ​​la razón es muy simple, tengo una dirección IP duplicada para iniciar sesión en ssh, por lo que después de modificar este problema, todo está resuelto.

Ventilador
fuente
1

Tuve el mismo error en mi máquina y borré el known_hostsarchivo, y después de eso, funciona bien.

GoingMyWay
fuente
1
No desea eliminar su authorized_keyscuando tiene un problema con el known_hostsarchivo
jeb
0

SOLUCIÓN:

1- eliminar de "$ HOME / .ssh / known_hosts" la línea que se refiere al host con la cual es imposible conectarse.

2- ejecute este comando: ssh-keygen -R "IP_ADDRESSorHOSTNAME" (sustituya "IP_ADDRESSorHOSTNAME" con su IP de destino o nombre de host de destino)

3- Vuelva a intentar la conexión ssh (si falla, verifique el permiso en el directorio .ssh, debe ser 700)

Cielos oscuros
fuente
0

Mi solución en UBUNTU (linux):

1.Debe eliminar el contenido del archivo "known_hosts" que se encuentra en "/home/YOUR_USERNAME/.ssh/known_hosts"

2.Genere una nueva clave ssh como "ssh-keygen -t rsa -C" [email protected] "-b 4096"

3.Copie y pegue su nueva clave ssh en su repositorio git (gitlab en mi caso) claves SSH.

Esto funciona para mi !

Dionis Oros
fuente
-1

AWS EC2.

Encuentra la ip en el mensaje que te da.

correr

vim /home/ec2-user/.ssh/known_hosts

Use las teclas de flecha para encontrar la ip del mensaje y haga clic.

dd

Esto eliminará esa línea y luego ejecutará escape

:wp

Esto te ahorrará, entonces estás listo para comenzar.

usuario1503606
fuente