¿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 Tempos. Sólo hace
falta un justo flagelar para limpiarlos...
Héte aquí señores que nuestro Justicialismo ha decidido una lucha
enconada con estas excrecencias, y ofrece hoy una infraestructura del
cómputo salvador que sirve 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 vertir 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.
Se generarán así dos ficheros que conforman las llaves criptográficas,
en este caso llamados llave_nodopj_compu1_de_fulano y
llave_nodopj_compu1_de_fulano.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.pub
Se mostrará en la terminal el contenido del fichero
llave_nodopj_compu1_de_fulano.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. 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
[email protected]
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
llave_nodopj_compu1_de_fulano.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
[email protected]
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
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.