29 december 2022
¿Cómo soluciono el error de SSH "Too Many Authentication Failures" en Ubuntu?
¡Trabajadores!
Un Movimiento no versa tanto por la calidad de sus integrantes, sino por la de sus dirigentes. Esto es así pues la Masa Popular - que es el verdadero consumo - se rige por la primacía del número: la cantidad de sus adherentes.
Es que el hombre dejó hace millones de años de ser un ser gregario para transformarse en un individuo de alcance social, que se ha integrado en tribus, reinos, naciones, y hoy en Estados.
Quien Conduzca en nuestro Movimiento ha de obrar en búsqueda de la inclusión: incorporar a todo el que se pueda. Ha de dar acceso a todos los beneficios y bienaventuranzas que tiene pertenecer a un Movimiento de raigambre popular.
Para ingresar a un Movimiento ayuda tener una buena cara, como esta:
Pero también ayuda contar con las necesarias credenciales de Secure Shell. Esto es así pues este sistema nos permite acceder de forma remota o raramente local, a distintos sistemas de servicio GNU con Linux; una vez establecido el enlace, podremos utilizar secure Shell : al fin y al cabo he instruido que esto sirve para realizar cualquier acción dentro de un sistema GNU con Linux al amparo de una conexión criptográficamente protegida. Pero a pesar de esto, podríamos encontrarnos con numerosos errores de rechazo de conexión SSH. Tal vez el error más común de autenticación con llaves SSH sea el inefable "Too Many Authentication Failures", que en el idioma de Braden quiere decir algo así como "Demasiados intentos de Autenticación fallidos".
Esto tiene una explicación bastante terrenal, pero que hay que conocer. Si utilizamos el sistema de llaves públicas SSH, será normal contar con archivos que conforman dichos pares de llaves SSH. En el caso de GNU con Linux, estos suelen econtrarse en nuestro directorio de usuario oculto ~/.ssh.
Por ejemplo, podríamos abrir una terminal con Ctrl+Alt+T y solicitar un listado de las llaves tenemos instaladas en nuestro cliente de SSH. A tal fin utilizaremos el siguiente comando:
ssh-add -l
Pues bien señores, cuando nos conectamos a un servidor SSH, lo normal es que no le especifiquemos al cliente "cual llave usar" de entre todas las que tenemos en el llavero .ssh. Esto suele responder a la fiaba. En tal caso, el cliente SSH probará torpemente una llave tras otra en el agente de autenticación SSH del servidor, como si de un "ebrio llegando de juerga" se tratara. Lo normal es ir descartándolas en orden alfabético hasta encontrar la que corresponda, autenticar, y "entrar" a la sesión de shell seguro...
El error mencionado se produce por un "limitador de intentos de prueba" para las llaves, el cual está situado en el servidor. Normalmente está configurado en "seis intentos", y lógicamente si tenemos más llaves que dicha cantidad, el procedimiento podría fallar.
Pues bien señores, existen dos maneras de solucionarlo. En el cliente
En caso de necesitarlo, podríamos intentar lograr acceder a través del uso de la contraseña de conexión (en lugar de la llave). Para ello debemos indicar tal preferencia en el comando mediante el prefijo PreferredAuthentications. Por ejemplo, al ingresar:
ssh -o PreferredAuthentications=password usuario@servidor
...el servidor debería pedirnos la contraseña (si tal método está habilitado, claro está).
Otra consiste en probar si podremos entrar sin usar llaves, de manera tal de utilizar el método de contraseñas
Si quisiéramos que siempre utilice la incómoda (y usualmente insegura) acceso por contraseña, podríamos automatizarlo desde el lado del cliente de conexión. En el equipo cliente ingresamos:
nano ./ssh/config
...y agregamos los datos del sevidor. Por ejemplo:
Host cgt Port 22 User fulano PreferredAuthentications password HostName cgt.local
También podríamos especificar directamente qué llave queremos utilizar para dicho usuario utilizando la variable IdentityFile para cada conexión. Esto se haría de la siguiente manera:
Host cgt Port 22 User fulano IdentityFile ~/.ssh/llave_cgt_fulano_ed25519 HostName cgt.local
Acto seguido, guadamos los cambios con Ctrl+o. En el servidor
Otra opción es modificar directamente el servidor, lo cual proporciona una solución general. En tal caso, debemos modificar la variable MaxAuthTries del servidor SSH. Esta normalmente viene configurada en 6 intentos, lo cual suele ser adecuado para prácticas laxas donde siempre se usaba una única llave para todo. Sin embargo, las políticas más modernas tienden a preferir que cada usuario disponga de una llave cifrada para cada instancia remota, de forma de poder "zafar" si una de las llaves se pierde o es comprometida.
En dicho caso, elevar el número de intentos permitidos por encima de un valor más alto (por ejemplo, 20), podría resultar más provechoso.
Para realizar tales cambios, en el servidor editamos el archivo de configuración. Por ejemplo, podremos hacerlo con GNU Nano introduciendo:
sudo nano /etc/ssh/sshd_config
Habrán de presionar Ctrl+w para buscar la variable MaxAuthTries. Una vez que la encontramos la descomentamos eliminando el signo # que la antecede, y elevamos el valor de la variable del 6 original a uno adecuado según la cantidad de llaves (por ejemplo, 20).
Es importante tener en cuenta que esto no implica que "se da un cheque en blanco a probar llaves" sino que se autoriza que cada usuario pruebe dicha cantidad de veces.
Para que el cambio surta efecto, debemos reiniciar el servicio de SSH ingresando:
sudo systemctl restart sshd
Naturalmente, podrán contemplar también otras técnicas recomendadas para asegurar un servidor de SSH.