Autenticación SSH con Llave Pública

0
129

¡Hola amigas y amigos!

Imagine que Usted se estrena como Syadmin en una empresa que tiene una docena de servidores con sistemas operativos *NIX. Si Usted tiene que iniciar una sesión remota mediante SSH en algún que otro servidor en varias ocasiones durante su jornada de trabajo y en todas esas oportunidades debe teclear en una Terminal ssh usted@servidor-remoto y su contraseña, seguro que al final del día se sentirá obstinado al introducir tantas veces su propio password, sin contar con la posibilidad de que algún que otro fisgón inteligente la descubra mientras Usted la teclea y desencadene en la “LAN que Usted administra” todo un hackeo en regla. 😉

La Autenticación SSHSecure Shell” mediante Llave Pública, también conocida como “Autenticación SSH sin contraseña o “Passwordless SSH” permite el inicio de sesión remota sin la necesidad de una contraseña.

Las Llaves SSH son mas seguras que las contraseñas debido a que la Llave Privada no se comparte nunca, ni viaja a través de la red. El cifrado de las Llaves Privadas asegura que su contenido no pueda leerse fácilmente.

Introducción a la Autenticación SSH mediante Llaves

Siempre son dos las Llaves SSH que se utilizan: la Privada y la Pública. Por regla general, la Llave Privada se almacena en la carpeta /home/usuario/.ssh/id_<tipo de cifrado> y la pública en /home/usuario/.ssh/id<tipo de cifrado>.pub.

El tipo de cifrado que mas se usa es el RSA “Rivest, Shamir y Adleman”, desarrollado en 1997. Es el primer algoritmo criptográfico y el mas empleado en cifrados y firmas digitales. Cuando utilizamos el cifrado RSA, los nombres de las Llave Privada y Pública son id_rsa e id_rsa.pub respectivamente.

La Llave Pública “Public Key” se genera para el uso público, como su nombre propio lo indica. Se adiciona a los equipos remotos a los que nos deseamos conectar en el archivo /home/usuario/.ssh/authorized_keys. La Llave Privada “Private Key” se guarda en nuestro equipo local con estrictas reglas de acceso.

Cuando generamos las llaves, debemos suministrar una Frase de Contraseña “PassPhrase” y la longitud del cifrado RSA en bits. NO es recomendable utilizar Llaves sin PassPhrase. Veamos un ejemplo del método a seguir.

Ejemplo de generación y uso de las llaves

Los equipos involucrados son los siguientes:

  • Cliente: sysadmin.swl.fan
  • Servidor: leonardo-davinci.swl.fan
root@sysadmin:~# host sysadmin
sysadmin.swl.fan has address 192.168.10.1

root@sysadmin:~# host leonardo-davinci
leonardo-davinci.swl.fan is an alias for leonardo.swl.fan.
leonardo.swl.fan has address 192.168.10.12
  • Generamos las Llaves en nuestro equipo:
root@sysadmin:~# rm -R .ssh/

root@sysadmin:~# ssh-keygen -t rsa -b 4096
Generating public/private rsa key pair.
Enter file in which to save the key (/root/.ssh/id_rsa):
Created directory '/root/.ssh'.
Enter passphrase (empty for no passphrase):
Enter same passphrase again:
Your identification has been saved in /root/.ssh/id_rsa.
Your public key has been saved in /root/.ssh/id_rsa.pub.
The key fingerprint is:
94:e4:ba:ae:99:06:5b:fd:d3:72:b4:62:67:15:48:92 root@sysadmin
The key's randomart image is:
+---[RSA 4096]----+
|        ..       |
|       oE..      |
|        +o .     |
|       o  . .    |
|     .. S    .   |
|  . . ..  . .    |
|   +  .. o o     |
|  . .+  * *      |
|   .+... B       |
+-----------------+
  • Copiamos la Llave Pública “Public Key” al servidor remoto:
root@sysadmin:~# ssh-copy-id root@leonardo
The authenticity of host 'leonardo (192.168.10.12)' can't be established.
ECDSA key fingerprint is 46:8d:f6:58:50:d1:a2:70:61:17:94:4f:bf:6e:3d:6a.
Are you sure you want to continue connecting (yes/no)? yes
/usr/bin/ssh-copy-id: INFO: attempting to log in with the new key(s), to filter out any that are already installed
/usr/bin/ssh-copy-id: INFO: 1 key(s) remain to be installed -- if you are prompted now it is to install the new keys
root@leonardo's password:

Number of key(s) added: 1

Now try logging into the machine, with:   "ssh 'root@leonardo'"
and check to make sure that only the key(s) you wanted were added.
  • Adicionamos al agente ssh-agent local las claves generadas:

Con el objetivo de que cada vez que iniciemos una sesión remota mediante ssh root@leonardo no nos pida el PassPhrase, adicionamos las Llave Privada “Private Key” -identidad- al Agente de Autenticación SSH. Para mas información consulte man ssh-agent, man ssh-add.

