GNU/Linux >> Tutoriales Linux >  >> Linux

Cómo deshabilitar la verificación de clave de host SSH en Linux

La comunicación SSH está protegida mediante criptografía de clave pública. Cuando un usuario se conecta al servidor SSH usando el cliente SSH por primera vez, el programa SSH almacena la clave pública del servidor SSH en el directorio de inicio del usuario dentro de un archivo, hosts_conocidos, en una carpeta oculta llamada ~/.ssh/, como se muestra en la siguiente captura de pantalla:

Ahora, posteriormente, cada vez que el cliente ssh se conecta al servidor, compara la clave pública enviada por el servidor con la clave pública del servidor almacenada en el archivo ~/.ssh/known_hosts. Si la clave pública no coincide, el cliente asume que el tráfico de la red está siendo secuestrado o que el servidor al que se realiza la conexión no es el mismo y, por lo tanto, el cliente SSH interrumpe la conexión, como se muestra aquí:

$ ssh [email protected]
@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@
@    WARNING: REMOTE HOST IDENTIFICATION HAS CHANGED!     @
@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@
IT IS POSSIBLE THAT SOMEONE IS DOING SOMETHING NASTY!
Someone could be eavesdropping on you right now (man-in-the-middle attack)!
It is also possible that the RSA host key has just been changed.
The fingerprint for the RSA key sent by the remote host is
3f:1b:f4:bd:c5:aa:c1:1f:bf:4e:2e:cf:53:fa:d8:59.
Please contact your system administrator.
Add correct host key in /home/admin/.ssh/known_hosts to get rid of this message.
Offending key in /home/admin/.ssh/known_hosts:3
RSA host key for 192.168.12.12 has changed and you have requested strict checking.
Host key verification failed.$

Hay varias razones posibles por las que cambió la clave del host remoto. Un ataque Man-in-the-Middle es solo una posible razón. Otras razones posibles incluyen:

  • Se reinstaló OpenSSH en el host remoto pero, por alguna razón, no se restauró la clave de host original.
  • El host remoto fue reemplazado legítimamente por otra máquina.

También existe la posibilidad de que se haya reformateado el servidor o se haya reemplazado la clave del servidor por algún motivo legítimo. En tales circunstancias, el usuario debe actualizar sus archivos ~/.ssh/known_hosts eliminando las claves antiguas para habilitar el inicio de sesión en el servidor.

Si está seguro de que esto es inofensivo, puede usar cualquiera de los 2 métodos a continuación para engañar a openSSH para que le permita iniciar sesión. Pero tenga en cuenta que se ha vuelto vulnerable a los ataques de intermediarios.

Método 1:eliminar la clave de host del archivo ~/.ssh/known_hosts

El primer método es eliminar el host remoto del archivo ~/.ssh/known_hosts. Tenga en cuenta que el mensaje de advertencia ya le indica el número de línea en el archivoknown_hosts que corresponde al host remoto de destino. La línea ofensiva en el ejemplo anterior es la línea 3 ("Clave ofensiva en /home/admin/.ssh/known_hosts:3")

Puede usar la siguiente línea para eliminar esa línea (línea 3) del archivo.

$ sed -i 3d ~/.ssh/known_hosts

Tenga en cuenta que con el método anterior, se le pedirá que confirme la huella digital de la clave del host cuando ejecute ssh para iniciar sesión.

Método 2:deshabilitar StrictHostKeyChecking

El segundo método utiliza dos parámetros openSSH:

  • Comprobación estricta de clave de host
  • Archivo de hosts conocidos por el usuario

Este método engaña a SSH configurándolo para usar un archivo de hosts_conocidos vacío y NO para pedirle que confirme la clave de identidad del host remoto.

$ ssh -o UserKnownHostsFile=/dev/null -o StrictHostKeyChecking=no [email protected]
Warning: Permanently added '192.168.12.12' (RSA) to the list of known hosts.
[email protected]'s password:

El parámetro UserKnownHostsFile especifica el archivo de base de datos que se usará para almacenar las claves de host del usuario (el valor predeterminado es ~/.ssh/known_hosts). El archivo /dev/null es un archivo de dispositivo de sistema especial que descarta cualquier cosa escrita en él y, cuando se usa como archivo de entrada, devuelve el Fin del archivo inmediatamente.

Al configurar el archivo de dispositivo nulo como base de datos de claves de host, se engaña a SSH haciéndole creer que el cliente SSH nunca antes se ha conectado a ningún servidor SSH y, por lo tanto, nunca se encontrará con una clave de host que no coincida. El parámetro StrictHostKeyChecking especifica si SSH agregará automáticamente nuevas claves de host al archivo de base de datos de claves de host. Al establecerlo en no, la clave de host se agrega automáticamente, sin confirmación del usuario, para todas las conexiones por primera vez. Debido al archivo de base de datos de clave nula, todas las conexiones se ven por primera vez para cualquier host de servidor SSH. Por lo tanto, la clave de host se agrega automáticamente a la base de datos de claves de host sin confirmación del usuario. Escribir la clave en el archivo /dev/null descarta la clave y reporta el éxito.

Al especificar las 2 opciones SSH anteriores en la línea de comando, puede omitir la verificación de la clave de host para ese inicio de sesión SSH en particular. Si desea omitir la verificación de la clave de host de forma permanente, debe especificar esas mismas opciones en el archivo de configuración de SSH. Puede editar el archivo de configuración global de SSH (/etc/ssh/ssh_config) si desea que los cambios sean permanentes para todos los usuarios.

Si desea dirigirse a un usuario en particular, modifique el archivo de configuración de SSH específico del usuario (~/.ssh/config). Las instrucciones a continuación se aplican a ambos archivos. Suponga que desea omitir la verificación de clave para una subred en particular (192.168.0.0/24).

Agregue las siguientes líneas al principio del archivo de configuración de SSH.

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

Tenga en cuenta que el archivo de configuración debe tener una línea como Host * seguida de uno o más pares de parámetros y valores. Host * significa que coincidirá con cualquier host. Esencialmente, los parámetros que siguen a Host * son los valores predeterminados generales. Debido a que se usa el primer valor coincidente para cada parámetro SSH, desea agregar los parámetros específicos del host o de la subred al principio del archivo.

Como advertencia final, a menos que sepa lo que está haciendo, probablemente sea mejor omitir la verificación de claves caso por caso, en lugar de realizar cambios generales permanentes en los archivos de configuración de SSH.


Linux
  1. Cómo cambiar el puerto SSH en Linux

  2. Cómo configurar la autenticación basada en clave SSH en Linux

  3. Cómo reparar la clave infractora en el archivo ~/.ssh/known_hosts

  4. Cómo configurar las claves SSH para el inicio de sesión ssh "sin contraseña" en Linux

  5. ¿Cómo deshabilitar una tecla del teclado en Linux (Ubuntu)?

Cómo deshabilitar el intercambio en Linux

Cómo configurar claves SSH en Debian 11 Linux

Cómo SSH al servidor a través de Linux

¿Cómo deshabilitar el inicio de sesión SSH para el usuario raíz en Linux?

¿Cómo generar y usar la clave SSH en el sistema Linux?

Cómo agregar una clave SSH a VS Code y conectarse a un host