Mostrando entradas con la etiqueta configurar Ubuntu. Mostrar todas las entradas
Mostrando entradas con la etiqueta configurar Ubuntu. Mostrar todas las entradas

miércoles, 9 de agosto de 2023

¿Cómo instalo Nginx en Ubuntu 22.04LTS?

 Apenas iniciada su primer Presidencia, Juan Perón impuso un plan en contra de la suba descontrolada de precios, que puso a tono los mismos y afianzó el poder de consumo del Pueblo Trabajador. Mientras presentaba el plan conocido como "de los sesenta días", explicó cómo instalar el servidor web Nginx en Ubuntu.

¡Señores!
 
Es tal la trascendencia que asigno a la necesidad de terminar con la carestía de la vida - especialmente en beneficio de la clase humilde de la Nación - que he llegado hasta aquí con el deseo de dar la iniciación de esta campaña que llamamos de los sesenta días.

En primer término se ha fijado ya hace tiempo cual es el concepto del equilibrio social entre sueldos y salarios. Existe una línea de la vida fijada por los salarios mínimos. Ese salario mínimo establece la línea de la vida. Los que por deficiencia de salario no alcanzan a ese salario vital, son sumergidos. Y los que lo pasan, son los emergidos.

Buscamos que en el país - en relación a los precios existentes - no existan salarios que establezcan la condición de sumergido para ningún ciudadano argentino. Si los precios suben justificadamente, no hay otro remedio que aumentar los salarios. Pero si suben los precios injustificadamente, el remedio está en bajar los precios.

En este momento, esos dos factores, el aumento justificado y el aumento injustificado, son las causas de la carestía de la vida.

En realidad, el aumento que puede considerarse justificado obedece a razones reales, impulsados por la escasez de producción, por el exceso de exportación o por la mala distribución de los artículos de primera necesidad. Y la causas ficticias obedecen a la especulación, a la mala distribución por acopio o por sustracción a la venta.

Lo primero ha de encararse para resolverlo en forma absolutamente racional, y por lo tanto con medidas racionales. Lo segundo, es decir la especulación, el acopio o la sustracción a la venta deberá combatirse con medidas drásticas de la mayor energía.

En este trabajo que hoy inicia el gobierno, para abaratar los artículos de primera necesidad necesitamos proceder racionalmente para llevar al mínimo los costos de producción, equilibrar la producción misma en su aspecto cualitativo, evitar el exceso de exportación en perjuicio del consumo interno, y racionalizar la producción. Y en segundo término contra las medidas ficticias, es decir la especulación, el acaparamiento o la sustracción a la venta, castigarlo con toda la fuerza de la Ley, ya que ambas cosas deben de considerarse en épocas como las actuales - en que la Nación debe servir al exterior en una proporción desconocida hasta hoy para abastecer a los pueblos hambrientos de otros continentes sin que la población argentina sufra las consecuencias de esa escasez - con una científica graduación de lo que podemos enviar al extranjero y lo que debemos mantener para el alimento de nuestra población.

Para ello, en primer término la colaboración de todos es absolutamente indispensable. Estamos encarando la solución de un problema de todos los argentinos, y en consecuencia todos los argentinos deben colaborar en su solución. Los productores, los industriales y los comerciantes deberán facilitar la solución del problema acelerando la producción, disminuyendo a lo indispensable la exportación, y asegurando la distribución adecuada. Eso en cuanto a las fuerzas patronales.

Los trabajadores tienen aquí también su cooperación, y ella ha de ser aumentando el rendimiento de su trabajo para producir más. Esa es la misión de todo trabajador en este momento. Y su cooperación en el taller, en la fábrica, y en el campo ha de ser asegurar para el país el mayor grado de producción posible, rindiendo con su trabajo en todas las horas el máximo posible.

Los consumidores - vale decir el Pueblo - también tiene su cooperación que asegurar en este problema. Cooperarán no pagando en ningún caso precios mayores que los fijados y denunciando a todo mal comerciante que quiera imponer precios sobre los oficiales fijados. Cada ciudadano debe ser un soldado de esta cruzada y cooperar con el Estado para el bien de todos.

