¿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 puedo hacer un respaldo remoto con rsync en Ubuntu?

En 1969 y ante una entrevista para el períodico El Pueblo, Juan Perón expone en los jardines de la madrileña Quinta "17 de Octubre" cómo realizar respaldos remotos a través de SSH utilizando rsync en Ubuntu.

(...)

Con Isabelita nos mantemos actualizados instantáneamente de todo lo que sucede en la Argentina.

Todos los Movimientos replican la biología de los entes vitales que lo componen. En esto nadie tiene asegurado nada y es por ello que - conociendo este cariz inevitable - hemos de prever para proveer. Contar con un plan de contingencia de propia elaboración es la política que nos permite, en la desgracia, salir adelante remozados.

Dejar todo para último momento sólo nos asegurará una costosa improvisación desprendida de nuestros propios instintos, pero no de nuestros intereses razonables, y como tal suelen ser - por remedio - peor que la enfermedad.

Pues bien señores, un sistema GNU con Linux responde más o menos a las mismas directrices, ya que se trata de un sistema nacido en la consolidación de las voluntades informáticas del Pueblo.

En él, suelo normalmente recomendar diseñar una estrategia propia de previsión tendiende a conservar el funcionamiento del entorno y asegurar la preservación perenne de los datos propios, de un punto de vista en el que la  granularidad de la conservación en el tiempo también nos permitan mantener el sistema doctrinalmente actualizado. 

Así he obrado yo, que de esto se un poco, porque como político soy un aficionado, para lo que me he formado toda la vida es para ser un Conductor.

Usualmente es adecuado recurrir a la preservación por redundancia.

En GNU podremos lograrla preservando en medios de almacenamiento adicionales todo el trabajo elaborado y organizado.

Algunos oligarcas han pretendido proponernos como solución aquello a lo que estos vivos denominan "nube", que no es otra cosa que un equipo de cómputo ajeno. Sólo un tonto haría caso a este engaño para depositar sus datos en un servidor remoto que para colmo de males es ajeno y sobre el cual no tiene control real alguno. 

Si la seguridad ha de hacerse de manera remota, más vale que lo sea sobre medios de almacenamiento y equipamiento que se encuentren bajo nuestro exclusivo control. Nadie duda ya que lo más útil en ambientes productivos de gran disponibilidad es contar con múltiples discos duros en una máquina que conoceremos como servidores RAID. Proceder así nos permitirá contar con duplicación, triplicación o incluso cuadruplicación de datos en el mismo momento que se los genera. Este proceder podría parecer exagerado a más de uno, pero es lo que alguien con respeto por su trabajo y dos dedos de frente haría. Al fin y al cabo,  un disco rígido vale chirolas si lo comparamos con la información que resguarda. Por lo demás, contamos ya con sistemas NAT ya hechos, que pensando en este cometido pueden enlazarse a nuestra red LAN, dejando al alcance varios discos SATA de replicación automática.

Sin embargo, incluso podremos hacer respaldos de manera simplificada. Para ello, cualquier sistema GNU puede contar con rsync. Se trata de una aplicación que nos permite sincronizar los datos remotos en un directorio de otro sistema de acceso SSH (ya sea en la red LAN o a través de Internet).

Su sintaxis básica es:

rsync origen destino

Naturalmente, el comportamiento estándar de rsync de copiar y actualizar los ficheros desde el origen hacia el destino replica la necesidad del respaldo de ficheros. En otras palabras, rsync copiará solamente los ficheros nuevos o, en el caso de existir una copia de respaldo previa, sólo aquellos actualizados (modificados) . Al proceder tras este análisis automático, rsync se nos presenta increíblemente útil pues ahorra mucho ancho de banda y acelera enormemente la operación, deslindándose de trabajar ficheros ya respaldados.

Respaldo básico con rsync

Lo que se necesitamos para respaldar un directorio /home de forma remota, es otro sistema destino provista con SSH (y suficiente espacio de disco de destino como para almacenar nuestros ficheros allí), y rsync instalado en nuestro sistema local.

Podríamos querer agregar primero la opción "-n" al comando de rsync mientras preparamos todo y probamos. Esta opción hace que rsync realice una "prueba piloto" ejecutando el comando y produciendo salida en la terminal, sin que realmente manipule fichero alguno.

Utilizaremos rsync para conectarnos desde nuestro cliente (la máquina donde queremos almacenar la copia respaldo) a la máquina remota (donde tenemos el original). Para ellos indicamos la siguiente sintaxis:

rsync -avz -e ssh /ruta/origen/a/respaldar usuario:maquina.remota:/ruta/remota/destino

