No agregue hostkey a known

111

Quiero conectarme a un host a través de SSH pero no quiero que el nombre de host se agregue a mi ~/.ssh/known_hosts.

¿Cómo puedo hacer eso?

ssh hosts

— Albert
fuente

99

-o "UserKnownHostsFile /dev/null"

Deberia trabajar.

— Albert
fuente

3

Funciona según lo previsto, pero siempre informará: "Advertencia: se agregó permanentemente 'hostname, ip' (RSA) a la lista de hosts conocidos". Lo hice desaparecer con: 2> y 1 | grep -v "^Warning: Permanently added"

— Guillaume Boudreau

3

agregue -o "LogLevel ERROR" y ya no se quejará con Advertencias

— John

1

Nota: una solicitud para suprimir ese mensaje "Advertencia: se agregó permanentemente 'hostname, ip' (RSA) a la lista de hosts conocidos". fue reportado a los mantenedores bugzilla.mindrot.org/show_bug.cgi?id=2413

— Ben Creasy el

2

La tubería grepse fusionará con stdout y stderr; También el estado de salida puede cambiar. Si se usa bash, será mejor utilizar la sustitución de proceso para deshacerse del mensaje: ssh 2> >( egrep >&2 -v '^Warning: Permanently added') -o "UserKnownHostsFile /dev/null" [...]. Evitará la tubería y, por lo tanto, los cambios correspondientes en el manejo del estado de salida.

— Alex O

1

@John Es mejor usar uno de los otros métodos en estos comentarios, de lo contrario, está introduciendo una falla de seguridad debido a la posibilidad de ocultar otras advertencias no relacionadas

— Jon Bentley

97

Si desea este comportamiento porque está trabajando con servidores en la nube (AWS EC2, Rackspace CloudServers, etc.) o está aprovisionando constantemente nuevas imágenes en Vagrant, es posible que desee actualizar su configuración SSH en lugar de agregar alias bash o más opciones en el línea de comando.

Considere agregar algo como:

Host *.mydomain.com 
  StrictHostKeyChecking no
  UserKnownHostsFile /dev/null
  User foo
  LogLevel QUIET

Utilice lo más estricto posible como regex para host para estar seguro.
Establecer LogLevel en QUIET mantendrá la Advertencia que Guillaume mencionó de aparecer

— cclark
fuente

Realmente debería intentar no deshabilitar completamente StrictHostKeyChecking, por lo que la respuesta de cclark es un gran compromiso para trabajar con servidores en la nube.

— Alex Recarey

Esto me resultó muy útil ya que estaba usando Shipit (una herramienta de implementación de JavaScript) contra Vagrant. No podía llegar fácilmente a los parámetros que Shipit estaba pasando a SSH, así que esto me permitió eludir la herramienta y decirle lo que hice y no quería que recordara.

— John Munsch

1

LogLevel es lo que estaba buscando. ¡Tiene la ventaja adicional de no mostrar el aviso configurado de la compañía cuando ejecuta scripts! (Estoy ejecutando ahora w / loglevel ERROR)

— Anshu Prateek

¿En qué archivo agrego esto?

— Wim Deblauwe

Este es su archivo de configuración SSH. En Linux o macOS, el archivo generalmente estaría en un directorio llamado .ssh dentro de su directorio de inicio y llamado config - ~ / .ssh / config

— cclark

8

Tengo ganas de agregar la clave de host a sus conocidos_hosts (las personas que ejecutan estos servicios son, en mi experiencia, al menos lo suficientemente inteligentes como para mantener sus claves de host consistentes entre las máquinas que sirven el mismo nombre de host) y luego activar StrictHostKeyChecking, desactivar CheckHostIP y iniciar sesión con LogLevel ERROR le brindará la mejor experiencia sin sacrificar la seguridad. (De acuerdo, sin CheckHostIP necesita confiar en DNS, que es un gran agujero sin DNSSEC generalizado o algo similar; pero por el momento lo veremos debajo de la alfombra).

Utilizo un archivo de solo lectura conocido_hosts, así que tengo que hacer algo o recibo advertencias interminables sobre no poder agregar entradas a conocido_hosts.

Lo que uso:

Host github.com *.github.com
StrictHostKeyChecking yes
CheckHostIP no
LogLevel ERROR

Me gustaría que estos servicios publiquen sus claves de host SSH en sus sitios web a través de HTTPS, para poder copiarlas explícitamente sin tener que conectarme primero y exponerme potencialmente a un ataque MITM.

— Kyle Rose
fuente

7

Para una sola sesión ssh, use esto

ssh -o StrictHostKeyChecking=no -o UserKnownHostsFile=/dev/null user@host

— Quanlong
fuente

44

Esto no agrega nada nuevo a una respuesta aceptada en una pregunta que tiene 5 años.

— JakeGould

5

yo sugiero

LogLevel ERROR

terminado

LogLevel QUIET

así que aún aparece "No se pudo resolver el nombre de host" y otros errores similares

— kiloforce
fuente

deberías poder confiar en tus conexiones SSH, en mi humilde opinión. No solo haga silencio sobre sus riesgos.

— sylvainulg

3

Depende de verdad. Tenemos entornos de desarrollo que se destruyen cada semana y se reconstruyen, sus registros A permanecen igual pero su clave de host se genera cada vez que se construye. No podemos conservar las claves de host porque el registro A solo se define en una base de datos basada en un nombre de entorno, y los nombres de entorno se pueden descartar o crear nuevos en cualquier momento, por lo que la solución anterior es realmente útil.

— Alex Berry

2

¿Has intentado deshabilitar StrictHostKeyChecking? Puede hacerlo con la -oopción o en el archivo de configuración ~/.ssh/config.

— jneves
fuente

Ya estoy usando eso. Pero tiene un efecto diferente: reduce la rigurosidad para la comprobación de la clave del host. Es decir, cuando el host es desconocido, todavía se conecta cuando deshabilita esa opción. Por lo tanto, aún guarda el host. Pero creo que he encontrado la solución correcta (ver mi respuesta).

— Albert

0

Encontré las siguientes entradas .ssh / config útiles (LAN con DHCP y DNS):

 CheckHostIP no

 Host *.*
 CheckHostIP yes

El resultado es que los nombres de máquinas locales "zora" o "goron" no verificarán las direcciones IP asignadas dinámicamente, pero www.mycompany.com o node42.planetlab.com aún tendrán sus IP estáticas confirmadas.

— sylvainulg
fuente

No agregue hostkey a known_hosts para SSH