Pregunta “¿Agregar la clave de host correcta en conocido_hosts” / múltiples claves de host ssh por nombre de host?


Tratando de ssh en una computadora que controlo, recibo el mensaje familiar:

@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@
@    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 RSA key sent by the remote host is
[...].
Please contact your system administrator.
Add correct host key in /home/sward/.ssh/known_hosts to get rid of this message.
Offending RSA key in /home/sward/.ssh/known_hosts:86
RSA host key for [...] has changed and you have requested strict checking.
Host key verification failed.

De hecho, he cambiado la clave. Y leí unas cuantas docenas de publicaciones que dicen que la forma de resolver este problema es eliminando la clave anterior de la known_hosts expediente.

Pero lo que me gustaría es que ssh acepte tanto la clave antigua como la nueva. El idioma en el mensaje de error ("Add correct host key") sugiere que debería haber alguna forma de agregar la clave de host correcta sin eliminar la anterior.

No he podido averiguar cómo agregar la nueva clave de host sin eliminar la anterior.

¿Es esto posible, o el mensaje de error es extremadamente engañoso?


121
2017-10-13 14:01


origen


Esta es la clave de host que está generando el error. Un host debe tener una y solo una clave. Esto no tiene nada que ver con las claves de cliente o usuario. ¿Tiene una dirección IP que flota entre hosts distintos o algo? - David Schwartz
En mi caso, sé que voy a cambiar mucho entre las dos teclas en un futuro cercano mientras toco algunas cosas. Parece que esto también sería útil en la única IP con múltiples hosts que sugieras. Principalmente, solo quiero saber si esto es posible para mi propia educación, aparte de cualquier aplicación práctica particular. - Samuel Edwin Ward


Respuestas:


  1. Obtenga la clave rsa de su servidor:

    $ ssh-keyscan -t rsa server_ip
    # server_ip SSH-2.0-OpenSSH_4.3
    server_ip ssh-rsa AAAAB3NzaC1yc2EAAAABIwAAAQEAwH5EXZG...
    
  2. y en el cliente, agregue esta clave a ~/.ssh/known_hosts:

    server_ip ssh-rsa AAAAB3NzaC1yc2EAAAABIwAAAQEAqx9m529...(the offending key)
    server_ip ssh-rsa AAAAB3NzaC1yc2EAAAABIwAAAQEAwH5EXZG...
    

126
2017-10-13 14:38



¡Esto funcionó! Sin embargo, estoy usando "HashKnownHosts", así que la entrada se veía un poco fuera de lugar. Afortunadamente, ssh_config (5) me señaló a ssh-keygen (1), lo que explicaba que puedo usar "ssh-keygen -H" para codificar las entradas sin borrar. ¡Gracias! - Samuel Edwin Ward
Esto "funciona" pero no está verificando la clave, por lo que es vulnerable a los ataques mitm ... - JasperWallace
@JasperWallace, siempre que el primer paso se realice a través de una conexión segura (por ejemplo, usando localhost) debería ser bastante seguro, creo - ony
¿Hay alguna forma de reunir todos los tipos de claves del servidor? A veces no sabes si son RSA, DSA, ECDSA, RSA1 ... etc. - Sopalajo de Arrierez
@SopalajodeArrierez la misma página de manual también dice que puede separar tipos con comas, así que ssh-keyscan -t rsa1,dsa,rsa,ecdsa,ed25519 server_ip - pero la única razón para encontrar rsa1 y dsa Las claves son para identificar los servidores que necesitan ser actualizados / reconfigurados. - kbolino


Eliminar que la entrada de conocido_hosts usando:

ssh-keygen -R *ip_address_or_hostname*

Esto eliminará la IP problemática o el nombre de host de arenas conocidas Archivo e intente conectarse de nuevo.

De las páginas 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 con hash (vea la opción -H   encima).


74
2018-02-09 06:49



msgstr "cómo agregar la nueva clave de host sin quitar la antigua". - Samuel Edwin Ward
Esta es la mejor solución ! - Thomas Decaux
¿Cómo tiene esto 19 votos? No se acerca a responder la pregunta formulada. - Molomby
Su pregunta aparece en segundo lugar cuando busco "git ssh update host key automáticamente". Esta respuesta es lo que estaba buscando. Abrir una nueva pregunta con exactamente lo que quiero podría cerrarla como un duplicado. - Jason Goemaat
El nombre de host también funciona - damluar


Una forma muy sencilla es:

cp ~/.ssh/known_hosts ~/.ssh/known_hosts.bak

Luego edite known_hosts para borrar la clave original, luego ssh al host usando:

ssh name@computer

