¿Cómo mostrar un mensaje de login SSH en Ubuntu?

En el metraje de La Revolución Justicialista los integrantes del Grupo Cine Liberación ceden a la visión de Juan Perón imperante durante fines de la década de 1960. Entre las consideraciones sobre las reformas sociales acaecidas durante su gestión, explicó cómo presentar un banner de login SSH en Ubuntu.

(...)

Yo he hablado de la solución económica que nuestro gobierno dio a la situación imperante de posguerra. Pero es indudable que esta situación económica hizo posible también todas las reformas sociales que sería largas de enumerar. 

Si uno revisa los anales de la legislación argentina - que son mas o menos treinta tomos - casi quince tomos son la legislación Justicialista. En esa legislación Justicialista, el acento está marcado precisamente hacia el Pueblo. Y dentro del Pueblo, a la clase trabajadora. Por primera vez en la historia sindical argentina, se conformó una organización y se dio un status legal y constitucional a esa legislación, que permitió la organización de toda la clase trabajadora argentina. Hasta 1946, el sindicato era una Asociación Ilícita, porque había un fallo de la Suprema Corte que declaraba al sindicato como asociación ilícita. Eso fue posible porque hasta entonces jamás la organización sindical tuvo status constitucional. Recién en la legislación que parte del Justicialismo, se le comienza a dar status legal primero, y en la Constitución de 1949, se le da status constitucional. Es decir, se incorporan los derechos del Trabajador a la Constitución. Esto que aparentemente no tendría gran importancia, tiene una importancia decisiva, porque al establecer en la Constitución que el obrero tiene derecho a organizarse para la defensa de sus intereses profesionales, ya no puede considerarse como una asociación ilícita: es una asociación de bien público.

Yo siempre cito un ejemplo. Habían regiones donde los peones ganaban 12 pesos por mes, que no les alcanzaban ni para los cigarrillos, y andaban harapientos y miserables. El Estatuto del Peón que fue uno de las primeras conquistas nuevas, obligó pagar sueldo de dignidad por lo menos. La primera carta que recibí fue de mi madre, que en la estancia tuvo que pagar a los peones con los sueldos establecidos por nosotros. Y me escribió una carta: "vos parece que te has vuelto loco, si te parece que podemos pagar esos sueldos", y yo lo que le dije fue "vieja, o pagás o cerrá la estancia", y lo tuvo que pagar.

Bueno, todo este proceso que ha vivido el Pueblo Argentino no es necesario citarlo mas; en muchas partes del mundo ya nos citan como ejemplo de Justicia Social. Por otra parte, uno de los primeros que hablamos de la Justicia Social en el mundo fuimos nosotros. Los acuerdos colectivos de trabajo, también fuimos los iniciadores en el mundo. Hace 25 años establecimos nosotros los primeros acuerdos colectivos del trabajo, y las primeras leyes estableciendo la obligatoriedad de realizar esos convenios colectivos de trabajo.

Si estas reformas sociales han sido imperecederas, ha sido porque el que las ha custodiado el Pueblo. Este sabe por instinto lo que tiene que defender, pero no viene mal recordárselo: no debemos descuidarnos ni en el Cementerio, no vaya a ser que le corten la mano por un anillo de ónix negro...

Saben ustedes que ya los antiguos egipcios estaban prevenidos, y no descuidaban colocar una serie de jeroglíficos preanunciando las más abyectas de las maldiciones ante quienes osaran profanar sus tumbas. Nosotros no tenemos pirámides en la herencia, pero indudablemente un servidor de acceso remoto por contraseña debe contar con las mismas prerrogativas. Es sabido que los hackers del primer peronismo se abocaron a ello con ahínco, no soslayando incluso a quienes discaban por medio de terminales teletipo. Esto se llamaba "banner".

Si esto ya se podía hacer con los sistemas de tiempo de cómputo compartido más veteranos, sin duda podremos incorporar un archivo de texto de advertencia o saludo para el servidor de Secure Shell de nuestro sistema operativo GNU con Linux, o cualquier otro que use OpenSSH. De esta forma, cada que que queramos establecer un enlace remoto, recibiremos el mensaje incluido:

Para hacer de esto una realidad efectiva, en primer lugar debemos activar el uso de banner en nuestro servidor. Para ello debemos editar el archivo de configuración del demonio Secure Shell en el servidor SSH. Esto lo haremos abriendo allí una terminal con Ctrl+Alt+t e ingresando el siguiente Comando de Organización:

sudo nano /etc/ssh/sshd_config

