GNU/Linux >> Tutoriales Linux >  >> Linux

¿Ignorar temporalmente mi archivo `~/.ssh/known_hosts`?

Solución 1:

Puedes usar ssh -o StrictHostKeyChecking=no para desactivar la verificación known_hosts momentáneamente. Pero yo desaconsejaría esto. Realmente debería verificar por qué la clave de host ha cambiado.

Otra opción es agregar una entrada específica a su ~/.ssh/config para el anfitrión en cuestión. Este podría ser un enfoque válido si tiene un determinado host que genera nuevas claves de host cada vez que se reinicia y se reinicia por una razón válida varias veces al día.

Host <your problematic host>
  StrictHostKeyChecking no

Solución 2:

Para ignorar por completo su archivo de hosts conocidos en un entorno POSIX, configure el GlobalKnownHostsFile y UserKnownHostsFile opciones a /dev/null :

ssh -o GlobalKnownHostsFile=/dev/null -o UserKnownHostsFile=/dev/null [email protected]

Configuración del StrictHostKeyChecking=no le permitirá conectarse pero SSH aún mostrará una advertencia :

ssh -o StrictHostKeyChecking=no [email protected]

Como han señalado otros, probablemente sea mejor abordar el problema subyacente. Podría considerar la autenticación de certificado SSH para verificar hosts, por ejemplo.

Solución 3:

Si ha reinstalado el servidor y, por lo tanto, la identificación ha cambiado, solo debe eliminar la línea 155 especificada de /Users/alexus/.ssh/known_hosts y adelante.

Si cambia entre diferentes redes privadas, debe usar nombres de host para conectarse, ya que el cliente ssh también guardará claves según el nombre de host. Agregue algo como esto a su /etc/hosts :

10.52.11.171 server1
10.52.11.171 server2

y luego usa ssh server1 cuando está conectado a la subred 1 y ssh server2 cuando está conectado a la subred2. De esta forma, ambos servidores pueden tener claves de host diferentes.

Solución 4:

-o StrictHostKeyChecking=no solo funciona si el host no está ya presente en el archivo unknown_hosts.

Creo que es más limpio (sin advertencias), si espera que la clave de los hosts cambie, tal vez debido a la clonación de máquinas virtuales, para obligar a ignorar ese tipo de hosts como este:

# Handle possible SSH key changes
host_key=$(ssh-keyscan -t rsa ${host_ip})
grep "${host_key}" ~/.ssh/known_hosts >/dev/null || {
    ssh-keygen -R ${host_ip}
    echo ${host_key} >>  ~/.ssh/known_hosts
}

# connect as normal way
ssh [email protected]${host_ip} "hostname"

Solución 5:

Algunas personas dicen que no está bien, que no debes hacer esto y demás, pero también necesito esto para probar un par de dispositivos integrados una y otra vez. Debes deshabilitar StrictHostKeyChecking=no , esto es correcto, pero también restablece el archivo de hosts conocidos a /dev/null . Aquí un ejemplo con inicio de sesión automático y ps en el dispositivo remoto.

sshpass -p pass ssh -o StrictHostKeyChecking=no -o UserKnownHostsFile=/dev/null [email protected] 'ps ax'

Linux
  1. [Linux]:Cómo aplicar hash a archivos de hosts conocidos del directorio ~/.ssh/

  2. ¿Cómo maneja Linux múltiples separadores de rutas consecutivas (/home////username///file)?

  3. Cómo verificar la sintaxis del archivo /etc/ssh/sshd_config

  4. Recuperar el archivo eliminado que se está escribiendo actualmente

  5. SSH:cómo incluir el comando -t en el archivo ~/.ssh/config

Uso del archivo de configuración SSH

Autenticación SSH de Ansible y escalada de privilegios

/dev/null en Linux

Archivos /proc/cpuinfo y /proc/meminfo en Linux

Comprender los archivos /proc/mounts, /etc/mtab y /proc/partitions

¿Deberían vivir los sitios web en /var/ o /usr/ según el uso recomendado?