ssh-agent, incluido con la distribución de OpenSSH, es un programa especialmente diseñado para manejar las claves RSA y DSA de forma agradable y segura (vea la Parte 1 de esta serie para una introcucción a la validación RSA y DSA.) ssh-agent, a diferencia de ssh, es un servicio diseñado con el único objetivo de almacenar en caché el descifrado de sus claves privadas.

ssh incluye soporte para comunicarse con ssh-agent, permitiendo a ssh adquirir sus claves privadas descifradas sin preguntarle por la contraseña en cada nueva conexión. Simplemente utilice ssh-add para añadir sus claves privadas a la caché de shh-agent. En un único proceso; después de utilizar ssh-add, ssh usará su clave privada desde ssh-agent, en lugar de preguntarle por una contraseña.

Echemos un vistazo a como trabaja todo este sistema de caché de claves con ssh-agent. Al iniciar ssh-agent desde consola, muestra unas variables de entorno importantes antes de desconectarse de la consola y continuar su proceso en segundo plano. He aquí un ejemplo de la salida generada por ssh-agent cuando se inicia:

$ ssh-agent
SSH_AUTH_SOCK=/tmp/ssh-XX4LkMJS/agent.26916; export SSH_AUTH_SOCK;
SSH_AGENT_PID=26917; export SSH_AGENT_PID;
echo Agent pid 26917;

Como puede ver, la salida de ssh-agent es en realidad una serie de comandos en bash; si se ejecutan, estos comandos ajustarías un par de variables de entorno, SSH_AUTH_SOCK y SSH_AGENT_PID. Debido a la inclusión del comando export, estas variables de entorno estarán disponibles para cualquier comando adicional que se lance posteriormente. Bien, todo pasaría si estas líneas fueran evaluadas por la consola, pero ahora solamente se ha enviado a stdout. Para solucionarlo, podemos llamar a ssh-agent como sigue:

$ eval `ssh-agent`

Este comando le dice a bash que lance ssh-agent y evalúe su salida. Invocando de esta forma (con comillas inclinadas, no con comillas simples normales), las variables SSH_AGENT_PID y SSH_AUTH_SOCK serán ajustadas y exportadas por su consola, estando estas variables a disposiciñon de todos los procesos nuevos que se puedan iniciar durante su sesión.

La mejor manera de lanzar ssh-agent es añadir la línea anterior a su ~/.bash_profile; de esta manera, todos los programas iniciados en su sesión verán las variables de entorno, serán capaces de localizar ssh-agent y cosultar claves cuando sea necesario. La variable de entorno particularmente importante es SHH_AUTH_SOCK; contiene un enlace a un socket UNIX que ssh y scp pueden usar para establecer comunicación con ssh-agent.

Por supuesto, ssh-agent se inicia con una caché de claves descifradas vacía. Antes de que podamos utilizar ssh-agent, en primer lugar hay que añadir nuestra(s) clave(s) privada(s) a la caché de ssh-agent utilizando el comando ssh-add. En el siguiente ejemplo uso ssh.add para añadir mi clave privada RSA ~/.ssh/identity a la caché de ssh-agent:

$ ssh-add ~/.ssh/identity
Need passphrase for /home/drobbins/.ssh/identity
Enter passphrase for /home/drobbins/.ssh/identity
(enter passphrase)

Como puede ver, ssh-add pregunta por mi contraseña a fin de que la clave privada pueda ser descifrada y se almacena en la caché de ssh-agent, lista para usar. Una vez que haya usado ssh-add para agregar su clave (o claves) privada a la caché de ssh-agent SSH_AUTH_SOCK se define en su actual consola (debe ser así, si lanzó ssh-agent desde su ~/.bash_profile), entonces ya puede usar ssh y scp para establecer conexiones con sistemas remotos sin suministrar su contraseña.

ssh-agent es realmente cool, pero su configuración por defecto tiene unos pocos inconvenientes. Echemos un vistazo a ellos.