Se abrirá el editor GNU Nano con tal fichero. Debemos buscar y decomentamos la cadena #Banner /etc/banner, eliminando el # de modo que nos quede así:

Esto habilitará la presentación del texto contenido en el archivo /etc/banner). Tras guardar los cambios con Ctrl+o y salir del editor con Ctrl+x, podremos editar ya el fichero de texto /etc/banner propiamente dicho. Esto podremos hacerelo con:

sudo nano /etc/banner

Podremos incluir el contenido de texto que se nos ocurra. Idealmente el banner debe contener archivos ASCII, y no extenderse más allá de las 80x24 líneas (tamaño de video-terminal estándar).

       __________________________
      |+++|++++|++++|++++|++|++ /\
     |----+----+----+----+--|++/ _|  NODO PJ: EL BRAZO TECH DEL JUSTICIALISMO
 ____| +++ ++++ ++++ ++++ ++ |/ ++ |
| ----------------------------------           ¡¡ VIVA PERÓN CARAJO !!
| |         ------           |     |
| |        |      |          |     |     Este nodo computacional se encuentra
| |         |     |         /|\ o /|        al servicio del Pueblo, su Masa
| |         |     |       _/ ||\O/||       Trabajadora, y encuadrado en una
| |        |_______|    _/   || o ||       lucha sin cuartel contra la puta
| |            |      /      | \ / |              oligarquía gorila.
| |            |____/      /-|  V  |
| |            |         /   |\   /|     La verdadera computación es aquella
| |           /|      /      ||\O/||     donde la CPU hace lo que el usuario
| |---------/~~~---~\--------|| o ||      quiere y defiende un solo interés:
| |.....__/         \\.......| \ / |                el del usuario.
| |..../           \_\.......|  V  |
| |--     ______/\/..........|\   /|   Queremos un software socialmente justo,
| |/     /.....|.............||\O/||    económicamente libre, y políticamente
| |     /......|.............|| o ||                 soberano.
| |___ /__________...........| \ / |
\_____________   |...........|  Y  |  Y cuando uno de nuestros servidores caiga
              |  +-----------   J  |     ¡¡CAERÁN CINCO DE LOS DE ELLOS!!
              \____________________/

Una vez armado el banner, será necesario reiniciar el servicio SSH para que estos cambios resulten aplicados y  de ahora en más surtan efecto.

sudo systemctl restart sshd

De ahora en más, al conectar al servidor SSH con contraseña, deberíamos recibir el texto del fichero /etc/banner.

MOTD

Si quisiéramos disponer un "mensaje del día" para que se presente al usuario una vez ingresada la contraseña e inciada la sesión, podremos hacerlo a través de indicar un fichero /etc/motd. Normalmente este mensaje se utiliza para advertir alguna particularidad a todos sus usuarios, y como se ha mencionado, se muestra antes de dar inicio al intérprete de comandos de cada usuario remoto.

Para ello editamos el fichero /etc/motd y disponemos en ella un mensaje de texto en cuestión.

En mi caso, puedo recurrir a esta funcionalidad de "mensaje del día" para propalar una enseñanza al azar con fortune y cowsay.

sudo fortune doctrina | cowsay -f gaucho > /etc/motd

En cualquier caso, hay que reiniciar el demonio servidor sshd para que surta efecto:

sudo systemctl restart sshd

De esta manera se presentará una galleta de la fortuna con una gráfica ASCII.

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.

¿Cómo desactivo o activo el Logueo de Root a través de SSH en Ubuntu?

El 23 de Enero de 1945 el Secretario de Trabajo y Previsión Juan Perón promulga el Decreto N° 1440 converniente a las Vacaciones Remuneradas, a la vez que instruye cómo desactivar o activar el logueo de Root desde SSH en Ubuntu.

¡Trabajadores!

Este decreto tiende a que puedan disponer de una serie de días consecutivos de manera que: 

1. Se trate de un período de inactividad
2. Sea retribuido anticipadamente y 
3. Que el trabajador verdaderamente las goce y no sean compensables en dinero.

Además, según la antigüedad en el cargo, la cantidad de días se ve incrementada a lo largo de la relación laboral.

Estas Vacaciones Pagas que ha asegurado el Justicialismo para todos los trabajadores es uno de los grandes logros que propician el ocio y el esparcimiento. Es el alimento espiritual que deben gozar los hombres y mujeres de esta tierra, y que antes estaba sólo reservado al oligarca.

