Forzar a ssh a no imprimir la advertencia "La identificación remota del host ha cambiado"

23

¿Hay alguna manera de evitar mensajes de advertencia de impresión ssh como este? 

"@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@\r",
"@    WARNING: REMOTE HOST IDENTIFICATION HAS CHANGED!     @\r",
"@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@\r",

Aunque la identidad del host remoto ha cambiado, sé que está bien y solo quiero deshacerme de esta advertencia.

ssh taza de cafe
fuente

Respuestas:

16

Cuatro maneras:

Para conectarse una vez a un sistema con una nueva clave de host, sin tener que responder preguntas, conéctese con la siguiente opción:

ssh -q -o "StrictHostKeyChecking no" this.one.host.name

Para eliminar permanentemente la advertencia para todos los sistemas, edite su ~/.ssh/configarchivo para agregar las siguientes líneas:

Host *
StrictHostKeyChecking no

Para eliminar permanentemente todas las advertencias para este un servidor, editar el ~/.ssh/configarchivo y añadir las siguientes líneas:

Host this.one.hostname
StrictHostKeyChecking no

Para eliminar la advertencia de este cambio para este servidor, elimine la clave de host para ese servidor ~/.ssh/known_hosts. La próxima vez que se conecte, se agregará la nueva clave de host.

Jenny D
fuente
En la segunda opción, ¿esa configuración debe hacerse en el lado del servidor al que nos estamos conectando?
coffeMug
No, es tuyo lo $HOME/.ssh/configque importa tanto en la segunda como en la tercera opción.
Jenny D el
Esto todavía imprime una advertencia para mí (aunque sí permite la conexión).
Michael Mior el
24

Agregue esto a su ~ / .ssh / config:

Host 10.*                            # use your own pattern here, eg. *.example.com, example.*.com
  StrictHostKeyChecking   no         # turn off the HostKey check                                                               
  LogLevel                ERROR      # keep it from printing to STDOUT
  UserKnownHostsFile      /dev/null  # (optional) add the host automatically to a black hole, otherwise it would be added to ~/.ssh/known_hosts and show you a warning/message at the top of your session. You may want it added to known_hosts if your shell uses `ssh` autocompletion, such as fish.
Elijah Lynn
fuente
3
MOD UP - solo uno que realmente respondió la pregunta - esta fue la única respuesta no solo para trabajar, sino para SUPRIMIR las ADVERTENCIAS.
Brad
Vaya, parece que los usuarios de fish shell no podrán usar la función de autocompletar ssh agradable para hosts conectados previamente si ponen UserKnownHostFile en / dev / null. Los usuarios de Fish y posiblemente todos no deberían configurar eso.
Elijah Lynn el
Es mejor que cree un ssh0script / alias / función ssh -o UserKnowHostsFile=/dev/null -o LogLevel=ERRORy lo use expresamente en lugar de volcar esas opciones ~/.ssh/config. Puede olvidarse de ellos y luego preguntarse por qué los cheques no funcionaron cuando solo quería que funcionaran.
Tío Billy
20

Puede quitar la línea para ese host ~/.ssh/known_host(cada host tiene una línea como entrada allí).

La alternativa es usar:

ssh -q -o "StrictHostKeyChecking no" ....

Solo el uso -qhabría sshfallado silenciosamente.

Timo
fuente
9

A veces no es conveniente agregar claves de host al valor predeterminado $ HOME / .ssh / known_hosts.

Úselo -o UserKnownHostsFile=/dev/nullademás de -qy -o StrictHostKeyChecking=nopara mantener conocido_hosts despejado. Aquí hay un ejemplo:

ssh -o UserKnownHostsFile=/dev/null -o StrictHostKeyChecking=no -q [email protected]
Chico inteligente
fuente
2

Una sugerencia alternativa es identificar por qué la clave del host está cambiando y hacer que deje de hacerlo.

Como ejemplo: si está compilando hosts en contenedores o mediante un sistema de aprovisionamiento, asegúrese de que estos usen constantemente la misma clave de host conocida por instancia.

Sé que esto no siempre es posible, y los hosts pueden administrarse fuera de su alcance de control, pero esas advertencias de hostkey están ahí por una razón y son significativas. Reducir el recuento de excepciones es una buena cosa.

De lo contrario, voto por StrictHostKeyChecking No en su ~/.ssh/config para el host específico en cuestión solamente.

Dr. Edward Morbius
fuente