Gestión de claves para OpenSSH, Parte 21. Presentando ssh-agent y keychain 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 introducció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 la 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:
Como puede ver, la salida de ssh-agent es en realidad una serie de comandos en bash; si se ejecutan, estos comandos ajustarían 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. Bueno, todo esto 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:
Este comando le dice a bash que lance ssh-agent y evalúe su salida. Invocando de esta forma (con comillas inclinadas hacia atrás, no con comillas simples normales), las variables SSH_AGENT_PID y SSH_AUTH_SOCK serán ajustadas y exportadas por su consola, estando a disposición de todos los procesos nuevos que se puedan iniciar durante la 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 consultar 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:
Como puede ver, ssh-add pregunta por mi contraseña para 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 inició 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 útil, pero su configuración predeterminada 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 sólo 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 único proceso ssh-agent fuera suficiente. Otro problema por defecto en ssh-agent es que la instalación no es compatible con tareas cron. Los trabajos iniciados por 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 único 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í, se iniciará ssh-agent y registrará las importantes variables SSH_AUTH_SOCK y SSH_AGENT_PID en el archivo ~/.keychain/<nombredeservidor>-sh 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:
Como puede ver, con keychain suministramos al fichero ~/.keychain/<nombredeservidor>-sh en lugar de evaluar la salida como cuando usamos ssh-agent directamente. Sin embargo el resultado es el mismo -- nuestra cada vez más importante variable SSH_AUTH_SOCK es definida, y ssh-agent se está ejecutando y listo para usarse. Debido a que se registra SSH_AUTH_SOCK en ~/.keychain/, nuestros propios guiones y tareas cron pueden conectar fácilmente con ssh-agent sólo con la lectura del archivo ~/.keychain/<nombredeservidor>-sh. keychain también aprovecha este fichero; recuerde cuando keychain se inició, este comprueba si ssh-agent está ejecutándose. Si es así, se usa el fichero ~/.keychain/ apropiado para adquirir la configuración correcta de SSH_AUTH_SOCK, por lo tanto le permite utilizar el actual agente en lugar de iniciar uno nuevo. keychain iniciará un nuevo proceso ssh-agent sólo si el fichero ~/.keychain/ no está en condiciones (esto es, apunta a un ssh-agent inexistente) o si el propio ~/.keychain/ no existe. La instalación de keychain es fácil:
Ahora que keychain está 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:
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 ~/.keychain, y le pedirá las contraseñas de las claves privadas especificadas en la linea de comandos keychain en ~/.bash_profile:
Una vez introducida la contraseña, las claves privadas se almacenarán en caché, y keychain finalizará. Entonces, se cargará ~/.keychain/<nombredeservidor>-sh inicializando su sesión para ser usada con ssh-agent. Ahora, si reinicia su sesión nuevamente, notará que keychain encontrará ssh-agent como proceso existente; que no finalizó cuando cerró su sesión. Además, keychain verificará que las claves privadas especificadas están listas en la caché de ssh-agent. Si no es así, entonces le pedirá la contraseña, pero si todo va bien, su actual ssh-agent todavía contendrá la clave privada que previamente añadió, lo que significa que no se le preguntará por una contraseña:
Felicidades, acaba de iniciar sesión y debería ser capaz de usar ssh y scp en sistemas remotos; no necesita usar ssh-add después de iniciar la sesión, y ssh y scp no le pedirán una contraseña. De hecho, siempre y cuando el proceso inicial ssh-agent siga en marcha, podrá acceder y establecer conexiones ssh sin suministrar una contraseña. Y es muy probable que su proceso ssh-agent continue ejecutándose hasta que la máquina sea reiniciada; probablemente lo configure en un sistema Linux, ¡es posible que no sea necesario que introduzca su contraseña en varios meses!. Bienvenido al mundo de la seguridad, conexiones libres de contraseñas usando la validación RSA y DSA. Adelante, cree varias sesiones nuevas, y verá que keychain "enganchará"; al mismo proceso ssh-agent cada vez. No hay que olvidar que puede enganchar sus cron jobs y scripts al proceso ssh-agent en ejecución. Para utilizar los comandos ssh o scp desde scripts de consola y trabajos cron, asegúrese de que obtiene su fichero ~/.keychain/<nombredeservidor>-shell en primer lugar:
Luego, cualquier comando ssh o scp serán capaces de encontrar el actual proceso ssh-agent en ejecución y establecer una conexión segura libre de contraseñas igual que desde la consola. Después de tener funcionando keychain, asegúrese de teclear keychain --help para familiarizarse con todas las opciones de línea de comandos de keychain. Vamos a echar un vistazo a uno en particular: 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 fácilmente 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, lo que no es tan 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 si 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 si 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 ocasionales 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:
|
|