Por uno lado, con eval `ssh-agent` en ~/.bash_profile, una nueva copia de ssh-agent es iniciada cada inicio de sesión; no solamente es un desperdicio, también significa que necesita usar ssh-add para añadir una clave privada para cada nueva copia de ssh-agent. Si solo abre una consola en su sistema, esto no es mayor problema, pero la mayoría de nosotros abrimos un buen número de terminales y es necesario escribir la contraseña cada vez que se abre una nueva consola. Técnicamente, no hay razón por la que debiera ser necesario esto mientras un solo proceso ssh-agent fuera suficiente.

Otro problema por defecto en ssh-agent es que la instalación no es compatible con cron jobs. Los trabajos iniciados por el proceso cron, no heredan la variable de entorno SSH_AUTH_SOCK, y por consiguiente no sabrán que hay un proceso ssh-agent en ejecución ni cómo ponerse en contacto con él. Este problema también es corregible.

Para resolver estos problemas, He escrito un práctico front-end basado en bash llamado keychain. Lo que hace especial a keychain es el hecho de que permite utilizar un solo proceso ssh-agent por sistema, no sólo por sesión. Esto significa que usted sólo tiene que hacer un ssh-add por clave privada, y punto. Como veremos en breve, incluso keychain ayuda a optimizar el proceso ssh-add tratando de añadir solamente las claves privadas que no estén en ejecución en la caché de ssh-agent.

Aquí hay una muestra de como funciona keychain. Cuando se inicia a partir de su ~/.bash_profile, se comprueba en primer lugar si algún ssh-agent se está ejecutando. Si no es así, entonces se iniciará ssh-agent y registrará las importantes variables SSH_AUTH_SOCK y SSH_AGENT_PID en el archivo ~/.ssh-agent para su custodia y posterior uso. Esta es la mejor manera de iniciar keychain; como hicimos con ssh-agent, es necesario realizar la configuración en ~/.bash_profile:

#!/bin/bash
#example ~/.bash_profile file
/usr/bin/keychain ~/.ssh/id_rsa
#redirect ~/.ssh-agent output to /dev/null to zap the annoying
#"Agent PID"; message
source ~/.ssh-agent > /dev/null

Como puede ver, con keychain suministramos al fichero ~/.ssh-agent en lugar de evaluar la salida como cuando usamos ssh-agent directamente. Sin embargo el resultado es el mismo -- nuestra cada vez más importánte variable SSH_AUTH_SOCK es definida, y ssh-agent se está ejecutando y listo para usarse. Y debido a que se registra SSH_AUTH_SOCK en ~/.ssh-agent, nuestros propios scripts y cron jobs pueden conectarse fácilmente con ssh-agent solo con la lectura del archivo ~/.ssh-agent. keychain también se aprovecha de este fichero; recuerde cuando keychain se inició, este comprueba si ssh-agent está ejecutándose. Si es así, se usa el fichero ~/.ssh-agent para adquirir la configuración apropiada de SSH_AUTH_SOCK, por lo tanto le permite utilizar el actual agente en lugar de iniciar uno nuevo. keychain solo iniciará un nuevo proceso ssh-agent sólo si el fichero ~/.ssh-agent está rancio (apunta a un ssh-agent inexistente) o si el mismo ~/.ssh-agent no existe.

La instalación de keychain es fácil. En primer lugar, vaya a la página del proyecto keychain y descarge la versión más reciente disponible de las fuentes de keychain o instale usando emerge, de la siguiente manera:

# emerge keychain

Ahora que keychain esta en /usr/bin/, añada a su ~/.bash_profile, añadiendo la ruta de su clave privada como argumento. Aquí hay una buena configuración para habilitar keychain desde ~/.bash_profile:

#!/bin/bash
#on this next line, we start keychain and point it to the private keys that
#we'd like it to cache
/usr/bin/keychain ~/.ssh/id_rsa ~/.ssh/id_dsa
source ~/.ssh-agent > /dev/null
#sourcing ~/.bashrc is a good thing
source ~/.bashrc

Una vez configurado su ~/.bash_profile para llamar a keychain en cada inicio de sesión, reinicie su sesión, Al hacerlo, keychain iniciará ssh-agent, registrará la configuración de la variable de entorno del agente en ~/.ssh-agent, y le pedirá las contraseñas de las claves privadas especificadas en la linea de comandos keychain en ~/.bash_profile:

$ source ~/.ssh-agent