Agregará la nueva clave automáticamente; luego compara los dos archivos. Un programa como meld es una buena manera de comparar los dos archivos. Luego fusionar los archivos para hacer conocido_hosts contienen ambas claves

Mi "razón" para mantener dos claves es que el sistema de destino es multiboot, aunque me atrevo a decir que hay una forma de sincronizar las claves en todas las instalaciones, parece más sencillo permitir varias claves.

EDITAR 2015/06

Debería agregar, revisándolo ahora, que me doy cuenta de una manera aún más sencilla [siempre que la entrada sea identificable, normalmente desde el nombre de host / dirección IP, aparte del mensaje de error que hace referencia a su ubicación específica];

  1. Edite known_hosts para agregar # al comienzo de la entrada 'antigua' en conocido_hosts temporalmente
  2. Conecte [ssh al host], acepte la solicitud de agregar la nueva clave 'automáticamente'
  3. A continuación, vuelva a editar known_hosts para eliminar el #

Incluso hay la opción HostKeyAlias ​​como en

ssh -o HostKeyAlias=mynewaliasforthemachine name@computer

luego, posteriormente, después de que ssh client agregue la nueva clave bajo el alias, puede editar known_hosts para sustituir el nombre de host / dirección "real" por el alias o conectarse a esa encarnación de ese host con la opción de alias para siempre


16
2018-04-30 22:29



Esta 'fusión'? meldmerge.org - Samuel Edwin Ward
esa es la fusión :) apt-get / yum nombre de instalación es simplemente fusión - Mark
Hice una variante de su sugerencia que funcionó bien: en lugar de cp, mv, luego ssh, luego cat ~ / .ssh / known_hosts.bak ~ / .ssh / known_hosts> tmp; mv tmp ~ / .ssh / known_hosts - Peter N Lewis


Tengo el mismo problema con una frambuesa pi que arranco con varios sistemas diferentes (sistema dev para compilar binarios de brazo, proyecto, xbmc, etc.) y me he encontrado con el mismo problema. Usan DHCP en una red local y mi enrutador siempre reutilizó la misma IP ya que la dirección MAC era la misma. Lo resolví usando diferentes nombres de dominio en mi archivo hosts:

10.10.10.110 pi-dev
10.10.10.110 pi-xbmc
10.10.10.110 pi-etc

El archivo known_hosts guarda las huellas dactilares por nombre de host, por lo que, a pesar de que es la misma dirección IP, cada nombre de host único recibe una entrada diferente.

Me cansé de agregar los nombres a los archivos de hosts cada vez que usaba un sistema nuevo, así que se me ocurrió una forma aún más perezosa al usar ceros en las direcciones IP como:

$ ssh pi@10.10.10.110
$ ssh pi@010.10.10.110
$ ssh pi@10.010.10.110

Cada variación de la dirección IP (no canónica) obtiene su propia entrada en known_hosts.


7
2017-11-04 02:28



La gente de OpenSSH se dio cuenta de que esta laguna ya no funciona en las versiones más recientes. - Mike
Puedes usar CheckHostIP no en ~/.ssh/config Para poder seguir utilizando la laguna. Incluso puedes definir tus alias allí para no tener que jugar con /etc/hosts y definir CheckHostIP no solo para estos 3 nombres de host. - GnP


Si tanto su cliente como su servidor tienen OpenSSH 6.8 o más nuevo, puede usar el UpdateHostKeys yes opción en tu ssh_config o ~/.ssh/config. Por ejemplo:

Host *
    UpdateHostKeys yes

Esto hace que SSH almacene todas las claves de host que el servidor tiene que known_hosts, y cuando un servidor cambia o elimina una clave de host, la clave también se cambia o elimina en su known_hosts.


2
2017-09-22 04:28



¡Esta es, con mucho, la respuesta más útil! Aunque no ofrece explícitamente una manera de resolver la pregunta original si ya se cambió una clave de host, todas las demás respuestas son inseguras ya que no verifican la nueva clave de host. Esta opción le permite hacer una transferencia segura a nuevas claves de host. - Jaap Eldering


No veo por qué quiere trabajar con dos claves, pero ciertamente puede agregar más de una clave válida a la ~/.ssh/known_hosts Archivo, pero tendrás que hacerlo manualmente.

Otra solución podría ser utilizar el StrictHostKeyChecking=no Opción para este host específico:

ssh -o StrictHostKeyChecking=no user@host

que podría poner en un alias en su ~/.profile o algo similar.

alias hc=ssh -o StrictHostKeyChecking=no user@host

1
2017-10-13 14:49