root@sysadmin:~# ssh-add
Enter passphrase for /root/.ssh/id_rsa:
Identity added: /root/.ssh/id_rsa (/root/.ssh/id_rsa)
  • Modificamos el archivo local /etc/ssh/sshd_config:

Los cambios en el archivo se muestran en negritas.

root@sysadmin:~# nano /etc/ssh/sshd_config
....
# Lifetime and size of ephemeral version 1 server key
KeyRegenerationInterval 3600
ServerKeyBits 4096

Importante: El siguiente cambio en la configuración del SSH en equipo local o cliente, inhabilita el inicio de sesión remoto clásico con contraseña desde un equipo remoto. NO es obligatorio hacerlo.

# Change to no to disable tunnelled clear text passwords
PasswordAuthentication no
  • Reiniciamos el servicio:
root@sysadmin:~# systemctl restart ssh
root@sysadmin:~# systemctl status ssh
 ssh.service - OpenBSD Secure Shell server
   Loaded: loaded (/lib/systemd/system/ssh.service; enabled)
   Active: active (running) since mar 2017-08-29 11:38:10 EDT; 5s ago
 Main PID: 4575 (sshd)
   CGroup: /system.slice/ssh.service
           └─4575 /usr/sbin/sshd -D

ago 29 11:38:10 sysadmin systemd[1]: Started OpenBSD Secure Shell server.
ago 29 11:38:10 sysadmin sshd[4575]: Server listening on 0.0.0.0 port 22.
ago 29 11:38:10 sysadmin sshd[4575]: Server listening on :: port 22.
  • Iniciamos sesión en el equipo remoto sin contraseña:
root@sysadmin:~# ssh root@leonardo
The programs included with the Debian GNU/Linux system are free software;
the exact distribution terms for each program are described in the
individual files in /usr/share/doc/*/copyright.

Debian GNU/Linux comes with ABSOLUTELY NO WARRANTY, to the extent
permitted by applicable law.
Last login: Tue Aug 29 11:51:49 2017 from 192.168.10.1
root@leonardo:~#
  • Comprobamos permisos de archivos locales y remotos:
root@sysadmin:~# ls -la | grep .ssh
drw-------  2 root root  4096 ago 29 12:04 .ssh

root@sysadmin:~# ls -l .ssh/
total 12
-rw------- 1 root root 3326 ago 29 11:27 id_rsa
-rw-r--r-- 1 root root  739 ago 29 11:27 id_rsa.pub
-rw-r--r-- 1 root root  444 ago 29 11:29 known_hosts

root@sysadmin:~# ssh root@leonardo
root@leonardo:~# ls -la | grep .ssh
drwx------  2 root root 4096 ago 29 12:01 .ssh

root@leonardo:~# ls -l .ssh/
total 8
-rw------- 1 root root 739 ago 29 12:01 authorized_keys
-rw-r--r-- 1 root root 444 ago 29 11:54 known_hosts

Los permisos en las carpetas y archivos son correctos.

Otros aspectos de interés

  • El valor por defecto ServerKeyBits 1024 en los archivos /etc/ssh/sshd_config de los servidores remotos, NO tiene porqué ser igual al valor ServerKeyBits 4096 que se configuró en el equipo local
  • De Wikipedia RSA: Las claves RSA son normalmente de entre 1024-2048 bits de longitud. Algunos expertos creen que las claves de 1024 bits podrían comenzar a ser débiles en poco tiempo; claves de 4096 bits podrían ser rotas en un futuro. Por lo tanto, si n es suficientemente grande el algoritmo RSA es seguro. Si n tiene 256 bits o menos, puede ser factorizado en pocas horas con un ordenador personal, usando software libre. Si n tiene 512 bits o menos, puede ser factorizado por varios cientos de computadoras como en 1999. Un dispositivo hardware teórico llamado TWIRL descrito por Shamir y Tromer en el 2003 cuestionó a la seguridad de claves de 1024 bits. Se recomienda actualmente que n sea como mínimo de 2048 bits de longitud.
  • Personalmente recomendamos un mínimo de 4096 bits para el cifrado RSA, al generar las llaves.
  • La Identidad que adicionamos mediante ssh-add al Agente de Autenticación evita la solicitud del PassPhrase en la máquina local y nunca se transmite por la red. La fortaleza de una Public Key recae en la longitud en bits declarada al generar la llave. NO está relacionada en absoluto con la fortaleza del PassPhrase.
  • El registro “log” del inicio de sesión remota mediante SSH lo podemos ver si ejecutamos:
root@sysadmin:~# ssh -v root@leonardo
  • Para depurar posibles errores en el proceso de autenticación, ejecutar:
root@leonardo:~# tail -f /var/log/auth.log

Resumen

En este artículo solo nos hemos referido a la PasswordLess SSH para equipos con sistemas operativos UNIX/Linux. Sin embargo lo podemos implementar en máquinas clientes con sistemas operativos de Microsoft mediante el PuTTY (muy buena documentación aporta el paquete putty-doc), WinSCP y otros.

Esperamos que este documento le sea útil a los amantes del Software Libre.

¡Hasta la próxima entrega!

Dejar respuesta

Please enter your comment!
Please enter your name here