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 me conecto a un servidor Secure Shell utilizando llaves cifradas en Ubuntu?

¡Trabajadores!

La nuestra es una Comunidad Organizada, que se ha elevado para proveer a los hombres de esta tierra con la capacidad de reivindicar y defender sus derechos. Entre estos se destacan - junto a los Derechos del Trabajo, de la Niñez y los de la Ancianidad - los Derechos Digitales.

Entre sus grandes valores no debemos soslayar la seguridad y privacidad en los ambientes telemáticos. En un mundo grave donde las comunidades se organizan en ambientes que pueden resultar hostiles, debemos velar especialmente por este aspecto.

Debe de ser un Estado Fuerte y ágil quien asegure a todos tales premisas. Sólo un iluso puede pretender que el accionar de privados, interesados con fines inconfesables, nos otorguen por mágico designio estos principios innegociables. Es el Estado - como principal agente protector de una Comunidad a la que representa - quien puede otorgar estos beneficios. 

Decía el Mariscal de Sajonia que los Ejércitos no valen tanto por su número, sino por el hombre que tienen a su frente. Y esto puede aplicarse a todas las organizaciones. 

Como muestra basta sólo un botón: dejen cualquier grupo de hombres del cómputo al albedrío del Capital, y no tardarán en ver en los transportes telemáticos a analfabetos vendedores con la bragueta abierta que ofrecen pedazos de hardware en una caja. Se creerán dueños del tren, y si los dejan, querrán manejar la locomotora. Este fenómeno no es exclusividad de los tiempos que corren. Cuando Dios mandó a su hijo a ensuciarse las chancletas caminando los desiertos de Judea, fue porque ya en ese entonces existían también estos mercaderes en los Templos. Sólo hace falta un justo flagelar para limpiarlos...

Hete aquí señores que nuestro Justicialismo ha decidido presentar enconada lucha a estas excrecencias, y ofrece hoy una infraestructura del cómputo salvador, capaz de servir a todos bajo la autoridad de un Conductor que se ha formado y capacitado en este quehacer.

Nadie desconoce que en los sistemas operativos multiusuario, el sistema de Shell Seguro (SSH) constituye un factor de singular importancia. En él, lo normal ha sido siempre utilizar las llamadas "contraseñas de acceso" para gran seguridad. No son estas mas que claves secretas capaces de operar para su cometido básico: el de establecer contacto cifrado a un entorno de terminal de cómputo.

Sin embargo, este proceder suele contar con algunos inconvenientes que es necesario sopesar. El primero es lógico, y consiste en la natural obligatoriedad de recordar estas contraseñas si es que deseamos acceder. El segundo implica el compromiso en el cual tales contraseñas pueden caer, llevando a graves inconvenientes de seguridad, y para colmo de forma generalizada.

Para suplir tales deficiencia, nuestro Movimiento ha previsto al Shell Seguro la deseable característica de utilizar el llamado mecanismo de "par de llaves cifradas", en lugar de afectar contraseñas. 

Este cometido en beneficio de todos hube de defenderlo con toda mi autoridad. Consiste en dar uso a dos ficheros de cifrado, uno de los cuales es secreto y permanece en nuestro poder, mientras que el otro que se hace público y es utilizado para la certificación. Obrar así nos permite una comunicación enormemente más segura en las redes de datos.

Para usar este tipo de llaves asiduamente es necesario seguir - por única vez - cuatro paso, el cual instruiré de manera detallada.

Crear un par de llaves de cifrado

En primer lugar habrán de abrir una terminal en vuestro sistema local mediante Ctrl+Alt+T, y crear allí un par de llaves cifradas específicas para tal dispositivo. Esto puede hacerse mediante los siguientes comandos de organización:

cd ~/.ssh/ ;
ssh-keygen -t ed25519

El ordenador presentará un mensaje similar a este:

Generando un par de llaves púbico/privado tipo ed25519.
Ingresa el nombre de fichero para la llave (/home/fulano/.ssh/id_ed25519):

Este mensaje solicita proveer un nombre que identifique los ficheros del par de llaves.

Habrán de introducir entonces un nombre, que puede ser descriptivo para las llaves de cifrado. Háganlo en lo posible sin utilizar espacios, acentos ni eñes. Napoleón fue un hombre que solía decir que un ejemplo podía verter luz sobre todo. En esta ejemplificación, si nos llamamos Fulano y desde el equipo lugar compu1 anhelamos conectarnos  al servidor remoto llamado nodopj.org, bien podríamos utilizar el nombre de llave llave_nodopj_compu1_de_fulano.key.

Se generarán así dos ficheros que conforman las llaves criptográficas, en este caso llamados llave_nodopj_compu1_de_fulano.key y llave_nodopj_compu1_de_fulani.key.pub. Ambos ficheros quedarán a resguardo en una carpeta local denominada ~/.ssh/. Ya no te será necesario volver a crear este par de llaves, al menos en este equipo local.

Revisar la llave pública

En segundo lugar debe revisarse el contenido del fichero que supone la llave pública de este equipo local compu1. Siguiendo el ejemplo que he propuesto, podrían hacerlo con el comando siguiente:

cat ~/.ssh/llave_nodopj_compu1_de_fulano.key.pub

Se mostrará en la terminal el contenido del fichero llave_nodopj_compu1_de_fulano.key.pub que compone vuestra llave pública. Debería presentar una apariencia similar a esta:

