UNIX – Cómo autenticar con clave pública en SSH.-

En este artículo voy a explicar cómo autenticar una sesión SSH utilizando clave pública, para permitir que un usuario se conecte a un sistema remoto sin necesidad de escribir la contraseña. Esta configuración es útil para cuando se requiere trabajar con scripts que se conectan a sistemas remotos de forma automática desde tareas programadas, por ejemplo los sistemas de respaldo (backup).

Los mecanismos de autenticación se utilizan para asegurar que un usuario sea quien dice ser. El método de autenticación más conocido por nosotros es el de usuario y contraseña. Para asegurar que «Pepe» sea realmente «Pepe», este mecanismo de autenticación requiere la contraseña de «Pepe». La fortaleza de este sistema se basa en que la contraseña sea lo más secreta posible, lo que equivale a decir que el verdadero «Pepe» sea el único que conozca su contraseña.

SSH permite utilizar una amplia variedad de mecanismos de autenticación diferentes entre los que se incluyen usuario y contraseña. Posiblemente este sea el mecanismo más utilizado por muchos para autenticar una sesión SSH, pero SSH también soporta la autenticación mediante clave pública, desafío/respuesta, GSSAPI, y otros.

La autenticación mediante clave pública se basa en la criptografía de clave pública, donde los procesos de encripción y desencripción son realizados utilizando claves diferentes (una clave para encriptar y otra para desencriptar, y viceversa), y funciona de la siguiente manera. La idea es que cada usuario cree un par de claves pública/privada para autenticación. El servidor SSH conoce la clave pública, y sólo el usuario conoce su clave privada.
Manos a la obra

Supongamos que necesitamos que «emiliano» en «syslocal» se conecte al sistema «sysremoto» autenticando como «admin» sin utilizar contraseña.

El primer paso consiste generar el par de claves de autenticación SSH para el usuario «emiliano» utilizando la herramienta ssh-keygen. SSH implementa la autenticación con clave pública utilizando RSA o DSA. La versión 1 del protocolo SSH sólo soporta RSA, mientras que la versión 2 soporta ambos sistemas.

Cambiar al directorio $HOME de «emiliano»:

[emiliano@syslocal ~]$ cd

Generar el par de claves de autenticación para SSH de tipo DSA (para la versión 2 del protocolo SSH):

[emiliano@syslocal ~] ssh-keygen -t dsa
Generating public/private dsa key pair.
Enter file in which to save the key (/home/emiliano/.ssh/id_dsa):
Created directory ‘/home/emiliano/.ssh’.
Enter passphrase (empty for no passphrase):
Enter same passphrase again:
Your identification has been saved in /home/emiliano/.ssh/id_dsa.
Your public key has been saved in /home/emiliano/.ssh/id_dsa.pub.
The key fingerprint is:
6f:d5:19:e4:f9:8f:9d:88:8d:c2:a4:ca:13:4c:2c:22 emiliano@syslocal
The key’s randomart image is:
+–[ DSA 1024]—-+
| .haaerk .- |
| agg hd |
| . ku df |
| -,sdf |
| dd34.,+S |
| ffddd |
| .B + |
| .=+ds |
| o2 ++o |
+—————–+

Cuando se utiliza RSA, ssh-keygen guarda la calve privada en el archivo ~/.ssh/id_dsa y la clave pública en ~/.ssh/id_dsa.pub.

Revisar los permisos de las claves generadas. id_dsa debe tener permisos restrictivos (600):

emiliano@syslocal:~$ ls -lath .ssh/
total 16K
drwx—— 2 emiliano emiliano 4,0K nov 4 11:04 .
-rw——- 1 emiliano emiliano 668 nov 4 11:04 id_dsa
-rw-r–r– 1 emiliano emiliano 607 nov 4 11:04 id_dsa.pub
drwxr-xr-x 4 emiliano emiliano 4,0K nov 4 11:04 ..

Además, el directorio /home/emiliano/.ssh/ debe tener permisos 700, tal como se observa.

Ahora es necesario copiar la clave pública del usuario «emiliano» al archivo ~/.ssh/authorized_keys en el directorio $HOME del usuario «admin» en el sistema «sysremoto». Este archivo posee una clave por línea, correspondiente a cada usuario que puede loguearse como «admin» utilizando el mecanismo de autenticación con clave pública.

Luego de realizar la copia, el usuario «emiliano» (perteneciente al sistema «syslocal») podrá loguarse como «admin» en «sysremoto» sin necesidad de escribir la contraseña.

En el sistema remoto «sysremoto», loguearse como usuario «admin» y cambiar al directorio $HOME:

[admin@sysremoto ~]$ cd

Si no existe, crear el directorio .ssh y asignarle los permisos adecuados:

[admin@sysremoto ~]$ mkdir .ssh
[admin@sysremoto ~]$ chmod 700 .ssh/

Si el archivo .ssh/authorized_keys no existe, crearlo con los permisos adecuados, de lo contrario la autenticación con clave pública no funcionará correctamente:

[admin@sysremoto ~]$ touch .ssh/authorized_keys
[admin@sysremoto ~]$ chmod 644 .ssh/authorized_keys

Como mencioné anteriormente, el archivo ~/.ssh/authorized_keys lista las claves públicas con las cuales se permite el acceso. Cuando un usuario se loguea, el cliente SSH le indica al servidor qué par de claves desea utilizar para la autenticación. El cliente prueba que tiene acceso a la clave privada y el servidor verifica que la correspondiente clave pública esta autorizada para la cuenta especificada.

Es posible traer la clave pública del usuario «emiliano» desde el sistema «syslocal» utilizando SFTP o SCP, para luego agregarla al archivo .ssh/authorized_keys, aunque es posible utilizar una técnica más interesante.

Volver al sistema «syslocal» logueado como «emiliano» y concatenar la clave pública al archivo ~/.ssh/authorized_keys en el $HOME de «admin» utilizando SSH

[emiliano@syslocal ~]$ cat .ssh/id_dsa.pub | ssh admin@sysremoto «cat >> .ssh/authorized_keys»

De forma alternativa, si el sistema «syslocal» posee un servidor SSH que escucha conexiones remotas, es posible traer la clave ejecutando en «sysremoto»:

[admin@sysremoto ~]$ ssh emiliano@syslocal «cat .ssh/id_dsa.pub» >> .ssh/authorized_keys

Antes de poder probar el mecanismo de autenticación mediante clave pública, es necesario verificar que el servidor SSH lo permita. Para ello, abrir el archivo /etc/ssh/sshd_config:

[admin@sysremoto ~]$ sudo nano /etc/ssh/sshd_config

Verificar que las siguientes líneas estén descomentadas:

PubkeyAuthentication yes
AuthorizedKeysFile .ssh/authorized_keys

Si en lugar de DSA se utilizan claves RSA, será necesario además descomentar la línea:

RSAAuthentication yes

Si se han realizado cambios en el archivo, reiniciar el servidor SSH ejecutando service ssh restart (si es Debian) o service sshd restart (si es Red Hat/CentOS).

Finalmente, es posible verificar la autenticación con clave pública:

[emiliano@syslocal ~]$ ssh admin@sysremoto
Last login: Tue Nov 4 15:54:08 2014 from 192.168.145.123
[admin@sysremoto ~]$

Tal como muestra la captura anterior, se debe poder ingresar sin solicitar el password de «admin».