2012-05-05 19:05:56 +0000 2012-05-05 19:05:56 +0000
315

Cómo corregir la advertencia sobre la clave de host de la ECDSA

Estoy tratando de configurar SSH sin contraseña en un servidor Ubuntu con ssh-copy-id myuser@myserver, pero recibo el error:

Advertencia: la clave de host de la ECDSA para 'myserver' difiere de la clave para la dirección IP '192.168.1.123'

¿Qué está causando esto, y cómo lo corrijo? Intenté borrar el directorio .ssh de la máquina remota y ejecutar ssh-keygen -R "myserver" localmente, pero esto no resuelve el error.

Respuestas [13]

459
2012-05-05 20:20:21 +0000

Quita la llave de caché para 192.168.1.123 en la máquina local:

ssh-keygen -R 192.168.1.123
459
69
2014-03-11 18:52:18 +0000

En mi caso ssh-keygen -R ... no arregló la advertencia. Tenía información extra como esta:

Offending key for IP in /home/myuser/.ssh/known_hosts:8
Matching host key in /home/myuser/.ssh/known_hosts:24

Simplemente edité manualmente ~/.ssh/known_hosts y borré la línea 8 (la "clave de la ofensa"). Intenté reconectarme, el host fue añadido permanentemente, y todo estuvo bien después de eso!

69
19
2014-01-16 08:12:11 +0000

Hago mucho ssh-ing entre mis computadoras LAN y mis dos cuentas de webhosting, así que he resuelto todo tipo de problemas con SSH, incluyendo problemas de autenticación usando ssh -v para ver dónde y qué salió mal.

Habiendo resuelto este problema y no estando contento con las respuestas, quería saber realmente "por qué" yo mismo...

El desencadenante de mi caso es: instalé el nuevo sistema operativo del servidor en el trabajo y al instalar el paquete openssh-server, se generó un nuevo conjunto de claves de host en el servidor del trabajo. Anteriormente, todos mis sistemas operativos de servidor eran Ubuntu y esta vez cambió a Debian (y sospecho que hay una diferencia de matices en los permisos).

Cuando todos los sistemas operativos eran Ubuntu y reinstalo el sistema operativo de un servidor, al primer SSH que entra, recibo este tipo de advertencia, que prefiero a la advertencia silenciosa de arriba!

@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@
@ 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 the RSA host key has just been changed.
The fingerprint for the RSA key sent by the remote host is
06:ea:f1:f8:db:75:5c:0c:af:15:d7:99:2d:ef:08:2a.
Please contact your system administrator.
Add correct host key in /home/user/.ssh/known_hosts to get rid of this message.
Offending key in /home/user/.ssh/known_hosts:4
RSA host key for domain.com has changed and you have requested strict checking.
Host key verification failed.

Entonces abro ~/. ssh/known_hosts en la computadora iniciando el ssh, borro esa línea, reconecto y sucede esto:

chris@home ~ $ ssh work
The authenticity of host '[work]:11122 ([99.85.243.208]:11122)' can't be established.
ECDSA key fingerprint is 56:6d:13:be:fe:a0:29:ca:53:da:23:d6:1d:36:dd:c5.
Are you sure you want to continue connecting (yes/no)? yes
Warning: Permanently added '[work]:11122 ([99.85.243.208]:11122)' (ECDSA) to the list of known hosts.
Linux rock 3.2.0-4-amd64 #1 SMP Debian 3.2.51-1 x86_64

Esa parte de :11122 es el número de puerto desde el cual enrutamiento SSH en el firewall

Revisé las copias de seguridad de un antiguo servidor Ubuntu y las comparé con mi nueva instalación de Debian:

Ubuntu: Debian:
# Package generated configuration file # Package generated configuration file
# See the sshd(8) manpage for details # See the sshd_config(5) manpage for details

# What ports, IPs and protocols we listen for # What ports, IPs and protocols we listen for
Port 22 Port 22
# Use these options to restrict which interface # Use these options to restrict which interfaces
#ListenAddress :: #ListenAddress ::
#ListenAddress 0.0.0.0 #ListenAddress 0.0.0.0
Protocol 2 Protocol 2
# HostKeys for protocol version 2 # HostKeys for protocol version 2
HostKey /etc/ssh/ssh_host_rsa_key HostKey /etc/ssh/ssh_host_rsa_key
HostKey /etc/ssh/ssh_host_dsa_key HostKey /etc/ssh/ssh_host_dsa_key
------------------------------------------------ HostKey /etc/ssh/ssh_host_ecdsa_key
#Privilege Separation is turned on for security #Privilege Separation is turned on for security
UsePrivilegeSeparation yes UsePrivilegeSeparation yes

Así que sí, es probable que el servidor haya empezado a usar claves ecdsa recientemente, lo que basado en los cambios de Ubuntu últimamente, culparía a una actualización. El alejamiento de Ubuntu del sólido sistema operativo Linux con el que contaba es la razón por la que instalé Debian esta vez.

Leí un security.SE q/a on ecdsa y ya he eliminado esa línea de sshd_config mi nuevo servidor Debian. (y ejecuté service ssh restart)