StrictHostKeyChecking no parece ayudar en este caso; al parecer, solo especifica el comportamiento cuando el host no está en el archivo conocido_hosts. Mencionado aquí gossamer-threads.com/lists/openssh/dev/45349#45349 - Samuel Edwin Ward
Funciona aqui Obtendrá la advertencia, pero el inicio de sesión continúa. - Sven♦
Eso es extraño. ¿Está utilizando la autenticación de contraseña? ¿Estás utilizando OpenSSH? - Samuel Edwin Ward


Si tu solamente ssh en una red local entonces ...

Una solución simple es borrar el archivo de clave anterior y reemplazarlo con uno en blanco. Esto le permitirá volver a autorizar todas sus conexiones con nuevas claves. Si tiene claves ssh almacenadas para sitios fuera de su red local, entonces debe asegurarse de que su conexión inicial sea segura como lo hizo la primera vez que se conectó a ese servidor.

p.ej

cp known_hosts known_hosts.old
rm known_hosts
nano known_hosts

Luego presione espacio, retroceda cntl + xy 'y' para guardar el nuevo búfer (archivo). Es una mala práctica, pero está bien, siempre y cuando no se encuentre fuera de su red local (por ejemplo, una unidad o un servidor de trabajo)

En una red local segura, esto es seguro porque simplemente no puedes conseguir un hombre en el ataque central.

Siempre es mejor usar el código que entiendes!


0
2018-06-15 21:44



Limpiando la totalidad known_hosts archivo cada vez se negará la mayor parte de la seguridad proporcionada por ssh. - kasperd
De hecho, argumentaría que en una red interna segura, es más seguro entender su código y burlar la seguridad que copiar el código sin pensar. En una red externa entonces la situación sería diferente. - Aaron


Tantas respuestas, pero tantas que renuncian a la protección al desactivar la comprobación estricta del host, o destruir la información del host no relacionada o simplemente obligar al usuario a aceptar claves de forma interactiva, posiblemente en un momento posterior, cuando sea inesperado.

Aquí hay una técnica simple que le permite dejar el control de host estricto, pero actualizar la clave de forma controlada, cuando esperar para cambiar:

  • Eliminar la clave antigua y actualizar en un comando

    ssh-keygen -R server.example.com && \
        ssh -o StrictHostKeyChecking=no server.example.com echo SSH host key updated.
    
  • Repita con la (s) dirección (es) IP u otros nombres de host si los usa.

La ventaja de este enfoque es que cambia la clave del servidor exactamente una vez. La mayoría de las versiones de ssh-keygen parecen no devolver un error si el servidor que intenta eliminar no existe en el archivo de hosts conocidos; si este es un problema para usted, use los dos comandos en secuencia.

Este enfoque también verifica la conectividad y emite un buen mensaje para los registros en el comando ssh (que inicia sesión, actualiza la clave del host y genera salidas). Clave de host SSH actualizada entonces inmediatamente sale.

Si su versión de ssh-keygen devuelve un código de salida distinto de cero, y prefiere manejar esto sin errores, independientemente de la conexión anterior, simplemente use los dos comandos en secuencia, ignorando cualquier error en el comando ssh-keygen.

Si usa esta técnica, nunca necesita modificar su comando ssh, o desactivar la verificación del host, excepto durante ese comando ssh. Puede estar seguro de que las futuras sesiones ssh funcionarán sin conflicto o la necesidad de aceptar explícitamente una nueva clave, siempre que el comando ssh anterior se ejecute sin errores.


-1
2017-09-18 01:56





Yo tuve el mismo problema.

Todo lo que hice fue sudo nano /home/user/.ssh/ host_allow y borró la llave.

Cuando regresé al servidor, se agregó una nueva clave.


-3
2018-05-18 11:31



Más información acerca de por qué sucede esto sería útil para la respuesta. - Drew Khoury


Utilice el comando sed para hacer eliminar la línea ofensiva

OUTPUT: as show in above example
Offending key in /home/user/.ssh/known_hosts:86

Eliminar la línea 86 como se menciona en los hosts conocidos.

CODE: 
sed -i '86d' /home/user/.ssh/known_hosts

La próxima vez que acceda utilizando ssh, el sistema agregará automáticamente una nueva clave.

nuevas versiones de ssh

utilizar:

ssh-keygen -R <hostname|ip address>

Se eliminará la entrada del nombre de host y se realizará una copia de seguridad de la antigua .known_host como known_hosts.old


-4
2018-06-14 05:47



"Pero lo que me gustaría es que ssh acepte tanto la clave antigua como la nueva". Tu respuesta no hace esto. - Samuel Edwin Ward