Los funcionarios encargados de la vigilancia e inspección deben ser inflexibles y rígidos en el cumplimiento de su función. Los poderes y autoridades del Estado en todas sus jerarquías y funciones deben prestar apoyo y cooperación para la mejor realización de este plan.

Nadie dentro del país puede ser espectador indiferente sin que se lo considere un traidor a la causa de todos. Esta campaña de sesenta días, debe de poner a la Nación entera en marcha para vencer en ese plazo todas las dificultades, con la cooperación de los productores, industriales y comerciantes, con la cooperación de los trabajadores, haciendo rendir al máximo su trabajo, con la cooperación de los ciudadanos consumidores, no haciendo el juego a la especulación y no pagando en ningún caso un precio sobre los fijados.

Y señores, por sobre todas las cosas para no inutilizar todos estos esfuerzo de conjunto, necesitamos honradez. Honradez en el comerciante, para mantener la calidad de los artículos y no inutilizar los esfuerzos realizados. Honradez en el público, que no se preste a maniobras de ninguna naturaleza. Honradez en los funcionarios para hacer cumplir a todos con su deber de acuerdo a la ley.

Señores, vencidos los sesentas días, los precios de los artículos de primera necesidad serán los establecidos en 1945 por el Consejo Nacional de Posguerra, es decir, lo que necesita una familia obrera, en comida, menaje y vestido, para vivir dignamente con el salario vital mínimo establecido. 
En los servicios telemáticos también hemos de obrar de la misma manera. Hemos de disponer de software servidor capaz de cooperar y de gastar lo mínimo requerido. Nginix es la solución que hemos propuesto.

Se trata de uno de los servidores web más populares del mundo y aloja algunos de los sitios más grandes y con mayor tráfico en Internet. Es más fácil de utilizar que Apache en la mayoría de los casos y puede emplearse como servidor web o proxy inverso.

En esta guía os explicaré la manera de instalar Nginx en su servidor de Ubuntu 22.04LTS.

Requisitos previos

Antes de comenzar a usar esta guía, debería contar con lo siguiente:
  • Un servidor de Ubuntu 18.04 y un usuario regular que no sea Conductor (root) capaz de ejercer privilegios sudo. Además, debería ya tener habilitado un firewall básico capaz de bloquear los puertos que no sean esenciales. Para aprender a configurar una cuenta normal de usuario e instalar un firewall, siga nuestra guía de configuración inicial para Ubuntu 18.04.
Cuando disponga de una cuenta, inicie sesión como usuario no root para comenzar.

Paso 1: Instalar Nginx

Debido aq ue Nginx está disponible en los repositorios predeterminados de Ubuntu, puede instalarlo utilizando el sistema de paquetes apt.
Actualice su índice local de paquetes:

sudo apt update
sudo apt install nginx

Paso 2: Ajustar el firewall

Si siguió el tutorial de configuración del servidor de los requisitos previos, tendrá habilitado el firewall UFW. Compruebe los perfiles de aplicaciones ufw disponibles con el siguiente comando:

sudo ufw app list

...nuestro sistema nos devolverá:

Available applications:
  Nginx Full
  Nginx HTTP
  Nginx HTTPS
  OpenSSH

Habilitaremos el perfil más restrictivo, el cual de todas formas permitirá el tráfico que hemos configurado y con ello el tráfico en el puerto 80. Para ello ingresamos:

sudo ufw allow 'Nginx HTTP' 

Verificamos el cambio realizado con:

sudo ufw status 

...nuestro sistema nos devolverá:

Status: active

To                         Action      From
--                         ------      ----
OpenSSH                    ALLOW       Anywhere                  
Nginx HTTP                 ALLOW       Anywhere                  
OpenSSH (v6)               ALLOW       Anywhere (v6)             
Nginx HTTP (v6)            ALLOW       Anywhere (v6)

Paso 3: Comprobar nuestro servidor web

