¿Cómo eliminar la comprobación estricta de la clave RSA en SSH y cuál es el problema aquí?


42

Tengo un servidor Linux que cada vez que me conecto me muestra el mensaje que cambió la clave de host SSH:

$ ssh root @ host1 @@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@ @@@@@@@@@@@@@@ @ ADVERTENCIA: ¡LA IDENTIFICACIÓN DEL HOSTING REMOTO HA CAMBIADO! @ @@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@ @@@@@@@@@@ ¡ES POSIBLE QUE ALGUIEN ESTÉ HACIENDO ALGO MALDITO! ¡Alguien podría estar espiándote ahora mismo (ataque de hombre en el medio)! También es posible que la clave de host RSA se haya cambiado. La huella digital para la clave RSA enviada por el host remoto es 93: a2: 1b: 1c: 5f: 3e: 68: 47: bf: 79: 56: 52: f0: ec: 03: 6b. Por favor, póngase en contacto con el administrador del sistema. Agregue la clave de host correcta en /home/emerson/.ssh/known_hosts para deshacerse de este mensaje. Clave ofensiva en /home/emerson/.ssh/known_hosts:377

La clave de host RSA para host1 ha cambiado y usted ha solicitado una verificación estricta. La verificación de la clave del host ha fallado.

Me mantiene conectado durante unos segundos y luego cierra la conexión.

host1: ~ / .ssh # Lectura del host remoto host1: Restablecimiento de la conexión por parte del par La conexión al host1 cerrada.

¿Alguien sabe qué está pasando y qué puedo hacer para resolver este problema?


1
Esta pregunta anterior engaña: serverfault.com/questions/2988/…
Drew Stephens

Respuestas:


68

No elimine todo el archivo conocido_hosts según lo recomendado por algunas personas, esto anula totalmente el punto de la advertencia. Es una característica de seguridad para advertirle que puede haber sucedido un hombre en el medio del ataque.

Le sugiero que identifique por qué cree que algo ha cambiado, lo más probable es que una actualización de SSH haya alterado las claves de cifrado debido a un posible agujero de seguridad. Luego puede purgar esa línea específica de su archivo conocido_hosts:

sed -i 377d ~/.ssh/known_hosts

Este d eletes línea 377 como se muestra después de los dos puntos en la advertencia:

/home/emerson/.ssh/known_hosts:377

Alternativamente, puede eliminar la clave relevante haciendo lo siguiente

