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 ECDSA para 'myserver' 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 .sshdirectorio en la máquina remota y ejecutarlo ssh-keygen -R "myserver"localmente, pero esto no resuelve el error.
Respuestas:
Retire la clave en caché para 192.168.1.123en la máquina local:
ssh-keygen -R 192.168.1.123
ssh-keyscan -t ecdsa my.server.domain >> ~/.ssh/known_hostsdespués de eso, no necesita verificar la nueva clave al conectarse al host.
En mi caso ssh-keygen -R ...no solucioné 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é ~/.ssh/known_hostsy eliminé manualmente la línea 8 (la "clave infractora"). Traté de volver a conectarme, el host se agregó permanentemente, ¡y todo estuvo bien después de eso!
sed -e '8d' /home/myuser/.ssh/known_hosts, reemplazando el número de línea 8y el nombre del archivo con los que se muestran en su sistema.
known_hosts:8refiere a un valor indexado a cero o no. Es bueno saber que es un mapeo 1: 1 ...
ssh-keygen -R [hostname]:2022
~/.ssh/known_hosts, recibo el mensaje de que no se puede establecer la autenticidad y "¿Está seguro de que desea continuar conectándose?". Responder "sí" intenta y no se conecta. Si intento conectarme por segunda vez, aparece el mismo error de clave de host ECDSA con el que comencé.
Hago muchos cambios entre mis computadoras LAN y mis dos cuentas de alojamiento web, por lo que he resuelto todo tipo de probabilidades y termina con SSH, incluidos los problemas de autenticación ssh -vpara ver dónde y qué salió mal.
Después de haber resuelto este problema y no estar contento con las respuestas, quería saber realmente "por qué" ...
El desencadenante de mi caso es: instalé un 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 los sistemas operativos de mi 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 reinstalo el sistema operativo de un servidor, en el primer SSH en él, recibo 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.
Luego abro ~/.ssh/known_hostsen la computadora iniciando el ssh, borro esa línea, vuelvo a conectar 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
De eso se trata: 11122 es el número de puerto desde el que enruto SSH en el firewall
Verifiqué las copias de seguridad de un antiguo servidor Ubuntu y 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í, probablemente, el host comenzó 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 en ecdsa y ya he eliminado esa línea de sshd_configmi nuevo servidor Debian. (y corrió service ssh restart)
ubuntu debian servery verás a qué me refiero.
El aviso se produce cada vez porque las direcciones IP cambian todo el tiempo cuando se utiliza el direccionamiento dinámico. Intente usar IP estática para que solo tenga que agregar la clave una sola vez.
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 me funcionó en el mismo escenario
Agregué las siguientes líneas a mi ~ / .ssh / config, deshabilitando así la comprobación estricta del host para todas las direcciones .local. (con la asignación de direcciones DHCP, las direcciones IP de mis máquinas locales siempre cambian)
host *.local
StrictHostKeyChecking no
Sin embargo, todavía recibes la advertencia, lo cual está bien para mí.
¿Estás utilizando el mismo usuario para conectarte?
Si ha iniciado sesión en una PC local como el usuario John y está conectado al servidor B como el usuario Adolf @ B y todo está bien, no significa que todo esté bien si está conectado a la PC local como el usuario Jane y se conecta al servidor B como usuario Adolf @ B .
Si desea iniciar sesión en el servidor B como usuario Beda desde la PC A sin contraseña, pruebe 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 la frase de contraseña vacía.
ssh Beda@B mkdir -p .ssh
Este comando crea el directorio, si aún no existen. De lo contrario, no imprima un mensaje de error.
cd ~/.ssh
Este comando cambia el directorio al directorio de inicio de sus 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 claves autorizadas en el servidor.
IMPORTANTE: Beda es su nombre de usuario en el servidor que está conectando, B es la IP de su servidor.
Ahora, puede conectarse al servidor B sin una contraseña o frase de contraseña:
ssh Beda@B
El hilo aquí puede ayudar.
Esencialmente, desea eliminar las claves RSA y ECDSA para ese host, luego usar ssh-keyscanpara volver a colocarlas en su known_hostsarchivo de una manera que no cause este conflicto. A mí me funcionó cuando tuve el mismo problema.
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:
Pregunta: ... y ¿cómo lo soluciono?
Como otros ya han respondido, elimine la clave de host ECDSA en caché para myserver que su cuenta ha almacenado en caché.
Este error siguió molestándome durante mucho tiempo. Por alguna razón, hizo una diferencia si haría un
ssh host
o
ssh host.domain
https://askubuntu.com/questions/87449/how-to-disable-strict-host-key-checking-in-ssh
luego me señaló la opción de cambiar el archivo de configuración. Vea mi script https://askubuntu.com/a/949731/129227 allí para automatizar el proceso.
CanonicalizeHostnamey CanonicalDomainsevitaría eliminar la comprobación estricta y haría que ssh considerara que host y host.domain fueran iguales.
Lo arreglé en un Chromebook desinstalando y reinstalando Secure Shell ... Funcionó de maravilla.
Aquí le mostramos cómo eliminar una huella digital de host conocida (del known_hostsarchivo) en un sistema operativo Chrome:
Encuentre el índice de la entrada del host infractor en la salida ssh cuando la conexión falla. Por ejemplo, en la línea debajo del índice ofensivo es 7 :
Offending ECDSA key in /.ssh/known_hosts:7
Abra la consola de JavaScript ( CTRL+ Shift+ J) de la ventana Secure Shell y escriba lo siguiente, reemplazando INDEXcon el valor apropiado (por ejemplo, 7 ):
term_.command.removeKnownHostByIndex(INDEX);
The ECDSA host key for server has changed. Mi forma es eliminar la cadena de caché relacionada sobre el dominio en~/.ssh/known_hosts. Entonces el ssh funciona.