Realziaremos una verificación con el sistema init systemd para saber si se encuentra en ejecución el servicio, ingresando la siguiente órden:

systemctl status nginx

...a lo cual deberíamos recibir en la terminal algo como:
● nginx.service - A high performance web server and a reverse proxy server Loaded: loaded (/lib/systemd/system/nginx.service; enabled; vendor preset: enabled) Active: active (running) since Fri 2018-04-20 16:08:19 UTC; 3 days ago Docs: man:nginx(8) Main PID: 2369 (nginx) Tasks: 2 (limit: 1153) CGroup: /system.slice/nginx.service ├─2369 nginx: master process /usr/sbin/nginx -g daemon on; master_process on; └─2380 nginx: worker process

A través su dirección IP, accederemos a la página de destino predeterminada de Nginx para confirmar que el software opera de la manera deseada por el Pueblo:

http://IP_del_servidor

Deberíamos ver la insulsa página web de destino predeterminada de Nginx:

Paso 4: Configurar bloques de servidor (recomendable)

Al emplear el servidor web Nginx, podremos emplear _bloques de servidor _(similares a los hosts virtuales de Apache) a fin de encapsular detalles de configuración y alojar más de un dominio desde un único servidor.

Configuraremos un dominio llamado peronismo.com, pero debería cambiarlo por su propio nombre de dominio.

Creemos el directorio para peronismo.com, utilizando el indicador -p para crear cualquier directorio principal necesario:

sudo mkdir -p /var/www/peronismo.com/html

Asignamos la propiedad del directorio:

sudo chown -R $USER:$USER /var/www/peronismo.com/html

Los permisos de su las raíces de nuestras webs han de ser las correctas si no modificó su valor umask, pero podremos comprobarlo ingresando:

sudo chmod -R 755 /var/www/peronismo.com

Asimismo, crearemos allí una página de ejemplo index.html utilizando el editor GNU Nano:

nano /var/www/peronismo.com/html/index.html

Se abrirá el editor GNU Nano con el archivo vacío index.html. Le pegaremos el siguiente contenido:

 

Guardamos los cambios en el archivo con Ctrl+o y cerramos el editor con Ctrl+x.

Acto seguido, creamos un nuevo bloque de servidor en /etc/nginx/sites-available/peronismo.com. Lo haremos con:

sudo nano /etc/nginx/sites-available/peronismo.com

Le pegamos en dicho archivo el siguiente bloque de configuración, a fin de actualizar nuestro nuevo directorio y nombre de dominio:

server {
        listen 80;
        listen [::]:80;

        root /var/www/peronismo.com/html;
        index index.html index.htm index.nginx-debian.html;

        server_name peronismo.com www.peronismo.com;

        location / {
                try_files $uri $uri/ =404;
        }
}

Guardamos el archivo con Ctrl+o y cerramos el editor GNU Nano con Ctrl+x.

Habilitamos el archivo creando un enlace entre él y el directorio sites-enabled. Para ello utilizamos:

sudo ln -s /etc/nginx/sites-available/peronismo.com /etc/nginx/sites-enabled/

Al ingresar este comando de organización, quedará habilitado y configurado los dos bloques del servidor para responder las solicitudes según las directivas listen y server_name.
  • peronismo.com: responderá a solicitudes de peronismo.com www.peronismo.com, en tanto
  • default: responderá a cualquier solicitud en el puerto 80 que no coincida con los otros dos bloques.
Para evitar un posible problema de memoria de depósito hash que pueda surgir al agregar nombres de servidor adicionales, será necesario ajustar un valor en el archivo /etc/nginx/nginx.conf. A tal fin editaremos el archivo:

sudo nano /etc/nginx/nginx.conf

Se abirá Nano con dicho archivo. Usamos Ctrl+w para buscar la directiva server_names_hash_bucket_size. Al localizar dicha línea, le eliminamos el símbolo numeral ("#") a fin de descomentar la línea.


...
http {
    ...
    server_names_hash_bucket_size 64;
    ...
}
...