ssh-keygen -R 127.0.0.1 (obviously replace with the server's IP)

NO purgue todo el archivo y asegúrese de que esta sea realmente la máquina a la que desea conectarse antes de purgar la clave específica.


No va a eliminar más de 350 servidores debido a una discrepancia de clave. ¿Alguna idea de por qué sigue cerrando la conexión?
setatakahashi

¿No se resuelve una vez que eliminas el registro conocido dehosting_hosts? De lo contrario, ¿podría ejecutar el cliente ssh en modo detallado y pegarlo en alguna parte?
Adam Gibbins

1
Está cerrando la máquina porque la clave del host no es válida, tal como dice. Si se toma en serio la seguridad, debe consultar con el administrador del servidor para asegurarse de que la clave del host haya cambiado por un motivo legítimo. Si es así, puede reemplazarlo, como explicó Adam.
Matthew Flaschen

Seguí tu sugerencia pero $ sed -i "46 d" ~ / .ssh / known_hosts sed: 1: "/Users/myusr/.ssh ...": caracteres adicionales al final del comando l, así que lo eliminé manualmente con vim y funcionó. Gracias!
Luis Ramirez-Monterosa

3
La sintaxis de Adam es casi correcta, pero necesita un espacio entre la "377" y la "d". Además, en OS X, los hosts conocidos se encuentran en ~ / .ssh / known_hosts; tenga en cuenta la falta de un "." en el nombre del archivo.
ktappe

27

Creo que aunque algunas de las respuestas aquí abordan el curso de acción recomendado en la pregunta del OP, no responde completamente la pregunta.

La pregunta dice "¿Cómo eliminar la comprobación estricta de claves RSA en SSH y cuál es el problema aquí?"

El problema aquí es, como lo aconsejaron algunos otros, un cambio en el host probablemente debido a la reinstalación del servidor (escenario más común). Y la solución recomendada es eliminar la clave infractora del archivo .ssh / Authorised_keys con un sed en línea.

Sin embargo, no vi ninguna respuesta que aborde la parte específica de la pregunta " Cómo eliminar la comprobación estricta de la clave RSA en SSH ".

Puede eliminar la comprobación de StrictHostKey en su archivo de configuración ssh, generalmente almacenado en ~/.ssh/config.

A continuación se proporciona un ejemplo de bloque de host:

Host 101
  HostName yourip|hostname
  User youruserid
  IdentityFile /path/to/keyfile
  Port 22
  StrictHostKeyChecking no

La línea añadida específicamente es la última StrictHostKeyChecking noque hace exactamente eso. Dependiendo de su escenario específico, esto puede ser útil para usted, como ejecutar múltiples contenedores virtualizados en un servidor dedicado, con solo unos pocos ips, detener e iniciar otra instancia en la misma ip.


3
+1 Porque esta publicación en realidad aborda la parte de comprobación estricta del mensaje de error.
Shibumi

1
+1 de mí también por abordar el contenido de la pregunta. Dependiendo de los factores, puede haber más por hacer. Este enfoque degrada la comprobación del host de "estricto" a "algo" (mi terminología). En mi situación, eso dejó a ssh con permiso para evitar que inicie sesión porque la forma en que quería iniciar sesión era ingresar una contraseña, y eso fue deshabilitado por "alguna" comprobación de host. Por lo tanto, debe continuar y dirigir ssh para usar / dev / null como "UserKnownHostsFile". Esto establece la comprobación del host en "ninguna" en efecto y se aplican las ADVERTENCIAS DE DIRE anteriores, así que no lo hagas de forma global o permanente.
Cardiff Space Man

Esta es realmente una solución elegante. ¡Gracias por compartir!
LeOn - Han Li

10

Otra forma de eliminar StrictHostKeyChecking, cuando solo necesita hacerlo para un solo servidor:

ssh <server> -o StrictHostKeyChecking=no

Le permitirá iniciar sesión pero no solucionará el problema permanentemente.
Andres Canella

Cuando lo hago, me da la oportunidad de agregar la clave, que luego soluciona el problema permanentemente
Greg Dougherty

Tal vez tenemos un problema diferente? Me estoy conectando a un servidor que tenía una IP diferente antes.
Andres Canella

Si tiene un servidor cuyos datos han cambiado, debe eliminarlos de su archivo de hosts conocidos (después de establecer primero que el cambio es correcto) y agregar su nueva información. Si tiene un nuevo servidor, -o le permitirá conectarse al servidor y agregar su información.
Greg Dougherty

Creo que en realidad es una buena práctica mantener StrictHostKeyChecking establecido en SÍ en su configuración y solo usar este interruptor cuando sepa que se está conectando a un nuevo servidor o que haya cambiado las claves en un servidor antiguo.
mohak

5

En primer lugar, ¿es esta tu máquina? ¿Cambió a sabiendas las claves de host? Si no, estaría muy preocupado de que algo haya alterado esos datos.

En segundo lugar, sube la depuración ssh,

ssh -vvv user@host

y vea lo que le dice, también intente buscar, / var / log / secure y / var / log / messages en el servidor al que está tratando de conectarse para obtener pistas, sshd da buenos mensajes de error.

En tercer lugar, ¿esta máquina está conectada a internet? ¿Debería realmente permitir los inicios de sesión de root?


1
+1 para el comentario de inicios de sesión de raíz
Fahad Sadah

Todo lo que se necesita para que ocurra este error es la máquina de destino que se está volviendo a crear. Si te estás conectando a un objetivo que está de tu lado de una DMZ, es muy poco probable que se produzca un ataque MitM.
ktappe

3

Obtiene esto porque algo ha cambiado (como nueva NIC, nueva IP, cambio en el software del servidor, etc.). El enfoque de seguridad tiene un buen artículo sobre la protección de clave de host SSH .

Simplemente quite la clave (usando SFTP o similar) del servidor, editando el $HOME/.ssh/known_hostsarchivo y acepte la nueva en la próxima conexión.

Su conexión podría estar cayendo debido a la configuración StrictHostKeyChecking. Vea este hilo para un problema similar.


2
Noooo, por favor no hagas esto. Esto anula totalmente toda la seguridad que proporciona esta característica. Solo elimine la clave específica que ha cambiado, no todos los hosts conocidos.
Adam Gibbins

55
No recomendé eliminar el archivo known_hosts, recomendé editarlo y eliminar la clave.

Ooop, lo siento, mal leído.
Adam Gibbins

2
Este mensaje ciertamente no puede ser activado por una nueva dirección IP, y mucho menos por una nueva NIC. Ver la respuesta correcta de Adam Gibbins.
bortzmeyer

1
Antes de votar en contra (estoy encontrando personas muy felices con esto), investigue. Lea este artículo de Security Focus, securityfocus.com/infocus/1806 . Cito un poco: "¿Por qué puede cambiar una clave de host? La máquina a la que desea conectarse se ha movido a un nombre DNS o dirección IP diferente, o se ha reemplazado por uno completamente nuevo". Si una respuesta es horriblemente incorrecta, permita la posibilidad de una corrección. Después de todo, este es un wiki.

3

Como el 'host' [ampliamente definido, podría ser todo, desde una reinstalación / arranque múltiple hasta una computadora completamente diferente con una dirección IP a la que se ha conectado antes, por ejemplo], parece que el cliente ssh ha cambiado, le está dando el error.

No es necesario desactivar la comprobación estricta, ni tampoco es razonable la eliminación total de las claves guardadas.

Es muy posible tener dos claves diferentes enumeradas enhosting_hosts para un nombre de host o dirección IP en particular; dándole 2 alternativas según si cree que puede necesitar la clave 'antigua' que está actualmente almacenada en conocido_hosts

Elimine la clave particular a la que se refiere, en l377 de known_hosts para el OP, o mantenga ambos

La forma más sencilla de mantener ambos, evitando la eliminación de claves en conocido_hosts, es

  1. Edite conocido_hosts para agregar # al comienzo de la entrada 'antigua' referenciada en conocido_hosts [@ l377] temporalmente
  2. Conéctese [ssh al host], acepte la solicitud para agregar la nueva clave 'automáticamente'
  3. Luego vuelva a editar known_hosts para eliminar el #

más respuestas en "Agregar la clave de host correcta en conocido_hosts" / múltiples claves de host ssh por nombre de host?


No sabía sobre el truco de las dos llaves. Este no es un comportamiento documentado, ¿verdad?
hackerb9
Al usar nuestro sitio, usted reconoce que ha leído y comprende nuestra Política de Cookies y Política de Privacidad.
Licensed under cc by-sa 3.0 with attribution required.