Problema de conexión SSH con el error "Error de verificación de clave de host ..."


179

Puedo conectarme a otra máquina Ubuntu en mi LAN a través de SSH. En ambas PC instalé el servidor openssh pero desde otra computadora Ubuntu no puedo conectarme a mi PC a través de SSH y recibí este error:

La verificación de la clave del host ha fallado ...


1
¿Utiliza dólares nombres de host o direcciones IP?
Thorbjørn Ravn Andersen

No es similar pero recibí el mismo error pero debido a un problema diferente: serverfault.com/questions/494916/…
zengr

Este no es un problema específico de Ubuntu. Puede suceder con cualquiera sshde la línea de comandos.
MarkHu

Respuestas:


216

"Anfitrión verificación de clave no se ha" significa que el anfitrión clave del host remoto se ha cambiado.

SSH almacena las claves de host de los hosts remotos en ~/.ssh/known_hosts. Puede editar ese archivo de texto manualmente y eliminar la clave anterior (puede ver el número de línea en el mensaje de error), o usar

ssh-keygen -R hostname

Desde la página 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.

(que aprendí de la respuesta a ¿Es posible eliminar una clave de host particular del archivo conocido_hosts de SSH? ).


44
También puede significar que simplemente no tiene la clave de host del host remoto. Por ejemplo, si yo rm ~/.ssh/*, entonces ssh -o BatchMode=yes root@somewhere, si nada más está mal, obtendré Host key verification failed. No importante si siempre eres interactivo, pero relevante para los scripts que encuentran el mismo error.
Ron Burk el

Como era de esperar, los ssh-keygen -R example.net:7999rendimientos Host example.net:7999 not found in known_hosts.
alex

Eliminé el known_hostsarchivo y ssh nuevamente. Funcionó.
ParisaN

el archivo ~/.ssh/known_hostses ilegible
João Pimentel Ferreira

128

Si está ejecutando ciertas situaciones remotas / de secuencias de comandos en las que carece de acceso interactivo a la solicitud de agregar hostkey, evite esto de la siguiente manera:

$ ssh -o StrictHostKeyChecking=no user@something.example.com uptime

Advertencia: se agregó permanentemente 'something.example.com, 10.11.12.13' (RSA) a la lista de hosts conocidos.


66
+1, esta es una solución fea, pero en algunos casos de procesos de monitoreo automatizados que funcionan con dispositivos dymaic conectados a IP, esta es una solución simple y aceptable.
Ninsuo

11
+1 Por ejemplo, para las ejecuciones de Jenkins, esta es una buena solución. Gracias
Lobo

55
@Lobo no puede estar más de acuerdo, lo estoy usando para Jenkins, lo cual es genialsh """ssh -o StrictHostKeyChecking=No ec2-user@someIpAddress-e2e sudo service tomcat restart"""
prayagupd

Salvó mi vida. Solución salvavidas.
user1735921

10

Además, a veces hay una situación en la que está trabajando en la consola en serie, luego, al verificar el comando anterior en modo detallado, -vse mostrará que /dev/ttyno existe, mientras que sí existe.

ssh -v user@hostname

En el caso anterior, simplemente elimine /dev/ttyy cree un enlace simbólico de /dev/ttyS0to /dev/tty.

rm /dev/tty
ln -s /dev/ttyS0 /dev/tty

Como alternativa, agregue id_rsa.puba la ubicación remota, de modo que no se solicite la contraseña y obtenga acceso de inicio de sesión.


66
+1 para recomendar el uso del parámetro -v; Esto puede ayudar mucho al depurar problemas ssh.
daniel kullmann

8

En mi caso, esto fue causado por un problema de udev: no había ningún /dev/ttynodo de dispositivo. La solución para mí fue solo:

sudo mknod -m 666 /dev/tty c 5 0

6

En terminal:

ssh -o StrictHostKeyChecking=no -i YourPublicKey.pem user@example.com uptime

Aparecerá el siguiente mensaje, o similar:

Warning: Permanently added 'example.com, XX.XXX.XXX.XX' (ECDSA) to the list of known hosts.
 00:47:37 up 3 min,  0 users,  load average: 0.00, 0.00, 0.00

Luego, conéctese a su EC2 normalmente:

ssh -i YourPublickey.pem user@example.com

Obtuve command-line line 0: Bad yes/no/ask argument.porque usas erróneamente 'No' en lugar de 'no' como argumento paraStrictHostKeyChecking
Axel Bregnsbo

3

Bueno, simplemente porque el segundo ubuntu requiere conexión por clave y no por contraseña.

Le sugiero que use sudo dpkg-reconfigure openssh-serveren su PC, y luego debería funcionar correctamente. Se restablecerá la configuración de openssh y debería volver a una autenticación de contraseña predeterminada.

La segunda posibilidad es que ya hay una clave para su otro ubuntu en su PC, y que cambió, por lo que ya no se reconoce. En este caso, tendrá que editar el archivo .ssh/authorized_keyspara eliminar la línea problemática que identifica su ubuntu.


3

Este es un hilo viejo y acabo de encontrar esta respuesta, solo agregaré lo que hice para resolver esto.

ssh-keygen -f "/home/USER/.ssh/known_hosts" -R HOSTNAME

Acabo de mirar el mensaje de error que me arrojó y decía que ejecutara ese comando para eliminarlo de la lista de hosts. Después de eso hice lo siguiente:

ssh-copy-id HOSTNAME

Luego seguí las indicaciones desde allí hasta que pude ingresar al servidor.


Como este comando, recibo una sugerencia en ubuntu 12.4.
MANKuR

2

Significa que se modificó su clave de host remoto (puede ser un cambio de contraseña de host),

Su terminal sugirió ejecutar este comando como usuario root

$ ssh-keygen -f "/root/.ssh/known_hosts" -R [www.website.net]:4231

Debe eliminar ese nombre de host de la lista de hosts en su PC / servidor. Copie el comando sugerido y ejecútelo como usuario root.

$ sudo su                                                            // Login as a root user

$ ssh-keygen -f "/root/.ssh/known_hosts" -R [www.website.net]:4231   // Terminal suggested command execute here
Host [www.website.net]:4231 found: line 16 type ECDSA
/root/.ssh/known_hosts updated.
Original contents retained as /root/.ssh/known_hosts.old

$ exit                                                               // Exist from root user

$ sudo ssh root@www.website.net -p 4231                              // Try again

Espero que esto funcione.


1

Debe cambiar su clave de esta manera: a partir de su error determinado, encuentre qué clave de host cambió, por ejemplo: la clave ECDSA ofensiva en /Users/user-name/.ssh/known_hosts:5 dijo que la quinta clave cambió, así que haga esto:

sed -i '5d' ~/.ssh/known_hosts

Aviso: debe ser root o tener privilegios para sudo.


No, a menos que lo esté haciendo por otra persona, no requiere root ni sudo. Está editando el archivo en su directorio de inicio. Segundo: para que el comando funcione requiere GNU sed.
Techraf

Tal vez tengas razón, pero intenté pasar de Mac OSX a ubuntu-server y tengo que hacerlo. por cierto gracias por tu comentario.
Amir.AG

1

debe poner la clave rsa del host de destino en el host de origen /home/user/.ssh/known_hostsejecutándola en el destino

ssh-keyscan -t rsa @targethost

1

Es posible que solo necesite ingresar "yes" cuando ssh confirme que desea continuar conectándose.

Como abajo.

The authenticity of host 'xxx' can't be established.
ECDSA key fingerprint is yyy.
Are you sure you want to continue connecting (yes/no)? yes
Warning: Permanently added 'xxx' (ECDSA) to the list of known hosts.
Enter passphrase for key '/Users/ysy/.ssh/id_rsa':

Luego ingrese su contraseña.

Por favor, preste atención a "¿Está seguro de que desea continuar conectándose (sí / no)? ". Debe ingresar sí, no ingresar.


1

Además de desactivar estrictamente la comprobación de la clave de host, también puede conectarse escribiendo:

ssh -o LogLevel=quiet -o UserKnownHostsFile=/dev/null -o StrictHostKeyChecking=no <username@target_machine_ip_or_domain_name>

0

pico ~/.ssh/known_hosts y elimine todas las líneas, después de reconectarse y obtendrá una nueva clave.


66
Esta es una solución peligrosa, porque eliminará TODAS sus claves de host. La solución aceptada, ssh-keygen -R hostnamees mejor.
msanford

0

Mi solución proviene de esta publicación de blog: Error en la negociación del algoritmo para SSH Secure Shell Client

Necesita modificar el archivo de la siguiente manera:

sudo nano /etc/ssh/sshd_config

Y luego agregue lo siguiente:

# Ciphers
Ciphers aes128-cbc,aes192-cbc,aes256-cbc,blowfish-cbc,arcfour
KexAlgorithms diffie-hellman-group1-sha1

Básicamente, probó diferentes soluciones hasta que encuentre una que pueda resolver su problema. Si las soluciones anteriores no funcionan, intente con esta. Si este no funciona tan bien, intente con otros.


0

Simplemente haga "sudo vi /var/root/.ssh/known_hosts" y elimine la línea, que contiene una clave para un host al que está intentando conectarse y volver a conectarse.

No sé acerca de su situación particular, pero lo más probable es que este error haya aparecido con un mensaje como este:

my_mac:~ oivanche$ sudo ssh pi@192.168.0.45
@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@
@    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 ECDSA key sent by the remote host is
SHA256:sx1Z4xyGY9venBP6dIHAoBj0VhDOo7TUVCE2xWXpzQk.
Please contact your system administrator.
Add correct host key in /var/root/.ssh/known_hosts to get rid of this message.
Offending ECDSA key in /var/root/.ssh/known_hosts:74
ECDSA host key for 192.168.0.45 has changed and you have requested strict checking.
Host key verification failed.

Si lee el registro con más cuidado, verá que la clave que obtiene de un host está en conflicto con una clave que ya tiene; en este caso, está en la línea 74 del archivo known_hosts (clave ECDSA ofensiva en / var / root / .ssh / known_hosts: 74). Elimine la línea de conocido_hosts, guarde los cambios y vuelva a conectar.


-1
chmod 666 /dev/tty 

es otra solución tty: a veces, este archivo de dispositivo tiene permisos incorrectos.

Al usar nuestro sitio, usted reconoce que ha leído y comprende nuestra Política de Cookies y Política de Privacidad.
Licensed under cc by-sa 3.0 with attribution required.