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

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 ...

"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? ).

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.

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.

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

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

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.

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.

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.

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.

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

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)? Sí ". Debe ingresar sí, no ingresar.

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>

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

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.

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.

chmod 666 /dev/tty 

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