Tras guardar los cambios con Ctrl+o y salir del editor con Ctrl+x, realizaremos una prueba operativa en busca de posibles errores de sintaxis:

sudo nginx -t

Finalmente, reiniciamos el servidor Nginx para que se apliquen los cambios:

sudo systemctl restart nginx

Con todo esto, Nginx debería proporcionar su nombre de dominio. Podremos comprobar esto visitando http://peronismo.com. Allí, deberíamos ver el siguiente mensaje:

Conclusión

Conforme hayamos instalado y configurado neustro servidor web, contaremos con muchas opciones respecto del tipo de contenido que ofreceremos, y de las tecnologías que deseemos utilizar para crear una experiencia más completa y Justicialista para el Pueblo, que es el verdadero consumo.

lunes, 7 de marzo de 2022

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.

viernes, 31 de diciembre de 2021

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

jueves, 30 de diciembre de 2021

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

domingo, 18 de abril de 2021

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

lunes, 1 de marzo de 2021

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

jueves, 19 de septiembre de 2019

¿Cómo configuro el teclado IBM Model 122 "Acorazado" en Ubuntu?

¡Trabajadores!

Es sabido que un trabajador ha de contar con las mejores herramientas para hacer su trabajo. Pero muchas veces las mejores herramientas son las que el mismo trabajador crea o amolda a sus necesidades.
Es sabido que dentro del mundo de las terminales Unix, inicialmente se dio en utilizar los teclados provistos en las máquinas teletipo Tipo 33. Estos incómodos teclados fueron superados por otros mecánciamente más aptos y funcionalmente mejor pensados. Indudablemente los teclados tipo Space Cadet de las folklóricas computadoras Symbolics, o los influenciales LK201 para las postrimeras terminales DEC son espejos en los que habremos de mirarnos en los años que vendrán. Sin embargo, nadie duda que el más conocido de los teclados hayan sido los modelos de IBM.
 La computadora PC original contaba con el teclado "Modelo F" de 84 teclas. De este derivaría el más influyente modelo, el M (extendido y mejorado), de 101/102 teclas, del cual se desprenden los utilizados actualmente.
Aún así no fueron los definitivos, ya que en el Justicialismo de todo existe como en botica. Tal es así, que la locura experimental no tardó en alcanzar su más estrafalario paroxismo con "el acorazado". Se trataba del teclado IBM Modelo F de 122 teclas para la terminal IBM 3270. Este tipo de terminales industriales y de data-entry requerían el uso de una gran cantidad de teclas aún no estandarizadas, y para ellos se desarrolló este fenomenal teclado capaz de requerir un "Mano" del Eternauta para su correcta operación.

Ahora bien, estos teclados son parcialmente compatibles con las IBM PC, pero difíciles de adaptar al uso de los sistemas operativos actuales. Es por ello que la empresa Unicomp ha recreado el mismo en un fiel clon con teclas de resorte basculante, su teclado número de catálogo UB40T56 provisto de interfaz USB (y en esquema negro peronista).


El uso de uno de estos teclados tan provistos puede presentar ventajas a para quien requiera enorme combinaciones de teclas y un astronómico empleo de edición de texto y programación.

Lamentablemente, el uso de este tipo de teclados no está netamente soportado en GNU. Para hacer un uso efectivo, habremos de emplear ciertos recaudos. En particular debemos tener en cuenta dque nuestro sistema debe recibir las instrucciones específicas para saber qué hacer con las las teclas no estandarizadas del Modelo F 122 de Ubicom.

Vean señores, en un teclado estándar, cada tecla del teclado envia electrónicamente un código de tecla único al sistema, el cual, y nuestra computadora debería reaccionar acordemente. Sin embargo esto no es lo procedente en el teclado Unicomp mencionado.

Afortunadamente, mi rol como Conductor del Movimiento Nacional Justicialismo me impone acercar de forma paternalista las soluciones anheladas por las Masas del Pueblo. Por lo tanto volcaré esta sapiencia para que cada argentino lleve en su mochila el bastón de Mariscal.