en donde la opción -a indica el modo "archivada", que retiene las fechas y horas, información de propietario y grupo, y espeja recursivamente, compiando enlaces simbólicos como enlaces, etc (si quisiéramos copiar el referente del enlace, tenemos que incorporar también -L. La opción -v es verbosa e irá indicando cada fichero copiado. La opción -z comprime los datos enviados. La opción -e indica el tipo de intérprete a utilizar (en este caso, shell seguro SSH). usuario es el nombre de usuario en la máquina remota.

Por ejemplo, para copiar todo nuestro directorio /home de nuestro sistema GNU con Linux a una máquina remota, utilizaríamos el siguiente comando de organización:

rsync -avz -e ssh /home/$USER usuario@maquina.remota:/ruta/destino 

Naturalmente, al utilizar SSH, rsync nos solicitará la contraseña de la máquina.remota, y comenzará a copiar, reportando cada fichero. Una vez completado el procedimiento de respuesta al pedido de copias, rsync nos presentará estadísticas tales como la cantidad de bytes transferidos y la velocidad promedio.

Podremos utilizar este comando subsecuentemente. Lo más importante de este proceder será que rsyncs sólo respaldará los ficheros que subsecuentemente hayan cambiado y aquellos nuevos, lo cual es muy útil para mantener actualizado los respaldos de todo tipo.

Restaurar un respaldo

Para restaurar un archivo único desde la copia respaldo, podremos utilizar scp para transferirlo desde el directorio de respaldo local al directorio requerido en la máquina remota.

Ahora bien, para restaurar el respaldo al completo, simplemente indicamos el mismo comando anterior, pero invirtiendo el orden, pasando desde el directorio del respaldo a la máquina destino y origen, de la siguiente manera:

rsync -avz -e ssh usuario@maquina.remota:/ruta/origen/respaldo /ruta/respaldo/local

Como se ve, debemos ser cuidadosos de omitir la barra / al final de directorio. Al omitirse la barra, toda la estructura del directorio origen resultará recreada en la máquina remota (tal es el motivo por el cual la hemos omitido). 

Nota: Si bien en Unix es opcional agregar una / para especificar un directorio, en el caso específico de rsync si hubiésemos especificado una barra la estructura de directorios se replicaría desde el directorio dado (por ejemplo, el comando rsync -avz- e ssh usuario@maquina.remota:/ruta/al/home /directorio/respaldo/local/ producirá el respaldo adentro de /directorio/respaldo/local/ruta/al/home en la máquina.remota).

La opción --delete

También han comprendido ya que el comportamiento estándar actualiza ficheros en el destino, por lo cual el borrado de los mismos en el directorio origen no hará lo mismo en el de destino. 

Sin embargo, si quisiéramos que los ficheros removidos en el origen resulten también borrados en el destino, debemos agregarle el prefijo  --delete.

Por ejemplo, para hacer una actualización de los archivos borrados de un respaldo de la carpeta de usuario ~/Música situadas un pendrive USB llamado "PENDRIVE", usaríamos:

rsync -va /home/$USER/Música /media/$USER/PENDRIVE/ --delete

Rsync y enlaces simbólicos

Como se indicó, el comportamiento estándar de rsync -a es copiar los enlaces simbólicos como enlaces. Para que esto no se produzca y se copien también los destinos de dichos enlaces simbólicos, debemos agregar la opción -L luego de la opción -a.

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 uso un túnel SSH a través de la red anónima Tor en Ubuntu?

 Durante la histórica inauguración del Viaducto Presidente Perón de Sarandí, Juan Perón explica ante el Gobernador de la Provincia de Buenos Aires Carlos Aloé y el intendente de Avellaneda José Luis García, cómo crear un túnel Secure Shell a través de la red Tor.

¡Señor Cobernador!

¡Señor Intendente!

¡Trabajadores!

Esta obra magnífica de ingeniería, monumental en su factura y insuperable en su construcción, comenzó a gestarse en el principio de nuestro gobierno bajo auspicio de los muchachos de Vialidad de la Provincia. Debía responder al abhelado objetivo de solucionar y ordenar el tránsito, en áreas de la ciudad donde se veían atrasadas por la circulación de múltiples convoyes, entre ellos el ferrocarril lechero.

El trabajo que han emprendido ha consistido en elevar el nivel de vías y dejar las calles libres al tránsito vehicular, gracias a una inversión aproximada de 30 millones de pesos. ¡Cuánto han hecho! Me regocijo al observar esta portentosa obra, y observar en ella el rostro de todos los trabajadores Argentinos que han colmado de dicha mi corazón.

Un viaducto como este permite ahorrar tiempo, pero también hacer un cruce como este más seguro para todos. Permitirá ahorrar el tiempo que llevaba esperar al tren, que lo podremos utilizar en nuestro provecho, transformándolo ahora en un tiempo libre y feliz.

Sin embargo, un viaducto o túnel, como obra de infraestructura, puede servir también como clara inspiración para el desarrollo seguro y anónimo de todas nuestras necesidades de cómputo.

Vean señores, por diseño, el Shell Seguro (SSH) es una forma inherentemente bien pensada para obtener acceso con protección cifrada a máquinas remotas. Sin embargo, puede suceder que nos sea necesario una implementación aún más segura del mismo.

Normalmente, esto implica abrir el puerto 22 del router o configurar un reenvío de puertos. También se puede utilizar abrir todos los puertos del router, o utilizar DMZ.

En entornos de conexión hostiles como los de hoy, siempre nos será útil hacerlo más seguro, y poder contar con manera de sortear ciertos obstáculos telemáticos que nos podrían aparecer en la red.

Emplear un túnel a través de la red oculta Tor puede suplir estos inconvenientes.

La red Tor emplea un concepto de enrutamiento de capas de cebola, de manera de utilizar las redes públicas con el mayor anonimato posible. La idea es dirigir el tráfico telemático a través de una miríada de servidores, y encriptar cada estación en el camino. Por intermedio de estas postas seguras y anónimas, podremos agregar un nivel de anonimato mayor al normal, e incluso ocultar nuestros servicios de celosos actores intermediarios. 

Indudablemente que el Justicialismo ha de servir las necesidades de los Pueblos Libres. Por lo tanto, os enseñaré cómo realizar conexiones SSH a través de Tor. El proceso no esa terriblemente dificultoso si utilizamos el puerto tradicional de SSH, que es el puerto 22 (aunque podríamos modificarlo eventualmente).

En primer lugar, requeriremos instalar Tor. Para ello abrimos una terminal con Ctrl+Alt+t e ingresamos el siguiente Comando de Organización:

sudo apt-get install tor -y

Tras ingresar a ciegas nuestra contraseña de usuario, el sistema instalará la paquetería necesaria.

Acto seguido, agregaremos un par de opciones al fichero de configuración del configuración de Tor. Para ello ingresamos:

sudo nano /etc/tor/torrc

Se abrirá un fichero de configuración que tendrá ya contenido. Al final de dicho archivo ingresamos estas líneas:

## Líneas peronistas para usar SSH a través
## de un túnel a la red oculta Tor
HiddenServiceDir /var/lib/tor/other_hidden_service
HiddenServicePort 22

Procedemos a guardar el fichero de configuración con Ctrl+o y salimos del editor GNU Nano con Ctrl+x.

También nos aseguramos de otorgarle los permisos necesarios a nuestra configuración de Secure Shell, mediante el comando:

chmod g-rw ~/.ssh/config

Ahora podremos reiniciar el servicio de Tor para hacer uso del servicio de Shell seguro SSH a través de la red oculta. Esto lo haremos mediante el siguiente Comando de Organización:

sudo systemctl restart tor

Al reiniciar el servicio Tor, se generarán toda una serie necesaria de ficheros de trabajo que se localizarán en el directorio /var/lib/tor/other_hidden_service. En dicho directorio estará el nombre de huesped que desea utilizar para conectarse al servidor desde el cliente remoto. Para conocer cuál es dicho nombre de huesped (hostname), podemos utilizar este comando:

sudo cat /var/lib/tor/other_hidden_service/hostname

Podría obtener un resultado en cadena de caracteres, terminada en .onion. Por ejemplo:

vivaperoncarajovivaperoncarajovivaperoncarajovivaperonca.onion

Cómo conectarse al server SSH Tor

Una vez que tenemos este hostname, ahora abrir una terminal o utilizar un equipo distinto (donde también hemos instalado Tor). Para conectarse con el servidor, usaremos el comando torify para torificar al hostname provisto por el comando anterior. Para hacer la conección, utilizará el comando:

torify ssh usuario@hostname

Donde usuario es un usuario remoto y hostname es el nombre de huésped provisto por la red oculta Tor.

Por ejemplo:

torify ssh usuario@vivaperoncarajovivap....onion

Se nos solicitará nuestra contraseña del usuario remoto (o llave de paso SSH), y le una vez conformado dicho requerimiento, tendremos permitido ingresar al servidor. La ventaja es que el tráfico estará ruteado a través de la red anónima Tor.

El inconveniente de usar el puente Tor de esta forma es que obtendrá velocidades de transmisión menores que si estableciera una conexión SSH directa. Este sacrificio en segundos de valdrán la pena si consideramos el anonimato en la red y tener que habilitar aperturas externas del router intermedios.