2010-03-29 09:43:00 +0000 2010-03-29 09:43:00 +0000
181
181

¿Cómo puedo evitar la verificación de host de SSH para los hosts conocidos?

Me aparece el siguiente mensaje cada vez que intento conectar un servidor mediante SSH. Escribo “sí”, pero ¿hay alguna forma de evitarlo? 

The authenticity of host '111.222.333.444 (111.222.333.444)' can't be established.
RSA key fingerprint is f3:cf:58:ae:71:0b:c8:04:6f:34:a3:b2:e4:1e:0c:8b.
Are you sure you want to continue connecting (yes/no)?
Fuente

Respuestas (8)

254
254
254
2010-03-29 10:53:30 +0000

Utilice la opción -o, 

ssh -o "StrictHostKeyChecking no" user@host
Fuente
108
108
108
2013-08-06 21:56:17 +0000

Añade las siguientes líneas al principio de /etc/ssh/ssh_config… 

Host 192.168.0.*
   StrictHostKeyChecking no
   UserKnownHostsFile=/dev/null

Opciones:

  • La subred del Host puede ser * para permitir el acceso sin restricciones a todas las IPs.
  • Editar /etc/ssh/ssh_config para la configuración global o ~/.ssh/config para la configuración específica del usuario.

Ver http://linuxcommando.blogspot.com/2008/10/how-to-disable-ssh-host-key-checking.html

Fuente
28
28
28
2010-03-29 09:47:30 +0000

Sólo debería aparecer esto la primera vez que se conecta a un nuevo host. Después de responder yes el host se almacena en ~/.ssh/known_hosts y no se le preguntará la próxima vez que se conecte.

Ten en cuenta que si ~/.ssh/known_hosts no puede ser escrito por alguna razón (por ejemplo, un problema de permisos) entonces se te pedirá cada vez que te conectes.
Fuente
11
11
11
2010-06-08 22:29:47 +0000

La mejor manera (porque no sacrifica la seguridad) es conectarse una vez a todos los ordenadores desde un solo cliente (se le pedirá cada vez, responda siempre que sí). Como se indica en la otra respuesta, las claves se almacenarán entonces en ~/.ssh/known\hosts. A continuación, copie este archivo en cada ordenador cliente desde el que quiera conectarse posteriormente (posiblemente para cada cuenta de usuario que utilice). Entonces, todas estas cuentas “conocerán” los ordenadores, por lo que no habrá ningún aviso.

La ventaja sobre sólo deshabilitar el prompt es que SSH puede realmente comprobar si hay un ataque MITM.
Fuente
1
1
1
2015-07-11 23:20:24 +0000

Si desea desactivar la confirmación, en lugar de la autenticación, puede utilizar la opción “-o CheckHostIP=no” 

ssh -i sergeys_rsa_key.pem -o CheckHostIP=no brin@8.8.8.8
Fuente
0
0
0
2015-12-12 18:09:32 +0000

Esto es probablemente porque su servidor de claves ssh cambió, ya que la ip o el dominio del servidor es el mismo pero la clave ssh no coincide.

Debe eliminar la clave almacenada en /home/$user/.ssh/known_hosts para evitar este mensaje.

Lo arreglé eliminando todas las claves en ese archivo, así que se crea un nuevo token para este nombre de dominio.
Fuente
0
0
0
2020-01-27 07:10:41 +0000

Me he enfrentado a un problema similar en el que a pesar de utilizar la solución verificada mencionada anteriormente, mi ssh no funcionaba y era porque el archivo knownhosts faltaba en el directorio ~/.ssh/ y el sistema de archivos era de sólo lectura. Así que durante el tiempo de ejecución tampoco pude crear el archivo ~/.ssh/knownhosts.

Si se enfrenta a un problema similar, compruebe si puede escribir el archivo known_hosts en la ubicación /tmp. Esto es mayormente habilitado para escribir incluso en un sistema de archivos de sólo lectura.

Más tarde en el comando ssh puede especificar que ssh lea el archivo known_hosts desde la ubicación /tmp. 

ssh -o UserKnownHostsFile=/tmp/known_hosts -o StrictHostKeyChecking=no user_name@destination_server_ip
Fuente
-2
-2
-2
2018-11-09 12:14:07 +0000

Comprueba los permisos de tu archivo ~/.ssh/known_hosts. Los míos eran incorrectos cuando tuve este problema. Lo arreglé con 

chmod 0600 ~/.ssh/known_hosts
Fuente