ssh-ed25519 EstaEsLaLlaveCifradaYFormaUnaUnicaLineaAlfanumericaQueDebeMandar fulano@compu1

Habrán de asegurarse de copiar este contenido, pues será necesario pegarlo más adelante en el archivo authorized_keys del equipo remoto.

Agregar la llave pública al equipo remoto

En tercer lugar agregaremos la llave pública de nuestro usuario al equipo remoto. Podremos hacerlo con:

ssh-copy-id -i ~/.ssh/llave_nodopj_compu1_de_fulano.key.pub fulano@nodopj.org

En caso de no contar con ssh.copy-id, se debe operar en forma naual. Para tal fin conectarán al equipo remoto nodopj.org por medio de una sesión SSH con contraseña. En este caso propuesto, deberían utilizar:

ssh fulano@nodopj.org

Conforme haya establecido una conexión remota introduciendo la contraseña como siempre, habrán de editar el fichero .ssh/authorized_keys remoto y pegarle el contenido de la clave pública anteriormente copiada. 

Para ello abriremos el fichero con el editor GNU Nano. Utilizaremos el comando:

nano ~/.ssh/authorized_keys

...el cual abrirá el editor.

Han de saber que dentro de este fichero, cada contenido de llave pública va colocada en una línea de texto individual. Pegamos el contenido de la llave pública en el fichero.

Simplemente debe presionarse la tecla Intro para crear una nueva línea, y en esta nueva línea pegar el contenido de la nueva  llave_nodopj_compu1_de_fulano.key.pub. 

Nota: Si se diese el caso que ya existan una o más llaves públicas preexistentes en este fichero, no deben eliminárselas. Sólo deben eliminarse las llaves si se las desea inutilizar. 

Una vez guardados los cambios al fichero mediante Ctrl+o, se puede salir del editor GNU Nano por medio de Ctrl+x.

No suele venir mal modificar los permisos de directorio y fichero adecuados para este servicio de Secure Shell:

chmod 700 ~/.ssh ;
chmod 600 ~/.ssh/authorized_keys

Verificar la configuración

Conforme se haya finalizado el agregado de la llave pública en el servidor remoto, será útil evaluar la efectividad de la conexión con llave. Esto lo verificaremos logueándonos al servidor remoto nodopj.org mediante un comando que especifique manualmente el fichero de la llave. En este ejemplo, desde el cliente compu1 ingresaríamos:

ssh -i .ssh/llave_nodopj_compu1_de_fulano.key fulano@nodopj.org

Deberíamos poder conectarnos al servidor usando la llave, y ahora sin necesidad de ingresar la contraseña. Sin embargo, como este comando es bastante incómodo para escribir asiduamente pues es bastante largo, podremos proceder a configurar el cliente para que establezca en enlace con la llave específica automáticamente.

Configurar el uso de la llave el el sistema local

Para usar la llave sin tener que especificarla en el comando cada vez que desees conectarte, es necesario modificar en el equipo local el archivo de configuración ~/.ssh/config de manera acorde. Para ello en el equipo compu1 debe ingresarse:

nano ~/.ssh/config

...se abrirá el editor GNU Nano con dicho fichero. Al final de todo agrega el contenido que armonice la configuración para el servidor remoto nodopj.org, por ejemplo utilizando un contenido similar a este:

# Llave para nodopj.org
Host nodopj
Port 22
User fulano
IdentityFile ~/.ssh/llave_pirulo_compu1_de_fulano.key
HostName nodopj.org

Conforme esté preparada la configuración para vuestro caso particular, podrán guardarse los cambios con Ctrl+o y abandonar el editor con Ctrl+x. Nuevamente, no es imprescindible pero suele ser muy recomendable introducir a continuación los permisos de directorio y ficheros adecuados en este dispositivo, con el fin utilizarlos asiduamente:

chmod 700 ~/.ssh/ ;
chmod 600 ~/.ssh/config

Todo esto se realizar por única vez.

Conectarse por SSH sin contraseña

Al haber configurado el cliente y el servidor como os he indicado, de ahora en más podrán conectarse al servidor nodopj.org de manera segura y sencilla. Simplemente introduzcan el comando en el equipo cliente:

ssh nodopj

...Y se establecerá el enlace seguro y cifrado con un comando simple de escribir y recordar, y además utilizando la llave en lugar de una contraseña. 

Tengan presente conservar la contraseña en un lugar seguro, pues en caso de necesidad podrá continuar utilizándola para acceder al servidor remoto.

Es adecuado notar que en ciertas ocasiones reservadas a ambientes de seguridad certificada, podrían bien desear omitir el uso de contraseñas, y sólo habilitar el empleo del par de llaves cifradas de acceso. Este proceder puede configurarse así en el equipo remoto. Normalmente no es el temperamento que suelo recomendar, pues deja el acceso a merced de la existencia efectiva del fichero de llave pública.

Nota: Si se diese el caso de contar con otros equipos locales (compu2, compu3, etc) - desde los cuales se hace necesario también acceder asiduamente al usuario del servidor remoto nodopj.org - debe repetirse el paso de creación de un par llaves para cada uno de estos equipos locales. Asimismo, deberán agregarse el contenido de las llaves públicas al archivo de configuración .ssh/authorized_keys sito en el servidor remoto.

En conclusión, el uso de un par de llaves cifradas permite encriptar los enlaces a un servidor remoto, y permiten hacerlo de manera simple una vez configurado todo.