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