La primera tarea para usar el Unicomp de 122 teclas con Ubuntu será activar el modo de código de tecla único en el teclado en sí. Para lograrlo debemos abrir el teclado y remover un jumper específico de la plaqueta del mismo. Esto sencillo de hacer: damos vuelta el acorazado, y sacamos los tornillos de la carcasa, removiendo la mitad superior de la misma. La plaqueta quedará expuesta, lo que aprovechamos para buscar debajo de un pequeño microcontrolador integrado, y cerca del LED de Scroll Lock, al Jumper JP3.

Lo removemos tirando hacia arriba y quitando el jumper., y luego volvemos a cerrar el teclado y reponer los tornillos.

Acto seguido será recomendable activar en nuestro GNU con Linux el parámetro de kernel“atkbd.softraw=0”, lo cual podremos lograr a partir de Ubuntu 10.04 abriendo una Terminal con Ctrl+Alt+T e ingresando el siguiente Comando de Organización:

sudo nano /etc/default/grub

Se abrirá el archivo de configuración del arrancador Grub, con nuestros parámetros de configuración. Nos aseguramos de buscar la siguiente variante:

GRUB_CMDLINE_LINUX_DEFAULT=""

.,..y dentro del string entrecomillado, al final del mismo, le agregamos lo siguiente, de modo que quede:

GRUB_CMDLINE_LINUX_DEFAULT="atkbd.softraw=0"

Conforme finalicemos esta edición, guardamos los cambios con Ctrl+o, salimos del editor GNU Nano con Ctrl+x. No debemnos olvidar actualizar el arrancador Grub mediante el comando:

sudo grub-update

Si todo está bien y no devuelve errores, reiniciamos nuestro sistema con:

sudo reboot

(Nota: Si nos devolviese algún error, volvemos a editar el archivo para dejarlo como estaba y volvemos actualizar con sudo grub-update).

Si no hacemos esto, el comando showkey -s solamente nos mostrará los códigos de teclas que ya están preconfiguradas en el kernel, y no las que realmente son enviadas por el teclado. Es posible mostrar los códigos de teclas desconocidos activando el módulo i8042 en modo debug, pero el comando atkbd.softraw hace lo mismo de manera mas efectiva.

La parte molesta del procedimiento es tomar nota de cuáles son los códigos de tecla específicos que envía el teclado Unicomp 122. Ello se sondea con showkey -s y presionando las teclas para ver cada una.

Las teclas convencionales son más o menos parecidas a las estandarizadas por el teclado Modelo M de IBM, el de toda la vida. Sin embargo, existen discrepacias. Os listaré preliminarmente los resultados de mi sondeo específico. ¡Estén atentos que vuestros resultados pueden variar! Este teclado no es estándar y por ello requiere comprobar esto para evitar resultados indeseables con el mismo.

Grupo Tecla Presión Soltar Código de tecla
Teclas de Función

F13 5b db

F14 5c dc 95

F15 5d dd 183

F16 63 e3

F17 64 e4

F18 65 e5

F19 66 e6

F20 67 e7

F21 68 e8

F22 69 e9

F23 6a ea

F24 6b eb
(siguiente fila) F1 3b bb 59

F2 3c bc 60

F3 3d bd 61

F4 3e be 62

F5 3f bf 63

F6 40 c0 64

F7 41 c1 65

F8 42 c2 66

F9 43 c3 67

F10 44 c4 68

F11 57 d7 87

F12 58 d8 88
Teclado numérico izquierdo (La tecla superior izq es “Esc”)

Esc 7e fe 121

Cent 76 f6 85

ImpPant 72 f2

Pausa e1 1d 45 e1 9d c5 119

Imprimir 74 f4

Ayuda 6d ed

Record e0 2a e0 37 e0 b7 e0 aa 99

Play 6f ef

GUI (Windows) 75 f5

Menú 6c ec
Teclado de edición (entre el teclado QWERTY y el teclado numérico)

RetrocedeTab 5a da

Insertar e0 49 e0 c9 104