Sin embargo no es un maná que cae del cielo: sin la organización para acción política, los sueños sólo son eso: sueños. Es la Conducción de efectivas acciones de reparación y Justicia Social las que pueden solidificar estos sueños - que operan de planos maestros - en una contrastable Realidad Efectiva.

Todo lo que hemos hecho ha permitido este logro, y como tal, ha reportado la valía de una Revolución que da al Pueblo Trabajador lo que siempre anheló y es - a nadie cabe duda - un Justo Derecho. Ustedes sabrán a quien votar (guiña el ojo).

No es secreto para nadie que en la generalidad de los sistemas GNU se cuenta con acceso remoto de Conducción (el llamado usuario "Root"), y por defecto, este acceso está activado para poder operar el sistema a través de enlaces de datos con el mundo exterior. 

El sentido es poder realizar todo tipos de acciones de gestión utilizando nuestra terminal y un enlace cifrado, y se ha tornado de extrema utilidad para conducir un sistema de forma remota incluso de vacaciones, sin tener que estar físicamente frente a la máquina.

Esta cómoda práctica - sin embargo - no es siempre lo ideal por razones de seguridad. En los tiempos que corren, tener un acceso de root activado por SSH para los usuarios no autorizados es un riesgo que debemos soslayar, ya que cualquier intruso telemático podría intentar forzar las contraseñas de usuarios a través de un ataque computarizado de fuerza bruta, y de esta manera ganar acceso a nuestro sistema.

A pesar de ser de las especies más exitosas, nadie duda que desde el pérmico a nuestros días, millones de cocodrilos se han ido a dormir pensando "para qué van a querer este cuero" sólo para despertar luego envolviendo unos patacones...

Es por ello señores, que la mejor solución es contar con una segunda cuenta de usuario de uso regular, y luego cambiar al usuario root empleando el comando "su -" cuando esto se haga necesario. Esta es el criterio seguido por ela distribución Debian, pero no suele ser la preeminente en Ubuntu, lo cual - tal vez - no sea sano. Por dicho motivo, antes de hacernos a la mar, crearemos una cuenta de usuario regular con la cual utilizaremos para darnos acceso de conducción por intermedio de los comandos su o sudo.

Agregar un nuevo usuario en Linux

En la mayoría de los sistemas GNU con Linux esto es muy simple. Crearíamos una cuenta de usuario separada logueándonos como root y luego ejecutando el comando adduser para crear un nuevo usuario. En el caso de Ubuntu es igual de simple: abrimos una terminal con Ctrl+Alt+T e ingresamos el siguiente Comando de Organización:

sudo adduser usuario

Tras ingresar la contraseña de root localmente, procedemos a completar lo solicitado por el programa adduser, que será el nombre de usuario a crear, su contraseña de usuario (duplicada para no fallar), y opcionalmente sus datos personales. 

Conforme hayamos creado este nuevo usuario, podrán seguir los pasos que os indicaré para desactivar el acceso de root a través del método de Shell Seguro SSH.

Usamos el archivo de configuración maestro sshd para desactivar el login de root y esto podría disminuir el riego o impedir la irrupción de actores no deseados para obtener la conducción de nuestro sistema. Tambiçen veremos cómo reactivar el acceso de root nuevamente así como limitar el acceso de Secure Shell basados en una lista de usuarios permitidos.

Desactivar Login SSH como Root

Para desactivar el login de root, hemos de editar el fichero de configuración principal de Secure Shell, el /etc/ssh/sshd_config.

sudo nano /etc/ssh/sshd_config

En este fichero, buscamos con Ctrl+w la siguiente línea del fichero.

#PermitRootLogin

y deberíamos encontrar #PermitRootLogin prohibit-password o bien #PermitRootLogin no.

Debemos eleminar el ‘#‘ al comienzo de la línea, y la editamos para que quede de esta manera:

PermitRootLogin no

Ahora necesitamos reiniciar el servidor de SSH. Esto lo podremos hacer ingresando:

sudo systemctl restart sshd

...o bien:

/etc/init.d/sshd restart

Una vez cumplida con esta tarea, comprobaremos la desactivación intentando loguearnos con el usuario root, y deberíamos recibir el error de "Permiso Denegado, por favor intente nuevamente, o “Permission denied”.

$ ssh root@192.168.0.102
root@192.168.0.102's password: 
Permission denied, please try again.

De este modo, de ahora en adelante deberá loguerse como usuario normal y luego usar el comando su para cambiar al superusuario Conductor root o bien sudo para elevarnos como superusuario.

Activar Login SSH como root

