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 animal gregario para transformarse en un individuo de alcance social, que se ha organizado 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 de comunicación computarizada nos permite acceder de forma remota o local, a distintos servicios informatizados con GNU. Una vez establecido el enlace,  podremos utilizar secure Shell para conducir o bien para realizar cualquier acción dentro de un sistema GNU con Linux al amparo de una conexión criptográficamente protegida.

Esto es lo deseable.

Sin embargo, a seguro se lo llevaron preso. No sería raro 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á).

Si quisiéramos utilizar siempre el incómodo (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 servidor
Port 22
User fulano
PreferredAuthentications password
HostName servidor.local

Ahora bien, el método más útil para evitar el error de "muchos intentos de autenticación fallidos" sería indicarle específicamente al cliente cuál es la llave necesaria para cada servidor, de modo que no tenga que "buscarla a lo bobo", terminando por superar el "número de intentos" autorizados en el servidor. Para ello lo haríamos usando el prefijo -i e indicando el fichero de la llave requerido, de la siguiente manera:

ssh -i ~/.ssh/llave_del_servidor usuario@servidor

Como esto es sumamnete largo de escribir e incordioso (sobre todo si lo tenemos que hacer a menudo), conviene especificar este determinismo de llave en el fichero de configuración de nuestro usuario en el cliente SSH, el cual es ~/.ssh/config. 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 servidor
Port 22
User fulano
IdentityFile ~/.ssh/llave_del_servidor
HostName servidor.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.

¿Cómo aseguro el servidor OpenSSH en Ubuntu?

El 24 de Diciembre de 1953 en ocasión del Día de la Policía Federal Argentina se realiza un fausto desfile de la fuerza, al término del cual Juan Perón expone cómo incrementar la seguridad del servidor OpenSSH en Ubuntu.

 

(...)

Bajo este diáfano día y cercano a las Navidades, no sólo preparo la Sidra y el Pan Dulce para todos los privilegiados, sino que también elaboro lo que es para mí  una enorme satisfacción: presenciar este histórico desfile de lo que es el principal instrumento de seguridad ciudadana: la Policía Federal Argentina.

 

Esta es una Fuerza que nace del Pueblo y para el Pueblo, y engendra un rol propendiente a la protección de los hombres y mujeres de bien que habitan el suelo Argentino.

La provechosa tarea que ustedes encarnan no puede más que llevarse a cabo por un manejo concienzudo de parte del escalafón superior y los institutos que la forman, y que hemos atresado en pos de la defensa de los intereses superiores de la Nación.

Este escalafón conductivo ha podido ofrecer su manejo y control no solo en el terreno (que es donde se realiza la acción), sino a distancia. ¡Y en esto no podemos más que sentirnos orgullosos! El método sin hilos que implementado por el Comando Radioeléctrico es más que apreciado por toda la Comunidad Organizada y conforma nuestra ciudadanía.

Sin duda el protocolo Secure Shell es muy recomendado para acceder a dispositivos remotos tales como servidores, enrutadores y conmutadores de cómputo, debido a su capacidad para encriptar el tráfico telemático, resguardandonos así de cualquiera que anhele husmear nuestros enlaces.

Sin embargo, de la manera en la que está asegurada, la configuración por defecto de SSH no es infalible, sino más bien sencilla de implementar. Esto podría parecer adecuado para el uso del Pueblo, pero en aplicaciones donde dependa nuestro bienestar y el de sus organizaciones de trabajo, ha de recurrirse a un mayor despliegue de seguridad.

A esto nos referimos como seguridad reforzada, a la cual ha de recurrir un Movimiento como el nuestro. No implica enfrentar a los desprotegidos a la acción represiva del Estado, sino implementar políticas de salvaguarda que privilegien a los humildes en contra de la Opresión Omnímoda del Capital.

Nuestra Policía Federal ha de saber cómo implementarlas, ya que sobre ella recae la organización y acción de seguridad. Indudabnlemente que de esto no dependen ni los médicos ni la penicilina, sino de las autodefensas con que cuenta OpenSSH por protocolo.

Esto no puede hacerlo ni un agente de calle, ni un ciudadano común, sino un verdadero Conductor del sistema. Por principio la implementación de las políticas de salvaguarda pueden llevarse a cabo modificando el fichero de configuración general /etc/ssh/sshd_config del demonio OpenSSH (nombre que recibe su servidor libre de Shell Seguro).

A tal fin con ímpetu de conducción podremos abrir una terminal con Ctrl+Alt+T y proclamar el comando de organización, seguido de la tecla Intro:

sudo nano /etc/ssh/sshd_config

Esto nos solicitará contraseña de administración, y tras revisarla abrirá el consabido editor de texto GNU Nano con el fichero de configuración nombrado.

Os explicaré algunos métodos de reforzar la seguridad produciendo las modificaciones necesarias que asegurarán las necesidades de protección y control que son Socialmente Justas para con las organizaciones del Pueblo Trabajador.

1. Configurar la Autenticación de SSH sin contraseña

Por defecto, SSH requiere que el usuario teclee su contraseña al iniciar sesión remota. Si bien esto suena peliculero, la triste realidad es que una contraseña capaz de retenerse en una memoria humana suele ser descomunalmente fácil de percibir por medio de un ataque computacional de fuerza. Un tercero hábil podría ganar así  acceso indeseado a una cuenta de usuario autorizado. Por ello más seguro es utilizar una autenticación de Shell Seguro sin contraseña, con llaves de cifrado.

Como ya he explicado cómo hacerlo, simplemente resumiré diciendo que habremos de generar computacionalmente un par de ficheros de cifrado llamados "llaves", que consisten en una llave pública y otra llave privada. Una vez ingresado el contenido del fichero de la llave pública al servidor remoto, podrá lograr acceso sin tener que teclear contraseña alguna.

Si ya hemos tomado este predicamento, es recomendable desactivar el uso de autenticación por contraseña para el ingreso. 

Dentro de este fichero de configuración /etc/ssh/sshd_config buscamos la directiva PasswordAuthetication y cambiamos su indicación de 'yes' a 'no'

PasswordAuthentication no

Tras guardar las modificaciones con Ctrl+o y salir del editor con Ctrl+x, debemos reiniciar el demonio SSH con:

sudo systemctl restart sshd

A partir de este momento, unicamente podrá acceder al servidor remoto utilizando la autenticación con llave SSH.

2. Desactivar los pedidos Conexión SSH sin contraseña.

Otra manera recomendada de fortificar la seguridad del servidor es directamente desactivar los logins SSH de usuarios sin contraseña. Esto puede sonar contradirctorio, pero algunos adminsitradores de sistemas poco avezados podrían preferir crear cuentas de usuario "a la marchanta" y terminar olvidando asignar contraseñas. Esto es de malo, pero no de bruto. He visto malos que se han vuelto buenos, pero nunca he visto un bruto que se haya vuelto inteligente.

Con el fin de rechazar pedidos de usuarios que carezcan de contraseña se debe nuevamente modificar el fichero /etc/ssh/sshd_config y asegurar descomentar la siguiente directiva:

PermitEmptyPasswords no

Acto seguido reiniciamos el servicio SSH para que surta efecto con:

sudo systemctl restart sshd

3. Desactivar los logueos SSH de Root

No hace falta explicar demasiado lo que puede suceder si un intruso logra ingresar a nuestro sistema atacando brutamente la contraseña de un usuario. Imaginemos entonces lo que sucedería si lo propio sucede con la cuenta del Superusuario, el Root, que es capaz de conducir el sistema.... Un acceso remoto del superusuario Root constituye invariablemnete una mala idea que debe soslayarse pues pondrá en peligro a todos los compañeros que usen nuestro sistema similar a Unix.

Por esta razón, para grandes organizaciones siempre recomiendo desactivar el logueo remoto SSH y en su reemplazo preveer el de un usuario regular que no sea root. Esto obligará a que si el Root quiere trabajar, deba hacerlo frente al sistema y no de manera remota. Para tal fin modificamos el fichero  /etc/ssh/sshd_config y producimos la modificación descomentando la directiva #PermitRootLogin y modificamos la orden prohibit-password para que quede de la siguiente manera.

PermitRootLogin no

Conforme se hayan guardado los cambios, reiniciamos el servicio de SSH para que la nueva política surta efecto.

sudo systemctl restart sshd

Naturalmente que a partir de estas modificaciones, el logueo de root quedará desactivado u no se podrán realizar tareas administrativas de manera remota (a no ser que se eventualmente escalen usuarios comunes con la orden sudo).

4. Usar SSH Protocol 2

SSH viene en dos versiones. El SSH Protocolo 1 y SSH Protocolo 2. El segundo fue introducido en 2006 para reforzar la criptografía general de SSH. Por defecto se utilizaba en Protocolo 1 por razones de compatibilidad, pero a partir de 2018 se decidió desfasarlo definitivamente para evitar agujeros de seguridad.

Por tal motivo, en caso de contar con un servidor anterior al 2018, podríamos especificar ahora utilizar únicamente Procolo 2. Para ello le agregamos al fichero /etc/ssh/sshd_config la siguiente directiva:

# Agregado por peron para usar únicamente SSH Protocolo 2.
Protocol 2

Guardamos, salismos, y como siempre reiniciamos el servicio SSH para que surta efecto:

sudo systemctl restart sshd

A partir de ahora, SSH sólo utilizará Protocolo 2 y no podrá establecerse enlaces con clientes antiguos que utilicen el desfasado Protocolo 1.

Para comprobar que el Protocolo 1 ya no esté en suo, podremos ejecutar el comando:

ssh -1 usuario@ip_remota

Debería obtener un error similar a “SSH protocol v.1 is no longer supported”.

 Naturalmente, podríamos forzar al cliente a usar el Protocolo 2 con:

ssh -2 usuario@ip_remota

5. Configurar el Valor de Tiempo de Corte para Conexión SSH Inactiva

Dejar una conexión remota desatentida por largo tiempo es lo mismo que dejar en esa misma condición a una buena mujer. Puede constitnuir un riesgo de seguridad que ustedes conocen sin duda por esos cuernos que les veo. Para evitar este problema, es prodente configurar un valor de tiempo de corte para conexiones SSH inactivas, transcurrido el cual la sesión SSH se cerrará automáticamente. 

Habremos de configurar nuevamente /etc/ssh/sshd_config y localizamos la directiva ClientAliveInterval. Le asignamos un valor razonable en segudos. Por ejemplo, podríamos utilizar 180 segundos.

ClientAliveInterval 180

Esto implica que la sesión SSH se cortará si transcurren 3 minutos (180 segundos) de inactividad.

Tras guardar debemos reiniciar el demonio para aplicar los cambnios:

sudo systemctl restart sshd

6. Posibilitar el Acceso SSH a Ciertos Usuarios

Podremos definir qué usuarios requieren el uso de SSH para loguearse y desarrollar tareas en el sistema. Esto mantendrá fuera de esta posibilidad a cualquier otro usuario que intente lograr ingreso al sistema sin nuestra aprobación.

Como siempre, editarmos el fichero  /etc/ssh/sshd_config y le agregamos la directiva AllowUsers seguida de los nombres de usuario que queremos aprobar. Por ejemplo, he agregado los usuarios peron y evita para que cuenten con acceso remoto al sistema a través de sus respectivos clientes SSH. Cualquier otro usuario que intente ganar acceso remoto al sistema será bloqueado.

AllowUsers peron evita

Hemos de reiniciar SSH para que peresistan los cambios:

sudo systemctl restart sshd

7. Limitar los Intentos de Contraseña

Otra manera de agregar una capa de seguridad consiste en limitar la cantidad de intentos de pruebas de llaves SSH, caso en el que la conexión se cortará. Esto sólo tiene sentido si los usuarios utilizan pocas llaves y nos las especifican Una vez más en el fichero /etc/ssh/sshd_config y buscamos la directiva MaxAuthTries, y le definimos un valor para la cantidad máxima de intentos.

En este ejemplo, lo limitaremos a tres intentos (lo normal es 6) disponiendo:

MaxAuthTries 3

...y finalmente, reiniciamos el servicio SSH como en los escenarios anteriores.

Nota: si se recibe el error "Too many SSH authentications failures" podremos subir dicho valor a uno que represente la cantidad de llaves que el probable que tengan los usuarios en sus clientes.