19
7
2014-01-16 09:06:57 +0000

El aviso se produce cada vez porque las direcciones IP cambian todo el tiempo cuando se utiliza el direccionamiento dinámico. Intenta usar una IP estática para que sólo tengas que añadir la clave una vez.

7
6
2015-05-14 18:16:42 +0000

ssh-keygen -f "/root/.ssh/known_hosts" -R 192.168.1.123

Esto debería reemplazar las claves existentes bajo known_hosts.old y crear una nueva. Esta solución funcionó para mí en el mismo escenario

6
4
2018-03-15 12:23:28 +0000

Añadí las siguientes líneas a mi ~/.ssh/config, desactivando así la estricta comprobación del host para todas las direcciones .locales. (con la asignación de direcciones DHCP, las direcciones ip de mis máquinas locales siempre están cambiando)

host *.local
    StrictHostKeyChecking no

Sin embargo, aún recibes la advertencia, lo cual está bien para mí.

4
2
2014-10-21 09:17:22 +0000

¿Usas el mismo usuario para conectarte?

Si estás conectado a un PC local como el usuario John y conectado al servidor B como el usuario Adolf@B y todo está bien, no significa que todo esté bien si estás conectado a un PC local como el usuario Jane y conectado al servidor B como el usuario Adolf@B.

Si quieres conectarte al servidor B como usuario Beda desde la PC A sin contraseña, prueba este comando, todo desde la PC A:

ssh-keygen -t rsa

Este comando genera la clave y la almacena en el archivo. Por favor, deje frase de paso vacía.

ssh Beda@B mkdir -p .ssh

Este comando crea el directorio, si no existe ya. De lo contrario, no imprima un mensaje de error.

cd ~/.ssh

Este comando cambia el directorio al directorio principal de los usuarios ./ssh.

cat id_rsa.pub | ssh Beda@B 'cat >> .ssh/authorized_keys'

Este comando imprime el archivo id_rsa. pub (su clave pública) en authorized_keys en el servidor.

IMPORTANTE: Beda es su nombre de usuario en el servidor al que se está conectando, B es su IP de servidor.

Ahora, puede conectarse al servidor B sin una contraseña o frase de contraseña:

ssh Beda@B
2
1
2012-08-07 15:42:41 +0000

Pregunta: ¿Qué está causando esto, ...?

  • ¿La clave de host del servidor ssh cambió.  ¿Qué causó el cambio?  Es difícil de decir.  Aquí hay algunas suposiciones:

  • ¿Sshd en el myserver comenzó a usar claves ECDSA, por lo que es un nuevo tipo de clave?

  • ¿Se reinstaló recientemente el myserver?

  • ¿Sshd en el myserver se reinstaló recientemente por lo que se generó una nueva clave de host ssh?

  • ¿Alguien re-generó o reemplazó la clave de host sshd?

  • ¿Ha cambiado la dirección IP del myserver de manera que un host diferente está respondiendo a esa dirección IP?

Pregunta: ... y cómo lo arreglo?

Como otros ya han respondido, elimina la clave de host ECDSA cacheada para el myserver que tu cuenta ha cacheado.

1
1
2012-12-20 16:47:41 +0000

El hilo aquí puede ayudar.

Esencialmente, quieres quitar las claves RSA y ECDSA de ese host, y luego usar ssh-keyscan para volver a ponerlas en tu archivo known_hosts de manera que no cause este conflicto. A mí me funcionó cuando tuve el mismo problema.

1
0
2015-05-18 23:26:58 +0000

Arreglé esto en un Chromebook desinstalando y reinstalando Secure Shell... Funcionó como un encanto.

0
0
2020-02-23 01:54:19 +0000

A mi lado esto sucede debido a algo que considero un error ssh de los clientes más nuevos (OpenSSH_7.9p1 y superiores), cuando trata de aprender una clave de servidor ecdsa más segura donde ya hay una clave de tipo rsa más antigua conocida. Entonces presenta este mensaje engañoso!

No conozco una buena solución para esto, la única solución que encontré es eliminar todas las "buenas pero viejas claves rsa" para que el cliente pueda volver a aprender las "nuevas claves ecdsa más seguras". Así que:

  1. El primer paso es eliminar todas las viejas y buenas claves RSA ( Advertencia! Esto pierde la protección contra el MitM ):

    1. El segundo paso entonces es reaprender todas las claves del host, lo cual debe hacerse manualmente conectándose a cada IP de nuevo usando ssh.

Esto es lo que observo:

$ sftp test@136.243.197.100
Connected to test@136.243.197.100
sftp> 

$ sftp test@valentin.hilbig.de
Connected to test@valentin.hilbig.de.
sftp>

Ahora intenta conectarte a un nuevo alias de este mismo buen servidor ya conocido:

$ sftp test@gcopy.net
Warning: the ECDSA host key for 'gcopy.net' differs from the key for the IP address '136.243.197.100'
Offending key for IP in /home/test/.ssh/known_hosts:45
Matching host key in /home/test/.ssh/known_hosts:44
Are you sure you want to continue connecting (yes/no)?