Después de tener funcionando keychain, asegurese de teclear keychain --help para familiarizarse con todas las opciones de linea de comandos de keychain. Vamos a echar un vistazo a uno en partiular: la opción --clear

Recordará que en la parte 1, expliqué que el uso de claves privadas sin cifrar es una práctica peligrosa, ya que permite a cualquiera robar su clave privada y usarla para acceder a sus cuentas remotas de cualquier sistema sin suministrarle contraseña. Bien, mientras que keychain no es vulnerable a este tipo de abuso (que es siempre y cuando utilice las claves privadas cifradas), hay una debilidad potencialmente explotable directamente relacionada con el hecho que keychain se enganche facilmente a un proceso ssh-agent de larga duración. ¿Que pasaría, pensé, sin algún intruso consiguiera averiguar mi contraseña o frase de acceso a mi sistema local? Si de alguna manera se pudiera acceder bajo mi usuario, keychain les garantizaría el acceso instantáneo a mis claves privadas descifradas, por lo que no es obvio para ellos tener acceso a mis otras cuentas.

Ahora, antes de continuar, vamos a poner este riesgo de seguridad en perspectiva. Si algún usuario malintencionado de alguna manera pudiera validarse como yo, keychain permitiría el acceso a mis cuentas remotas. Sin embargo, aun así, sería muy difícil para el intruso robar mis claves privadas descifradas ya que todavía están encriptadas en el disco. Además, para tener acceso a mis claves privadas requiere que un usuario realmente se valide como yo. Así que, abusar de ssh-agent sería más difícil que simplemente robar una clave privada sin cifrar, que sólo requiere que un intruso acceda de alguna manera a mis ficheros en ~/.ssh, ya sea validado como yo o no. Sin embargo, si un intruso logró acceder en condiciones a validarse como yo, ello supondría que podría hacer un poco más de daño adicional usando mis claves privadas descifradas. Por lo tanto, si usted pasase a estar usando keychain en un servidor que no se validase a menudo o no activamente para controlar las brechas de seguridad, entonces considere utilizar la opción --clear para proporcionar una capa de seguridad adicional.

La opción --clear permite decirle a keychain suponer que cada nuevo acceso a su cuenta debería ser considerado como una potencial brecha en la seguridad hasta que se demuestre lo contrario. Al iniciar keychain con la opción --clear , keychain limpia inmediatamente todas sus claves privadas de la caché de ssh-agent cuando se inicia sesión, antes de realizar sus funciones normales. Por lo tanto, si usted es un intruso, keychain le pedirá las contraseñas en lugar de darle acceso a su actual conjunto de claves en caché. Sin embargo, a pesar de que ello aumenta la seguridad, hace las cosas un poco más incómodas y muy similar a ejecutar ssh-agent por sí solo, sin keychain. En este caso, como suele ser, uno puede optar por una mayor seguridad o mayor comodidad, pero no ambos.

A pesar de ello, utilizando kechain con --clear todavía tiene ventajas sobre el uso de ssh-agent por sí solo; recuerde, cuando se usa keychain --clear, sus cron jobs y scripts seguirán siendo capaces de establecer conexiones sin contraseñas; esto es debido a que sus claves privadas son limpiadas en el acceso, no al salir. Desde un cierre de sesión del sistema no constituye una potencial brecha de seguridad, no hay razón para que keychain limpie las claves de ssh-agent. Por lo tanto, la opción --clear es ideal para los servidores que se acceden con poca frecuencia para llevar a cabo ocacionales tareas de copia de seguridad, tales como backup de los servidores, cortafuegos y routers.

Ahora que la gestión de claves para OpenSSH esta completa, debe estar familiarizado con las claves RSA y DSA y saber como utilizarlas de forma conveniente y segura. Asegúrese de comprobar los siguientes recursos:

• Leer Parte 1 y Parte 3 de la serie de Daniel en gestión de claves para OpenSSH.
• Visite el sitio de desarrollo de OpenSSH
• Obtenga la versión más reciente de keychain
• Revise las OpenSSH FAQ
• PuTTY es un excelente cliente ssh para máquinas Windows
• Puede encontrar el libro de ayuda de O'Reilly "SSH, The Secure Shell: The Definitive Guide". El sitio del Autor contiene información acerca del libro, FAQ, noticias, y actualizaciones.