RePág e0 51 e0 d1 109
(siguiente fila) Blue Return e0 4f e0 cf 107

Supr e0 52 e0 d2 110

AvPág e0 53 e0 d3 111
(siguiente fila) Flecha Arriba e0 48 e0 c8 103
(siguiente fila) Flecha Izq e0 4b e0 cb 105

Inicio e0 47 e0 c7 102

Flecha Der e0 4d e0 cd 106
(siguiente fila) Flecha Abajo e0 50 e0 d0 108
Teclado numérico
(fila superior) Fin 01 81 1

Bloq Desp 46 c6 70
(BloqDesp+Mayús) Bloq Num 45 c5 69

/ 37 b7 55

* e0 c5 e0 b5 98
(siguiente fila) KP-7 47 c7 71

KP-8 48 c8 72

KP-9 49 c9 73

4e ce 78
(siguiente fila) KP-4 41 cb 75

KP-5 4c cc 76

KP-6 4d cd 77

+ 4a ca 74
(siguiente fila) KP-1 4f cf 79

KP-2 50 d0 80

KP-3 51 d1 81

Enter e0 1c e0 9c 96
(siguiente fila) KP-0 52 d2 82

KP-. 53 d3 83
  • Grupo. Para dividir las cosas, he agrupado las teclas en 5 secciones separadas del teclado: las teclas de función, el teclado de la izquierda, el teclado QWERTY, el teclado de edición, y el teclado numérico. Los detalles del teclado QWERTY estarán al final ya que los otros grupos son más interesantes (las teclas del QWERTY funcionan sin problemas).
  • Tecla. Este es la impresión de la tecla en el teclado. Podría ser diferente en distintas variantes, de modo que en todos los casos he iniciado con el teclado desde la parte superior izquierda, y he ido bajando hacia la derecha y abajo..
  • Presión. Este es el código producido cuando la tecla se aprieta.
  • Soltar. Este el el código producido cuando la tecla se suelta.
  • Código de tecla. Este el el código de tecla configurado producido en la consola Linux. Las celdas rojas son valores que son erróneos, pero además hay muchos que faltan pues no se producen con una presión de tecla. Son equivocados porque el código de letras dan un resultado que no se condice con la tecla en sí - en algunos casos peligrosamente erróneos, como AvPg que produce un Supr. Una de las cosas de que debemos tener en cuenta es que DEBEMOS usar el comando "showkey -k" en la consola para obtener los mismos números que tengo. El servidor X parece agregar un 8 a cada código de tecla.
Podremos encontrar ciertas particularidades. F14 y F15 han recibidos códigos de tecla estándares por defecto, de modo que sus códigos de tecla deben coincidir con teclas definidas en los teclados más populares. Y por supuesto, BloqNum y BloqDesp comparten el mismo código lo cual es extraño. Finalmente la tecla Record envía dos toques de tecla en uno.

Corregir las Teclas Erróneas

En primer lugar debemos mapear las teclas que producen un código de tecla que representa una tecla diferente que la que corresponde. Como la tecla marcada como End, que devuelve el código estandarizado de la tecla Esc. He dejado dos de las teclas erróneas de este grupo ya que serán mejor representadas en la próxima sección.

Las teclas erróneas pueden ser corregidas con los siguientes comandos:
 
setkeycodes 7e         1    # Esc
setkeycodes e049      82    # Insert
setkeycodes e051     105    # PageUp
setkeycodes e052     111    # Delete
setkeycodes e053     109    # PageDown
setkeycodes 01       107    # End
setkeycodes 37        98    # KP-/
setkeycodes e035      55    # KP-*
setkeycodes 4e        74    # KP--
setkeycodes 4a        78    # KP-+

He dejado un par de las teclas erróneas de esta sección, ya que no devuelven valores peligrosamente incorrectos, y corresponden de manera más lógica a la próxima sección (las teclas Record y Blue Return).

Configurar las Teclas Extra

