Keychain/es

Este documento describe cómo usar claves compartidas de SSH junto con el programa keychain. Asume un conocimiento básico de criptografía con clave pública.

Descripción del problema
Tener que teclear contraseñas para todos y cada uno de los sistemas es bastante pesado, especialmente si se gestionan muchso sistemas. Algunos administradores podrían echar en falta un guión o trabajo programado que necesita una forma adecuada de utilizar una conexión ssh. De cualquier forma, hay una solución a este problema, que comienza con la autenticación mediante clave pública.

¿Cómo funciona la autenticación con clave pública?
Asumamos que un cliente quiere conectarse al demonio ssh de un servidor. El cliente, en primer lugar, genera un par de claves y le entrega la clave pública al servidor. Después de esto, cada vez que el cliente intente conectarse, el servidor envía un reto cifrado con la clave pública. Solamente el titular de la correspondiente clave privada (el cliente) puede descifrar el reto, así pues, la respuesta correcta conduce a una autenticación exitosa.

Generar un par de claves
El primer paso consiste en crear un par de claves. Para hacer esto, se usa la orden ssh-keygen:

Acepte los valores por defecto y asegúrese de introducir una contraseña (passphrase) robusta.

Una vez haya finalizado la generación, debería aparecer una clave privada en y una clave pública en. La clave pública está ahora preparada para copiarse al equipo remoto.

Preparar el servidor
Se necesita copiar el archivo al servidor lanzando sshd. Se debe añadir al archivo que pertenece al usuario que se conecta al servidor remoto. Una vez se haya concedido acceso ssh al servidor por el personal de infraestructura, se pueden realizar los siguientes pasos para configurar el acceso atuomático usando una clave pública en el servidor remoto:

La salida de la última línea debería mostrar el contenido del fichero. Asegúrese de que la salida es correcta.

Probar la configuración
Teóricamente, si todo ha ido bien y el demonio ssh del servidor lo permite (ya que esto se puede configurar), debería obtener acceso ssh al servidor sin tener que introducir la contraseña. Todavía hace falta descifrar la clave privada en el cliente con la contraseña establecida anteriormente, pero no se debe confundir esto con la contraseña de la cuenta del usuario en el servidor.

Se debería haber pedido una contraseña para, y entonces conceder el acceso vía ssh como el usuario  al servidor. Si no es así, entre como, y verifique que el contenido de  tiene todas las entradas (que representan una clave pública) en una sola línea. También es una buena idea comprobar la configuración de sshd para asegurarse que permite la autorización mediante clave pública cuando está disponible.

En este momento, el lector podría estar pensando "¿Cuál es la gracia? ¡Solo he cambiado una contraseña por otra!" Relájese, en la siguiente sección se muestra exactamente como podemos utilizar esto para introducir la contraseña una vez y reutilizarla (descifrada) varias veces para realizar múltiples accesos.

Gestión típica de claves con ssh-agent
El siguiente paso es descifrar la(s) clave(s) privada(s) una sola vez y así poder usar ssh libremente sin más contraseñas. Eso es exactamente para lo que sirve el programa ssh-agent.

ssh-agent normalmente se inicia al comienzo de la sesión X, o al iniciar una sesión con un guión como. Para funcionar, crea un zócalo (socket) unix y registra las variables de entorno adecuadas para que cualquier aplicación posterior pueda aprovechar sus servicios al conectarse a este zócalo. Por supuesto, solo tiene sentido ejecutarlo en el proceso padre de una sesión X si desea usar las claves privadas descifradas en las aplicaciones X posteriores.

When running ssh-agent</tt>, it should output the PID of the running ssh-agent, and also set a few environment variables, namely  and. It should also automatically add to it's collection and ask the user for the corresponding passphrase. If other private keys exist which need to be added to the running ssh-agent, use the ssh-add</tt> command:

Ahora viene la magia. Con la clave privada descifrada, podrá acceder al servidor (configurado para utilizar clave pública) mediante ssh sin teclear contraseña alguna:

Para apagar ssh-agent (y de este modo se solicitará la contraseña de nuevo más tarde):

Para tener más comodidad al utilizar ssh-agent, proceda a la siguiente sección sobre el uso de keychain. Asegúrese de acabar con el ssh-agent que está corriendo ya que keychain gestiona el mismo la sesiones de ssh-agent</tt>.

Sacar hasta la última gota de comodidad de ssh-agent
Keychain permitirá reutilizar un ssh-agent entre un acceso y otro y opcionalmente, le pedirá la contraseña cada vez que el usuario acceda. Se debe hacer emerge en primer lugar:

Asumiendo que no hubo problemas, se puede ahora utilizar keychain</tt>. Agregue lo siguiente al archivo para habilitarlo:

Now test it. First make sure the ssh-agent processes from the previous section are killed, then start up a new shell, usually by just logging in, or spawning a new terminal. It should prompt for the password for each key specified on the command line. All shells opened after that point should reuse the ssh-agent, allowing to use passwordless ssh connections over and over.

Usar keychain con KDE
KDE users, instead of using, can let KDE manage ssh-agent for them. In order to do so, edit, which is read during KDE's startup, and , which is executed during KDE's shutdown. Here is how one could edit those files:

Ahora, todo lo que se tiene que hacer es lanzar el terminal que se desee, por ejemplo, Konsole, y cargar el conjunto de claves apropiadas que se van a utilizar. Por ejemplo:

Se recordarán las claves hasta que finalice la sesión KDE (o hasta que se termine con el proceso ssh-agent de forma manual).

Consideraciones sobre la seguridad
Of course, the use of ssh-agent may add a bit of insecurity to the system. If another user would gain access to a running shell, he could login to all of the servers without passwords. As a result, it is a risk to the servers, and users should be sure to consult the local security policy (if any). Be sure to take the appropriate measures to ensure the security of all sessions.

Solución de problemas
La mayor parte de esto debería funcionar correctamente, pero si aparecen los problemas, se puede buscar la solución en los siguientes documentos.


 * Si al conectar con ssh-agent</tt> las cosas no parecen funcionar, se puede considerar el uso de ssh con los argumentos  para averiguar qué puede estar sucediendo. A veces es servidor no está configurado para usar autenticación con clave pública, ¡Incluso a veces está configurado para solicitar las claves locales!. Si este es el caso, intente utilizar la opción   con ssh</tt> o cambie el fichero  del servidor.
 * Si al conectar con ssh-agent</tt> o keychain</tt> las cosas no parecen funcionar, entonces puede ocurrir que el intérprete de órdenes actual no comprenda las órdenes utilizadas. Consulte las páginas del manual de ssh-agent y keychain para obtener detalles sobre su funcionamiento en otros intérpretes de órdenes.

Recursos externos

 * Página oficial del proyecto
 * Series de artículos de IBM developerWorks que presentan los conceptos detrás de Keychain