¿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.