Por favor, echa un vistazo a la dirección IP. Es la misma IP que arriba! Así que parece que la (buena) clave de la (conocida) IP de repente se está ofendiendo a sí misma (no es así, ya que el cliente ssh mezcla dos claves incompatibles, véase más abajo).

Ahora intentamos arreglarlo:

$ ssh-keygen -R 136.243.197.100
# Host 136.243.197.100 found: line 45
/home/test/.ssh/known_hosts updated.
Original contents retained as /home/test/.ssh/known_hosts.old

Intentémoslo de nuevo:

$ sftp test@gcopy.net
Warning: Permanently added the ECDSA host key for IP address '136.243.197.100' to the list of known hosts.
Connected to test@gcopy.net.

$ sftp test@valentin.hilbig.de
Warning: the RSA host key for 'valentin.hilbig.de' differs from the key for the IP address '136.243.197.100'
Offending key for IP in /home/test/.ssh/known_hosts:45
Matching host key in /home/test/.ssh/known_hosts:10
Are you sure you want to continue connecting (yes/no)?

WTF? ¿Qué ha pasado aquí? ¿La nueva clave fresca aprendida del servidor vuelve a fallar? ¿Y el problema incluso cambió de lado? No, no es la llave, ni el servidor. ¡Todo está correcto!

¡Es el cliente ssh que falla al verificar la clave correcta! La entrada 45 en known_hosts ahora lleva una clave de tipo ecdsa-sha2-nistp256 mientras que la clave, que fue sacada del servidor por el cliente, es de tipo rsa-sha2-512 (¡y por lo tanto no puede coincidir con la otra clave!).

$ sftp -v test@valentin.hilbig.de

muestra:

debug1: kex: host key algorithm: rsa-sha2-512

mientras que

$ sftp -v test@gcopy.net

muestra:

debug1: kex: host key algorithm: ecdsa-sha2-nistp256

¡Aparentemente el cliente ssh tiene un error en algún lugar! ¡No puede hacer frente a una clave de host existente en más de una variante! O cae en la trampa de solicitar una variante anticuada de una clave.

¿Cómo arreglarlo?

Realmente no tengo ni idea. Esto probablemente sólo puede ser arreglado aguas arriba.

Pero hay una solución manual pero torpe:

Tienes que eliminar manualmente todos los rastros de la vieja llave de tipo rsa. La clave en cuestión se muestra en la salida, pero no se marca directamente como el problema:

Warning: the RSA host key for 'valentin.hilbig.de' differs from the key for the IP address '136.243.197.100'
Offending key for IP in /home/test/.ssh/known_hosts:45
Matching host key in /home/test/.ssh/known_hosts:10

comprueba:

awk 'NR==45 { print $2 }' /home/test/.ssh/known_hosts
awk 'NR==10 { print $2 }' /home/test/.ssh/known_hosts

da

ecdsa-sha2-nistp256
ssh-rsa

¡Así que aquí la clave de host parejada es la que ofende y la clave ofensiva es la correcta que debe ser guardada! Así que vamos a eliminar la incorrecta (coincidencia):

ssh-keygen -R valentin.hilbig.de
# Host valentin.hilbig.de found: line 10
/home/test/.ssh/known_hosts updated.
Original contents retained as /home/test/.ssh/known_hosts.old

Ahora comprueba de nuevo:

$ sftp test@valentin.hilbig.de
The authenticity of host 'valentin.hilbig.de (136.243.197.100)' can't be established.
ECDSA key fingerprint is SHA256:tf7lwe10C2p1lK2UG9p//m/4sUBCpX+i9k5Ub63c6Os.
Are you sure you want to continue connecting (yes/no)? yes
Warning: Permanently added 'valentin.hilbig.de' (ECDSA) to the list of known hosts.
Connected to test@valentin.hilbig.de.
sftp> 

$ sftp test@gcopy.net
Connected to test@gcopy.net.
sftp> 

sftp test@136.243.197.100
Connected to test@136.243.197.100.
sftp>

YAY! El problema finalmente se ha ido. Pero con varias 100 entradas en .ssh/known_hosts, esta "solución" realmente se convierte en un gran PITA (y una pesadilla de seguridad propensa a errores en Elm Street. YMMV.)

0
0
2017-07-24 07:55:39 +0000

A continuación se explica cómo eliminar una huella digital de host conocida (del archivo known_hosts) en un sistema operativo Chrome:

Encuentra el índice de la entrada del host infractor en la salida ssh cuando la conexión falla. Por ejemplo, en la línea que aparece debajo del índice del infractor es 7 :

Offending ECDSA key in /.ssh/known_hosts:7

Abra la consola JavaScript (CTRL+Shift+J) de la ventana de Secure Shell y escriba lo siguiente, reemplazando INDEX por el valor apropiado (por ejemplo, 7 ):

term_.command.removeKnownHostByIndex(INDEX);

Esta solución se tomó prestada de Blog de Leo Gaggl .

0