Ahora concentrémonos en las teclas extras. La parte difícil fue inventar nuevos códigos de tecla para estas teclas que no entren en conflicto con códigos de teclas previamente existentes, y que además sean razonables. Esto en la práctica es imposible, ya que el comando xmodmap -pk no aparenta mostrar un rango significativo de códigos de tecla no utilizados, aunque algunos de los códigos utilizados se empleen para butones con la orden "comprar" y cosas por el estilo!

De tal manera, que escogemos un rango con el mayor número de teclas no asignadas o inútiles, y los asignamos:
 
setkeycodes 5b       222    # F13
setkeycodes 5c       223    # F14
setkeycodes 5d       224    # F15
setkeycodes 63       225    # F16
setkeycodes 64       237    # F17
setkeycodes 65       238    # F18
setkeycodes 66       228    # F19
setkeycodes 67       229    # F20
setkeycodes 68       230    # F21
setkeycodes 69       231    # F22
setkeycodes 6a       232    # F23
setkeycodes 6b       233    # F24
setkeycodes 72        99    # Record (luego de intercambiar la tecla)
setkeycodes 74       209    # Print
setkeycodes 6d       138    # Help
setkeycodes 6f       239    # Play
setkeycodes 75       234    # Windows (GUI)
setkeycodes 6c       240    # Menu
setkeycodes 5a       235    # Backtab
setkeycodes e04f     236    # BlueReturn

Una vez que hemos cambiado esto, podemos buscar corregir los mapeados bajo el servidor X, que es la causa por la cual F17 y F18 están fuera de secuencia con los de arriba. Una de las teclas tiene que ser (al menos hasta que alguien logre una solución mejor) ordenada con un recambio de teclas. Para ello intercambiamos de lugar la tecla Record y la cambiamos por la marcada PrintScreen” (esto es fácil de hacer pues en los teclados IBM podemos sacar las teclas y ponerlas en otro lugar). Además como el código de teclas de Record efectivamente son dos códigos de tecla en uno, si intentamos remapearlo esto provoca "problemas extraños difíciles de dilucidar".

Corregir el resultado bajo servidor X11

Una vez que hemos configurado los código de tecla que no hacen cosas raras bajo el servidor X (por ejemplo F17 y F18 no producen un código de teclas bajo X11, sino que disparan otro evento), podemos seguir configurando el teclado bajo X según nuestros gustos.

A continuación un intento de mapear lo más fielmente posible las acciones de las teclas sin irnos a los extremos.
 
xmodmap -e "keycode 230 = F13"
xmodmap -e "keycode 231 = F14"
xmodmap -e "keycode 232 = F15"
xmodmap -e "keycode 233 = F16"
xmodmap -e "keycode 245 = F17"
xmodmap -e "keycode 246 = F18"
xmodmap -e "keycode 236 = F19"
xmodmap -e "keycode 237 = F20"
xmodmap -e "keycode 238 = F21"
xmodmap -e "keycode 239 = F22"
xmodmap -e "keycode 240 = F23"
xmodmap -e "keycode 241 = F24"
xmodmap -e "keycode 217 = Print"
xmodmap -e "keycode 9 = Escape 3270_Attn"
xmodmap -e "keycode  93 = cent bar"
xmodmap -e "keycode 175 = 3270_Record"
xmodmap -e "keycode 175 ="
xmodmap -e "keycode 247 = 3270_Play"
xmodmap -e "keycode 242 = Super_L"
xmodmap -e "keycode 248 = Multi_key"
xmodmap -e "keycode 243 = 3270_BackTab"
xmodmap -e "keycode 118 = Insert 3270_Duplicate"
xmodmap -e "keycode 112 = Prior 3270_Jump"
xmodmap -e "keycode 117 = Next 3270_Rule"

Esto nos da como resultado una configuración de teclado que más o menos ofrece los resultados esperados al presionar las teclas correspondientes. Para lograr algunos de los símbolos azules, presionamos la tecla correspondiente en combinación con Mayúscula.

El teclado numérico podría recibir un poco más de atención en cuanto a su mapeado en X, y hay algunos símbolos azules en el teclado QWERTY principal que podrían ser mapeados con mayor utilidad, pero de momento esto es suficiente para el Justicialismo.

