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


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

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

¿Qué está causando esto y cómo lo soluciono? Intenté eliminar el .ssh directorio en la máquina remota, y ejecutándose ssh-keygen -R "myserver" localmente, pero esto no resuelve el error.


210


origen


en mi caso, cambio el enlace del servidor (ip) con el dominio, luego el The ECDSA host key for server has changed. Mi manera es eliminar la cadena de caché relacionada sobre el dominio en ~/.ssh/known_hosts. Entonces el ssh funciona. - Ninja


Respuestas:


Retire la clave en caché para 192.168.1.123 en la máquina local:

ssh-keygen -R 192.168.1.123

300



No funcionó para mí en el servidor Debian recién instalado en el trabajo cuando SSHing desde casa. Además, la respuesta es bastante escueta. - Chris K
/home/wf/.ssh/known_hosts actualizado. Contenido original retenido como /home/wf/.ssh/known_hosts.old "Advertencia: Se agregó permanentemente la clave de host ECDSA para la dirección IP 'x.x.x.x' a la lista de hosts conocidos." se visualiza. y luego parece funcionar - Wolfgang Fahl
Puede actualizar la clave en lugar de eliminarla. Utilizar ssh-keyscan -t ecdsa my.server.domain >> ~/.ssh/known_hosts después de eso, no es necesario que verifique una nueva clave al primero conectarse al host. - Alex
Para quienes no logran que funcione: He tenido múltiples apariciones registradas de la misma IP: 1 / dicha dirección IP (xx.xx.xx.xx), dominio (tomsihap.fr), servidor vps proporcionado por el proveedor dirección (vpsxxx.ovh.net). ssh-keygen -R para cada uno de estos hizo el trabajo. - tomsihap
Funcionó para mí, pero la confusión podría ser desde qué host se debería ejecutar este comando? La respuesta es de la que exhibió el error. La segunda pregunta y respuesta son más obvias, pero por las dudas: ¿qué dirección pasar a ssh-keygen -R? La dirección que figura en la declaración de error. - Russ Bateman


En mi caso ssh-keygen -R ... no corrigió la advertencia. Tenía información adicional 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 ofensiva"). Intenté reconectarme, el host se agregó de forma permanente, ¡y todo estuvo bien después de eso!


40



Esto funcionó para mí. ¡Gracias! - Organic Marble
Funciona de maravilla. Puede arreglar esto en una línea con sed -e '8d' /home/myuser/.ssh/known_hosts, reemplazando el número de línea 8 y el nombre del archivo con los que se muestran en su sistema. - Alex P. Miller


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

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

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

Cuando todos los sistemas operativos eran Ubuntu y volví a instalar el sistema operativo de un servidor, en el primer SSH que recibí recibí este tipo de advertencia, que prefiero sobre la advertencia silenciosa anterior.

@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@
@    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 me abro ~ / .ssh / known_hosts en la computadora que inicia el ssh, elimine esa línea, reconecte y esto sucede:

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

Ese bit sobre: ​​11122 es el número de puerto I ruta SSH desde el firewall

Comprobé las copias de seguridad de un antiguo servidor de 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

Entonces, sí, es probable que el host haya comenzado 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 conté es por qué instalé a Debian esta vez.

yo leo un security.SE q / a en ecdsa y ya han eliminado esa línea de sshd_config mi nuevo servidor Debian (y corrió service ssh restart)


14



+1 para el bonito bloque de comparación de lado a lado. ¿Podría agregar una URL que aclare "el cambio de Ubuntu lejos del sistema operativo Linux sólido como una roca" significa? - bgoodr
@bgoodr es mi opinión y únicamente se basa en la configuración de mi propio servidor de archivos RAID varias veces en los últimos años. : / Mierda por respuesta, pero comienza a googlear ubuntu debian server y verás lo que quiero decir - Chris K
@ChrisK Usted, señor, es un jefe. Gracias por la respuesta detallada, pero concisa. - sargas


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

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


5





La solicitud se produce cada vez porque las direcciones IP cambian todo el tiempo cuando se utiliza el direccionamiento dinámico. Intente usar IP estática, por lo que solo debe agregar la clave una sola vez.


4



Buen punto, ¿extrañé que alguien mencionara ips dinámicos? - Chris K


¿Estás usando el mismo usuario para conectarte?

Si has iniciado sesión en una PC local como usuario John y conectado al servidor segundo como usuario Adolf @ B y todo está bien, eso no significa que todo esté bien si estás conectado a la PC local como usuario Jane y conectando al servidor segundo como usuario Adolf @ B.

Si desea iniciar sesión en el servidor B como usuario Beda de PC UN sin contraseña, prueba este comando, todo de PC UN:

ssh-keygen -t rsa

Este comando genera la clave y almacena la clave en el archivo. Por favor, vete frase de contraseña vacío.

ssh Beda@B mkdir -p .ssh

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

cd ~/.ssh

Este comando cambia el directorio al directorio de inicio 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





La amenaza aquí puede ayudar.

Básicamente, desea eliminar las claves RSA y ECDSA para ese host, luego use ssh-keyscan para ponerlos de nuevo en su known_hosts archivo de una manera que no cause este conflicto. Me funcionó cuando tuve el mismo problema.


1





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

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

  • ¿Sshd en myserver comenzó a usar claves ECDSA, entonces es un nuevo tipo de clave?
  • ¿Se volvió a instalar myserver recientemente?
  • ¿Se volvió a insallar sshd en myserver 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 de myserver para que un host diferente responda a esa dirección IP?

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

Como otros ya han respondido, elimine la clave del host ECDSA en caché para myserver que su cuenta ha almacenado en caché.


1



Buen consejo, pero en realidad no responde la pregunta. Ni siquiera INTENTA responder la pregunta. - boatcoder


Este error me mantuvo molesto por mucho tiempo. Por alguna razón, hizo una diferencia si yo haría una

ssh host

o

ssh host.domain

https://askubuntu.com/questions/87449/how-to-disable-strict-host-key-checking-in-ssh

luego me indicó la opción de cambiar el archivo de configuración. Ver mi script https://askubuntu.com/a/949731/129227 allí para automatizar el proceso.


1





Lo solucioné en un Chromebook desinstalando y reinstalando Secure Shell ... Funcionó a las mil maravillas.


0



Esto es excesivo. Vea una solución más simple en mi respuesta aquí. - Alex Yursha