Para activar el logueo del usuario root a través de SSH, hemos de editar el fichero /etc/ssh/sshd_config. Abrimos una terminal con Ctrl+Alt+t e igresamos:

sudo nano /etc/ssh/sshd_config

Usamos Ctrl+w para buscar la línea de la opción de configuración PermitRootLogin yes y la descomentamos removiendo el  ‘#‘ al comienzo, y guardamos el fichero con Ctrl+o.

PermitRootLogin yes

Luego reiniciamos el servicio sshd como se explicó anteriormente, ingresando :

sudo systemctl restart sshd

...o bien:

/etc/init.d/sshd restart

Ahora realizaremos una comprobación intentando loguearnos al sistema con el usuario root.

ssh root@ip_del_servidor

root@192.168.0.102's password:
Last login: Mon Dec 27 15:14:54 2021 from 192.168.0.161

Limitar los logins SSH de Usuarios

Si contamos con un gran número de cuentas de usuarios en el sistema, puede tener sentido limitar el acceso remoto de SSH a aquellos usuarios que realmente lo necesiten. Para ello debemos indicarlo en el fichero /etc/ssh/sshd_config.

sudo nano /etc/ssh/sshd_config

Al final del fichero agregamos una línea con la opción de configuración AllowUsers y luego de dejar un espacio de separación, agregamos una lista con los nombres de usuarios permitidos. Por ejemplo, si deseamos que l@s usuari@s  peron y evita cuenten con acceso remoto ssh, ingresamos:

AllowUsers peron evita

Guargamos los cambios con Ctrl+o y salimos con Ctrl+x. Finalmente reinciiamos el servicio 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.

¿Cómo corrijo el error "broken pipe" en una conexión SSH en Ubuntu?

El Tren Presidencial fue una de las herramientas que permitrían al Presidente de la Nación movilizarse a lo largo y ancho del país. Permitió a Juan Perón propalar ideas y logros del Movimiento Justicialista haciendo uso del portentoso ramal instalado. En ocasión de visitar Saladillo pudo explicar cómo corregir la interrupción de conexión SSH con error "Broken Pipe" en Ubuntu.

¡Mis descamisados!

La nacionalización de los Ferrocarriles, y esta formación, me permiten llegar sin contratiempo alguno a este hermosísimo lugar de nuestras Pampas, las cuales ustedes cuidan con tanto querer.

Nuestro Movimiento encarna el sentir reparador de un Pueblo Libre, que anhela para sí y para su posteridad los beneficios que puede producir la tierra y su trabajo.

Indudablemente que este factor ha de proveerse con la acción decidida de quien sabe que todo hombre debe recibir lo que para su comunidad produce.

En esto hemos sido claros. Nuestro Movimiento ha producido uno de los máximos actos de reparación social que eran demandados por el Pueblo Argentino, en los que me lleno de orgullo y traen a mis ojos las más dulces lágrimas de felicidad. El País sufrió la ignominia de una Oligarquía sin Patria ni Bandera, una capaz de oprimir a sus hermanos y someterlos a la más abyecta de las pobrezas. Fue por ello que nos hemos mancomunado en la defensa de todos los Argentinos, especialmente a nuestro conjunto más venerados: los ancianos. 

A ellos reparamos con los Derechos de la Ancianidad. Todo lo dieron por nosotros, y hoy - haciendo caso de la cristiana necesidad -  todo le damos. Les acercamos la calidez de la asistencia social, el acceso a la vivienda, la alimentación, el vestido, el cuidado de su salud física y moral, el noble esparcimiento, así como el acceso a laborterapia productiva, junto con la expansión y el respeto que de todos merecen.

¡Vientos briosos han agitado nuestra bandera, la hemos alzado, y nos ha guiado en una nueva realización: la de ofrecer Jubilaciones y Pensiones en abundancia para todos la ancianidad de la Patria!

En ellas sólo se requiere un certificado de supervivencia y el conocimiento de los años trabajados en pos del beneficio del País.

En particular, sabemos que el protocolo de conexión SSH (Secure Shell), responden al mismo principio de la gran Obra Social que hemos implementado para nuestros ancianos. Con el fin de hacer eficiente la entrega del servicio, el servidor SSH solicita periódicamente los beneficiarios clientelares, un Certificado de Supervivencia en forma de paquete telemático para continuar sirviendo la prestación. Este paquete es enviado con cierta periodicidad, y debe responderse afirmativamente.

