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
The first step is to create a key pair. To do this, use the command:

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
The file needs to be copied over to the server running. It has to be added to the file that belongs the connecting user on the remote server. After access to the server has been granted by infrastructure personnel, the following steps can be used to setup automatic login using a public key on the remote server:

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
Theoretically, if all went well, and the daemon on the server allows it (as this can be configured),  access without entering a password should now be possible on the server. The private key on the client will still need to be decrypted with the passphrase used previously, but this should not be confused with the password of the user account on the server.

It should have asked for a passphrase for, and then grant access via as the user   on the server. If not, login as, and verify that the contents of  has each entry (which is a public key) on a single line. It is also a good idea to check the sshd configuration to make sure that it allows to use public key authorization when available.

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
The next step is to decrypt the private key(s) once, and gain the ability to ssh freely, without any passwords. That is exactly what the program is for.

is usually started at the beginning of the X session, or from a shell startup script like. It works by creating a unix-socket, and registering the appropriate environment variables so that all subsequent applications can take advantage of its services by connecting to that socket. Clearly, it only makes sense to start it in the parent process of an X session to use the set of decrypted private keys in all subsequent X applications.

When running, it should output the PID of the running ssh-agent, and also set a few environment variables, namely SSH_AUTH_SOCK and SSH_AGENT_PID. 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 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):

To get even more convenience from ssh-agent, proceed to the next section on using keychain. Be sure to kill the running ssh-agent as keychain will handle the sessions itself.

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:

Assuming that was successful, can now be used. Add the following to the file to enable it:

Ahora se puede probar. En primer lugar asegúrese de que ha acabado con los ssh-agent iniciados en la sección anterior. A continuación iniciamos un nuevo intérprete de órdenes, normalmente accediendo a nuestro sistema o abriendo un nuevo terminal. Debería pedir la contraseña para cada clave especificada en la línea de la orden. Todos los intérpretes de órdenes que se abran a partir de este momento deberían reutilizar el ssh-agent, permitiéndole realizar conexiones ssh sin utilizar contraseña una y otra vez.

Usar keychain con KDE
Los usuarios de KDE, en lugar de utilizar, pueden dejar a KDE que se encargue del ssh-agent. Para ello, tendrán que editar el fichero, que se lee durante el inicio de KDE, y el fichero , que se ejecuta durante el apagado de KDE. A continuación se muestra como podrían editarse estos ficheros:

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).

Usar keychain con Plasma 5
As above for KDE 4 except replace with.

Consideraciones sobre la seguridad
Por supuesto, el uso de ssh-agent puede añadir un poco de inseguridad al sistema. Si otro usuario obtiene acceso al intérprete de órdenes, podría acceder a todos los servidores sin utilizar contraseña alguna. Por tanto, esto es una amenaza para los servidores a los cuales se conecta, por lo que se debería consultar la directriz de seguridad local (si existe alguna). Asegúrese de tomar las medidas apropiadas para asegurar todas las sesiones.

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.


 * If connecting without does not seem to work, consider using ssh with the   options to find out what's happening. Sometimes the server is not configured to use public key authentication, sometimes it is configured to ask for local passwords anyway! If that is the case, try using the   option with, or change the server's.
 * If connecting with or  does not seem to work, then it may be that the current shell does not understand the commands used. Consult the man pages for ssh-agent and keychain for details on working with other shells.

Recursos externos

 * The official Keychain project page at Funtoo.org.
 * IBM developerWorks article series introducing the concepts behind Keychain.