Configurarlo fácilmente en un archivo

Una vez comprendido el censado de los código de tecla de este particular teclado y ajustado nuestros anhelos, podremos hacerlo efectivo para nuestro sistema. Lo más práctico es juntar todo en un script que podamos ejecutar, ya sea aisladamente o cuando arranca el sistema (tal vez no recomendado esto, pues desfasaría otros teclados estándares). Si quisiéramos poner en práctica lo primero y dejar un script que deba ejecutarse para usar este teclado Unicomp, podríamos ingresar:

nano ~/teclado_122.sh

Esto abrirá el editor GNU Nano con un archivo en blanco. y le agregamos entonces el siguiente bloque de texto (que engloba los comandos anteriores):

#!/bin/bash
#
# Configuración para el teclado Unicomp de 122 teclas peronista 
# para Ubuntu 10.04 y superior.
# corrección teclas erróneas:
setkeycodes 7e         1    # Esc
setkeycodes e049      82    # Insert
setkeycodes e051     105    # PageUp
setkeycodes e052     111    # Delete
setkeycodes e053     109    # PageDown
setkeycodes 01       107    # End
setkeycodes 37        98    # KP-/
setkeycodes e035      55    # KP-*
setkeycodes 4e        74    # KP--
setkeycodes 4a        78    # KP-+
#configuración de teclas extra del teclado unicomp 122
setkeycodes 5b       222    # F13
setkeycodes 5c       223    # F14
setkeycodes 5d       224    # F15
setkeycodes 63       225    # F16
setkeycodes 64       237    # F17
setkeycodes 65       238    # F18
setkeycodes 66       228    # F19
setkeycodes 67       229    # F20
setkeycodes 68       230    # F21
setkeycodes 69       231    # F22
setkeycodes 6a       232    # F23
setkeycodes 6b       233    # F24
setkeycodes 72        99    # Record (luego de intercambiar la tecla)
setkeycodes 74       209    # Print
setkeycodes 6d       138    # Help
setkeycodes 6f       239    # Play
setkeycodes 75       234    # Windows (GUI)
setkeycodes 6c       240    # Menu
setkeycodes 5a       235    # Backtab
setkeycodes e04f     236    # BlueReturn
#mapeo de teclas en x11
xmodmap -e "keycode 230 = F13"
xmodmap -e "keycode 231 = F14"
xmodmap -e "keycode 232 = F15"
xmodmap -e "keycode 233 = F16"
xmodmap -e "keycode 245 = F17"
xmodmap -e "keycode 246 = F18"
xmodmap -e "keycode 236 = F19"
xmodmap -e "keycode 237 = F20"
xmodmap -e "keycode 238 = F21"
xmodmap -e "keycode 239 = F22"
xmodmap -e "keycode 240 = F23"
xmodmap -e "keycode 241 = F24"
xmodmap -e "keycode 217 = Print"
xmodmap -e "keycode 9 = Escape 3270_Attn"
xmodmap -e "keycode  93 = cent bar"
xmodmap -e "keycode 175 = 3270_Record"
xmodmap -e "keycode 175 ="
xmodmap -e "keycode 247 = 3270_Play"
xmodmap -e "keycode 242 = Super_L"
xmodmap -e "keycode 248 = Multi_key"
xmodmap -e "keycode 243 = 3270_BackTab"
xmodmap -e "keycode 118 = Insert 3270_Duplicate"
xmodmap -e "keycode 112 = Prior 3270_Jump"
xmodmap -e "keycode 117 = Next 3270_Rule" 

Una vez que tengamos el archivo, guardamos los cambios y salimos del editor con Ctrl+o y Ctrl+x. Finalmente lo hacemos ejecutable con el siguiente comando:

chmod +x ~/teclado_122.sh
cd ~
sudo mv teclado_122.sh /usr/local/bin/

De ahora en más, podremos hacer efectivos los cambios ejecutando el script con este comando:

teclado_122.sh