Configuración de claves públicas y privadas para establecer conexiones SSH sin autenticación
Evitar introducir la contraseña es totalmente posible, para ciertos casos de automatización podemos utilizar el intérprete expect que ya vimos en ésta entrada, pero también podemos configurar nuestro servicio SSH para que acepte llaves conocidas como veremos a continuación.
El concepto básico tras la autenticación SSH sin introducción de contraseñas consiste en crear llaves públicas y privadas con un usuario en un equipo de ejemplo que denominaremos de aquí en adelante Equipo A, donde la llave pública es la que se comparte con un usuario de otro equipo de ejemplo llamado Equipo B al cual nos deseamos conectar, y la llave privada es la que nos queda como clave de autenticación.
Cuando el usuario del Equipo A intente conectarse mediante el protocolo SSH con un usuario del sistema operativo del Equipo B, el primero le enviará su llave privada, al recibir la llave privada el Equipo B evaluará si la llave recibida coincide con su contrapartida llave pública recibida anteriormente por otros canales (o por el mismo), si el cálculo matemático de comprobación entre las dos llaves coincide entonces se confirma la autenticación, en caso contrario la misma se rechaza.
Todo un embrollo no? pues bien, a continuación veremos los pasos prácticos a seguir para configurar un escenario similar al expuesto anteriormente.
Configuraciones en el Equipo A
- Como el usuario admin del Equipo A es el que quiere loguearse al Equipo B con el usuario backup para pasarle de forma automatizada vía SSH las copias de seguridad generadas durante el día, éste deberá generar su llave pública y privada desde la línea de comandos ejecutando el siguiente comando:
admin@equipo_a:~> ssh-keygen -t dsa
OBS: Durante la ejecución del comando ssh-keygen éste nos solicitará introducir información adicional para generar la lleve, como la misma es alternativa podemos obviarla presionando la tecla enter para avanzar.
Generating public/private dsa key pair.
Enter file in which to save the key (/home/admin/.ssh/id_dsa):
Enter passphrase (empty for no passphrase):
Enter same passphrase again:
Your identification has been saved in /home/admin/.ssh/id_dsa.
Your public key has been saved in /home/admin/.ssh/id_dsa.pub.
The key fingerprint is:
9c:8d:21:1d:a6:27:d9:d9:01:11:9f:55:b0:09:4c:ec admin@equipo_a.testnet.local
The key's randomart image is:
+--[ DSA 1024]----+
| *B+ oo. |
| * =o= o |
| = *.+ o |
| = =E |
| S . |
| |
| |
| |
| |
+-----------------+
admin@equipo_a:~> - En el directorio oculto .ssh del home de nuestro usuario se generarán dos archivos conteniendo las dos llaves, por un lado el archivo id_dsa contendrá la llave privada y el archivo id_dsa.pub la llave pública que puede ser compartida. Esto lo podemos verificar ejecutando el siguiente comando:
admin@equipo_a:~> ls -l ~/.ssh
total 12
-rw------- 1 admin users 672 sep 8 21:27 id_dsa
-rw-r--r-- 1 admin users 618 sep 8 21:27 id_dsa.pub
-rw-r--r-- 1 admin users 2312 ago 13 17:40 known_hosts
admin@equipo_a:~> - Con el primer paso ya hemos generado la llave pública y privada del usuario admin del Equipo A, ahora solo nos resta pasarle nuestra llave pública al usuario backup del Equipo B remoto. Esto lo podemos hacer de varias formas, copiando la llave pública en un pendrive, enviándola mediante e-mail (no muy seguro), o como veremos a continuación a través del propio protocolo SSH (aún introduciendo la contraseña del usuario de destino):
admin@equipo_a:~> scp ~/.ssh/id_dsa.pub backup@equipo_b:/home/backup/id_dsa.pub.equipo_a
Y eso ha sido todo desde el Equipo A hasta el momento, las siguientes configuraciones se tienen que realizar en el equipo al cual nos queremos conectar, osea el Equipo B.
Password:
id_dsa.pub 100% 618 0.6KB/s 00:00
admin@equipo_a:~>
Configuraciones en el Equipo B
Para que la llave pública que nos enviaron desde el Equipo A sirva de algo tenemos que hacer lo siguiente:- Lo primero que tiene que hacer conectados con el usuario backup en el Equipo B es verificar que cuente con la estructura necesaria en su directorio home para albergar las configuraciones requeridas. Para ello comenzamos por verificar que el directorio .ssh exista en el directorio home, y si no existe aún lo creamos de la siguiente forma.
backup@equipo_b:~> mkdir ~/.ssh
- Ahora, para que el usuario admin del Equipo A no necesite introducir la contraseña cada vez que intente conectarse con el usuario backup es necesario copiar la llave pública contenida en el archivo id_dsa.pub.equipo_a al archivo authorized_keys2 del usuario backup.
backup@equipo_b:~> cat ~/id_dsa.pub.equipo_a >> ~/.ssh/authorized_keys2
- Por último le aplicamos los permisos correspondientes al directorio ~/.ssh y si queremos eliminamos el archivo id_dsa.pub.equipo_a que ya no será necesario.
backup@equipo_b:~> chmod 700 ~/.ssh
Y listo, esos son todos los pasos que deben ser realizados en el Equipo B.
backup@equipo_b:~> rm ~/id_dsa.pub.equipo_a
Prueba de conexión
Con la configuración anterior ya deberíamos poder conectarnos desde el usuario admin del Equipo A al Equipo B con el usuario backup sin que éste nos solicite introducir la contraseña. Esto lo podemos comprobar ejecutando lo siguiente:admin@equipo_a:~> ssh backup@equipo_bDesde ahora en más ya no necesitaremos introducir la contraseña como quedó patente en el ejemplo anterior, podremos copiar archivos con el comando SCP desde scripts automatizados sin que nos solicite la contraseña. Sin embargo, nunca se olviden de comprobar cada cierto tiempo que la autenticación sin contraseña siga funcionando correctamente, a menos que tus scripts de automatización tengan la forma de identificar el fallo e informarlo debidamente.
Last login: Sun Sep 8 22:19:51 2013 from equipo_a
Have a lot of fun...
backup@equipo_b:~>
Comentarios
Publicar un comentario