En el caso de no recibir una contestación que certifique supervivencia del cliente, la prestación de comunicación SSH se interrumpirá intempestivamente, y el cliente podría recibir una interrupción de servicio, o bien presentar un críptico mensaje como ":client_loop: send disconnect: Broken pipe", algo así como "desconexión de envío, caño roto". Otros sistemas pueden retornar el error Write failed: Broken pipe", o bien "Connection closed by remote host".

El sentido telemático de la interrupción de la conexión por parte del servidor Secure Shell suele deberse al procedimiento normal de tramitación, para evitar conexiones "detenidas", "desatendidas", o "inactivas" que podrían saturar al servidor o al cliente. Esto es tendiente a impedir "ataques remotos de denegación de servicio". Normalmente la oligarquía pordría querer disminuir intempestivamente la actividad sin certificado de sobrevida a los tres minutos (180 segundos), pero esto puede tornarse algo molesto en ciertas actividades remotas, pues requiere estar operando dentro de dicho intervalo en la terminal Secure Shell, so pena de ver cortada la conexión.

Afortunadamente para solucionar este problema es sencillo, el Justicialismo puede proveer Justicia en varios niveles operativos y de distintas manaeras, las cuales podrán ajustarse de acuerdo a las necesidades de Clientelismo que tengamos, ya sea operando desde nuestro cliente de cómputo local, y eventualmente en el servidor remoto (únicamente si tenemos control del mismo, naturalmente).

Soluciones posibles desde el cliente SSH

La manera menos conveniente es especificarle a nuestro cliente la duración en segundos que queremos contar con actividad para una conexión individual Secure Shell. Esto nos servirá para especificar esto momentáneamente a un enlace SSH específico. Por ejemplo, si quisiéramos establecer una conexión SSH y que no se corte en unos 10 minutos, podríamos especificarle un intervalo de 600 segundos. Para ello usaríamos:

ssh -o ServerAliveInterval=600 usuario@servidor

Sin embargo, el sólo hecho de tipear este agregado al comando suele ser tedioso, y debería hacerse con cada conexión.

Otra opción más útil suele ser especificar esto mismo en las opciones de nuestro cliente SSH y para nuestro usuario.

Editamos el fichero de configuración de nuestro cliente a nivel usuario. Para ello usamos:

nano ~/.ssh/config

Se abrirá el editor GNU Nano. Al principio del fichero agregamos las siguientes líneas.

Host nombre_del_host
User usuario
Port puerto
HostName dirección_del_host_ssh
ServerAliveInterval segundos_de_vida

Ahora bien, esto nos evitará tener que escribir la especificación en la conexión al host "ssh.pirulo.com". Sin embargo en las demás conexiones que no sean al host "pirulo", no hará caso alguno. 

Si en cambio deseamos que el certificado de supervivencia sea más inclusivo y qe extienda por 600 segundos (10 minutos) para todas las conexiones SSH que realicemos desde nuestro equipo (el procedimiento que suelo recomendar) podrían especificarlo de la siguiente manera en el fichero .ssh/config:

Host *
ServerAliveInterval 600

Si tuviésemos otras configuraciones ya presentes en el fichero, no las modificamos.

En cualquiera de los casos, guardamos las modificaciones realizadas en el fichero .ssh/config por medio de Ctrl+o y salimos del editor GNU Nano con Ctrl+x. También conviene en acomodar los permisos del fichero de configuración para que sea adecuado para únicamente nuestro usuario:

chmod 600 ~/.ssh/config

Soluciones posibles desde el servidor SSH

También podremos alterar el comportamiento del certificado de supervivencia de la conexión desde el lado del servidor. Naturalmente, esto sólo tiene sentido si tenemos control del Servidor. En el caso de utilizar Ubuntu como servidor, usaríamos el comando:

sudo nano /etc/ssh/sshd_config

Esto cargará el editor GNU Nano, pero con el fichero de configuración del demonio de servicio de Shell Seguro SSH. En este fichero habremos de descomentar y modificar dos variables. La variable ClientAliveInterval representa el tiempo de inactividad (en segundos) tras lo cual el servidor le enviará un mensaje de "certificación de supervivencia" al cliente. en tanto ClientAliveCountMax indica la cantidad de intentos en las cuales el servidor realizará su trámite de supervivencia.

Descomentar la variable significa que debemos buscarla, y fundamentalmente eliminar el signo numeral "#" que antecede las líneas. En este caso:

