Uso de ssh sin contraseña: claves pública y privada (RSA y DSA)


Vamos a seguir los pasos indicados en los dos siguientes articulos de IBM para garantizar el acceso del usuario suau en la maquina psuau.dominio.es a la maquina correo.prueba como usuario psuau, sin necesidad de introducir ninguna contraseña:

http://www-106.ibm.com/developerworks/library/l-keyc.html

http://www-106.ibm.com/developerworks/library/l-keyc2/


Los protocolos RSA y DSA estan basados en clave publica y clave privada para el acceso mediante ssh. Mientras que el protocolo 1 de ssh tan solo soporta RSA, el protocolo 2 soporta tanto RSA como DSA. Por lo tanto, haremos las pruebas con el protocolo RSA (los cambios para usar DSA son minimos y se explicarán llegado el momento).


Generación de la clave pública y privada


Entramos en el sistema local (psuau.dominio.es) como usuario 'suau', y tecleamos ssh-keygen. Se nos pedirá una localización para guardar tanto la clave pública como la privada (dejamos esas localizaciones por defecto), y una contraseña para la clave privada.

Si quisieramos usar el protocolo DSA tan solo tendriamos que haber tecleado ssh-keygen -t dsa.

Tras generar las claves, tendremos la clave privada en /home/suau/.ssh/identity y la clave pública en /home/suau/.ssh/identity.pub.


Instalación de la clave pública


Deberemos copiar remotamente el fichero de clave pública en correo.prueba. Para ello deberemos utilizar el comando scp:

scp /home/suau/.ssh/identity.pub suau@correo.prueba:


Con esto quedará copiada la clave pública en el directorio HOME de suau en la máquina correo.prueba. El último paso será introducir esta clave pública al final del fichero /home/suau/.ssh/authorized_keys en correo.prueba

ssh correo.prueba -l psuau

cat identity.pub >> /home/psuau/.ssh/authorized_keys


En el caso de DSA, el archivo de clave pública deberá ser incluido al final de authorized_keys2.


Qué hacer si no funciona


Lo primero a probar será a ejecutar ssh con el parámetro -1, de tal forma que se obligue a usar el protocolo 1. También se deberá comprobar que tanto en la máquina cliente en /etc/ssh/ssh_config como en la maquina servidor en /etc/ssh/sshd_config la opción RSAAuthentication debe tener el valor yes. Para las últimas versiones de OpenSSH lo mejor es utilizar DSA. En la máquina cliente se deberá comprobar que en /etc/ssh/ssh_config la directiva IdentifyFile se encuentra seguida del nombre del archivo donde se encuentre la clave privada.


Utilizando ssh-agent


ssh-agent es un demonio (al contrario que ssh) que tiene el objetivo de cachear las claves privadas. Ssh se puede comunicar con ssh-agent para obtener las contraseñas de las claves privadas, de tal forma que no se nos deba pedir uan contraseña cada vez que accedamos al servidor.

Al ejecutar ssh-agent se crean unas variables de entorno (lo ideal, por tanto, es ejecutarlo en el .bash_profile correspondiente). Para añadir una clave privada a ssh-agent utilizamos el comando ssh-add, de la siguiente forma:

ssh-add /home/psuau/.ssh/identity (o el correspondiente archivo de clave privada).


Sin embargo, ssh-agent tiene dos problemas principales:


Keychain


Tal como dice el artículo de IBM, para evitar estos problemas también podemos usar la utilidad keychain, que inicia un proceso de ssh-agent por sistema, no por sesión. Sin embargo, sigue sin ser más que una mera caché de passwords de claves privadas, por lo que en algún momento se deberá inrtoducir la contraseña, que a partir de ese momento quedará en la caché y no tendrá por qué volver a ser introducida.


Conclusiones


Para asegurarnos de que se pueda realizar un login mediante ssh deberemos crear una clave privada sin contraseña. En caso contrario, a pesar de las utilidades ssh-agent y keychain, deberemos introducirla en algun momento, aunque solo sea necesario hacerlo una vez.


Anexos



Ambos ejemplos utilizan el protocolo DSA.



[VOLVER]