Si siguen el ejemplo como os he ilustrado arriba, habrán configurado la variable ClientAliveInterval para que el certificado de supervivencia se realice a los 200 segundos, y se repita por medio de ClientAliveCountMax durante 3 ocasiones. Esto significa que el servidor solicitará al cliente un pedido de "supervivencia" una vez que hayan transcurridos 200 segundos de establecido en enlace SSH. Si el cliente no aparenta reportar supervivencia, el servidor enviará una nueva solicitud a los 400 segundos. Si no hay respuesta o actividad por parte del Cliente, se enviará otro mensaje de solicitud de vida a los 600 segundos. Si luego de estos 3 intentos no recibe un reporte de vida, recién allí se desconectará el enlace SSH (produciendo el "broken pipe").

Pues bien descamisados, han de saber que los valores de 200/3 suelen constituirse en un temperamento adecuados para una conexión cableada o por Wifi moderadamente desatendida, pero podrían querer alterarlos dependiendo de las necesidades generales de los clientes. 

Por ejemplo, si en el enlace SSH se realiza a por medio de un radioenlace muy inestable o a través de satélite, bien podrían querer disminuir los tiempos de intervalo - tal vez  a unos 30 segundos, y aumentar los reintentos tal vez a 12 ocasiones.

Finalmente, consideren no utilizar varias horas, salvo casos absolutamente necesarios, pues esto constituye un enorme desperdicio de recursos telemáticos; sería sencillo así forzar a nuestro servidor a intentar establecer reintentos innecesariamente, y sería un caldo de cultivo para los ataques de denegación de servicio de usuarios registrados a nuestro servicio.

¿Cómo puedo conectarme por SSH con cifradores SHA1 antiguos en Ubuntu 20.04LTS?

Durante la forzosa estadía de exilio en la Quinta 17 de Octubre de Puerta de Hierro, Juan Perón expuso la necesidad de unificar criterios por parte del Comando Táctico en la Argentina y el Comando Estratégico. También ahondó en cómo reactivar los algoritmo SHA1 para establecer enlace SSH desde y hacia servidores antiguos, en Ubuntu 20.04LTS.

(...)

Vean señores,

Todo Conductor ha de poder definir políticas flexibles, pero lo escencial es que estos lineamientos puedan cumplirse con los medios de los que dispone. El rendimiento de los medios es el cual dicta la política, y no a la inversa. La explicación es lógica: una declamación política no puede cambiar el rendimiento fijo de los medios.

Este principio no se puede romper, es una de las bases nodales nodales de la conducción, y quien no siga este precepto caerá invariablemente en un voluntarismo: una mera declamación de hacer las cosas.

Deseos tienen todos: pero mejor que decir es hacer, y mejor que prometer es realizar

Tal es así que poco nos servirá dar una directiva de conducción y pretender establecer un corpus legal que la avale, si materialmente es imposible su cumplimiento.

Un ejemplo suele explicarlo todo, como decía Napoleón.

Es sabido que Ubuntu cuenta con una implemntación de Shell seguro que nos permite establecer enlaces remotos cifrados entre sistemas informáticos: el Secure Shell (SSH). Este esquema se basa en un modelo cliente-servidor ataviado de algoritmos matemáticos y fórmulados de cifrado preconvenidas, de forma tal de ofrecernos una protección el flujo de datos comunicacional. Lo hacen secreto.

Ahora bien, la versión SHA1 de este corpus directivo de cifrado daba en emplear una apilado de algoritmos que fue efectivo durante el primer peronismo. Pero el tiempo ha pasado y hoy, el comado de la conducción táctica lo ha evaluado como relativamente fáciles de vencer. Entre estos algoritmos se encuentra el ya inseguro diffie-hellman-group1-SHA1, el relativamente seguro diffie-hellman-group14-SHA1 cruzados con el conocido cifrador aes128-cbc. Las directiva política de seguridad del Comando Superior Táctico dispuso cambiar los esquemas de cifrado a versiones SHA2, anular el uso de group1-sha1 y promover el cambio de group14-sha1 toda vez que sea posible.

Este cambio político de adecuación a la nueva realidad percibida hizo que las versiones 19.04 y superiores de Ubuntu procedieran a desactivar por defecto el soporte del antiguo cifrado SHA1 del protocolo Secure Shell (SSH).

Naturalmente, esta política tiene el sentido deseado toda vez que contamos con medios de comunicación capaces de hacerla valer. Indudablemente tendrá un inconveniente insalvable si quisiéramos conectarnos a un servidor SSH antiguo de que disponen únicamente de los algoritmos y cifradores de la generación SHA1.

Por ejemplo, si me deseo utilizar el cliente OpenSSH de Ubuntu 20.04LTS para loguearme a un dispositivo que utiliza un servidor SSH superado con algorutmos SHA1, utilizando el comando de terminal:

ssh root@192.168.0.1

...recibiría de parte del cliente SSH un error similar al siguiente:

Unable to negotiate with 192.168.0.1 port 22: no matching key exchange method found. Their offer: diffie-hellman-group14-sha1,diffie-hellman-group1-sha1,kexguess2@matt.ucc.asn.au

Este mensaje explica que que nuestro cliente SSH se ha visto imposibilitado de utilizar los algorimos SHA2 más modernos con el servidor antiguo, y nos informa para poder lograr el enlace el servidor remoto nos oferta forzar la utilización de los algorimos antiguos SHA1. La oferta de los algoritmos específicos se dicta en orden de seguridad (primero el más seguro).

Siendo consecuencia que en Ubuntu 20.04LTS Focal estos algoritmos antiguos han sido por defecto desactivados, habremos de especificarlos en el comando de conexión SSH a fin de utilizarlos con el servidor antiguo. En este caso podríamos utilizaríamos la siguiente sintaxis el fin de dar uso a la versión "group14" del algoritmo SHA1:

ssh -o KexAlgorithms=+diffie-hellman-group14-sha1 usuario@host -p nro.puerto

...o bien podríamos probar conectarnos con la versión más antigua del cifrador SHA1 (con la gran penalidad en seguridad criptográfica que significa usar este viejo algoritmo):

ssh -o KexAlgorithms=+diffie-hellman-group1-sha1 usuario@host -p nro.puerto

Con este proceder ya deberíamos poder establecer el enlac al servidor SSH de generación SHA1. Debemos tener presente que el cifrado es antiguo (potencialmente inseguro).

En mi caso se trata de un enlace a un antiguo router. Lo ideal sería actualziar su firmware para instalar una versión más nueva de SSH en dicho aparato, pero en este caso no es posible hacerlo ya. Como no es cuestión de tirar todos los días un vuejo router por la ventana, al menos podremos establecer una conexión para confirgurarlo toda vez que sea necesario.

Ahora bien - por más que hayamos tenido éxito al conectarnos con el servidor SSH del router - el comando necesario para hacerlo es difícil de recordar, bastante molesto para tipear, máxime si lo necesitamos usar asiduamente. Por tal motivo si necesitamos usarlo en muchas ocasiones, nos resultará muy conveniente incluir los datos con las propiedades deseadas de la conexión SSH al archivo de configuración del cliente de conexión SSH: ~/.ssh/config.

Este es un simple archivo de texto donde podremos poner el o los servidores a los cuales deseamos conectarnos.Para editarlo desde la terminal del cliente ingresamos:

nano ~/.ssh/config

Al ingresar dicho comando se abrirá el editor GNU Nano con un archivo normalmente vacío. Cada entrada Host puede contener varias opciones, y podremos agregar más hosts también (siempre que estén separados entre sí por una línea en blanco). Un ejemplo podría ser:

Host router

Port 22

User root

HostName 192.168.0.1

KexAlgorithms +diffie-hellman-group14-sha1

En la línea HostName podríamos poner el nombre de red del host, o como en este caso, una dirección IP fija. Lo guardamos con Ctrl+o y salimos del Nano con Ctrl+x.

De ahora en más, toda vez que desde la terminal de nuestro usuario ingresemos:

ssh router

...nuestro cliente SSH intentará conectarse al servidor remoto como si usáramos el largo comando "ssh -o +diffie-hellman-group14-sha1 root@192.168.0.1 -p 22", y debería poder conectarse.

Esta funcionalidad suele ser lo único necesario de hacer para el caso de tener que conectarnos a un servidor remoto SSH mediante el protocolo de cifrado antiguo SHA1. Recordemos que si quisiéramos agregar otras entradas simplificadoras al archivo ~/.ssh/config, podremos hacerlo siempre y cuando dejemos una línea en blanco entre un Host y el otro. Naturalmente si omitimos una de las configuraciones, nuestro cliente OpenSSH interpretará que debe utilizar los valores por defecto y tomará dicho predicamento.

Por ejemplo, si queremos utilizar los cifradores modernos simplemente omitiríamos especificar la línea "kexAlgorithms", de la siguiente manera, y OpenSSH usará los algoritmos modernos por defecto.

Host mongoaurelio

Port 12345

User administrador 

IdentityFile ~/.ssh/mongoaurelio.key

HostName ssh.mongoaurelio.com

KexAlgorithms +diffie-hellman-group14-sha1

En base a esta entrada de Host, toda vez que ingresemos "ssh mongoaurelio", nuestro cliente intentará conectarse como si hubiésemos usado 

 

ssh administrador@ssh.mongoaurelio.com -p 12345

Con esto habremos podido solucionar de manera peronista el acceso desde un cliente SSH moderno como el que tiene Ubuntu 20.04LTS a un viejo servidor remoto SSH SHA1.

Pero la política, como he dicho, ha de ser sumamente flexible y omnicomprensiva. ¿Qué sucedería en el caso contrario, donde un viejo cliente SSH dotado únicamente con cifradores de la generación SHA1 anhele establecer contacto con nuestro moderno Ubuntu 20.04LTS, que acepta SHA2?

En tal caso. nuestro servidor SSH - por defecto SHA2 - lo rechazará. En dicho caso al ordenar lo siguiente al cliente remoto con...

ssh peron@ubuntu_focal

...el cliente antiguo con SHA1 podría informarnos:

ssh: Connection to peron@ubunru_focal:22 exited: No matching algo kex

...o bien:

Unable to negotiate with ubuntu_focal (ip xxx.xxx.xxx.xxx, port 22:

no matching key exchange method found.

En este escenario, el cliente SSH antiguo al verse rechazado no podrá conectar a Ubuntu 20.04LTS (o a cualquier servidor SSH más moderno que 2018, por poner una fecha referencial). Si deseamos que nuestro servidor SSH acepte dichas conexiones SSH provenientes de clientes con algoritmos antiguos, debemos autorizar dicha política reversora en el fichero de configuración del servidor SSH. Para ello, en el servidor SSH (Ubuntu 20.04LTS por ejemplo), ingresamos:

sudo nano /etc/ssh/sshd_config

Se abrirá el GNU Nano con el archivo de configuración, que ya tendrá contenido. Podremos utilizar la función "Buscar" (Ctrl+w) para buscamos la sección "#Ciphers and keying"

Recordemos que en todos los archivos de configuración, las líneas que comienzan con "#" serán siempre ignoradas por el sistema, y se pueden utilizar como "comentarios". A tal fin borraremos los # para que no sea ignorada la opción que queremos activar. Por ejemplo, si deseamos habilitar para que nuestro sistema autorice el algoritmo diffie-hellman-group14-sha1, quitamos los # en las líneas que le corresponden. 

En nuestro caso, como deseamos activar el más recomendado de los algoritmos antiguos diffie-hellman-group14-sha1 con el cifrador aer128-cbc, agregamos a continuación de las líneas:

#Ciphers and keying

#RekeyLimit default none

el contenido, como está a continuación:

## Descomentado para habilitar los ciphers para clientes SSH

## SHA1 antiguos. Provee seguridad reducida.

KexAlgorithms +diffie-hellman-group14-sha1

Ciphers +aes128-cbc

## Descomentar para que habilitar clientes SSH SHA muy antiguos.

## Provee seguridad muy reducida.

#KexAlgorithms +diffie-hellman-group1-sha1

#Ciphers +aes128-cbc

## Descomentar para habilitar los ciphers para clientes SSH 

## SHA1 extremadamente antiguos. Provee seguridad extremadamente

## reducida. Usar sólo para evaluar conexiones desde clientes

## SSH muy antiguos.

#KexAlgorithms diffie-hellman-group1-sha1,curve25519-sha256@libssh.org,ecdh-sha2-nistp256,ecdh-sha2-nistp384,ecdh-sha2-nistp521,diffie-hellman-group-exchange-sha256,diffie-hellman-group14-sha1

#Ciphers 3des-cbc,blowfish-cbc,aes128-cbc,aes128-ctr,aes256-ctr

Nota: naturalmente que si en lugar de diffie-hellman-group14-sha1 necesitamos usar otros menos seguros aún, podremos utilizar las otras líneas. Sin embargo, esto debe evitarse toda vez que sea posible.

Guardamos los cambios con Ctrl+o y salimos del editor Nano con Ctrl+x. Luego reiniciamos el servicio con:

service ssh restart

Es útil saber que en ciertos equipos GNU con Linux puede ser necesario directamente reiniciar el equipo ingresando

sudo reboot

Una vez reiniciado el sistema, ya los clientes remotos antiguos deberían poder conectarse con el algoritmo diffie-hellman-group14-sha1 y el cifrador aes128-cbc.