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 :

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. Se debe añadir al archivo que pertenece al usuario que se conecta al servidor remoto. Una vez se haya concedido acceso 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
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:

Asumiendo que no hubo problemas, se puede ahora utilizar. Agregue lo siguiente al archivo para habilitarlo:

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
Al igual que arriba para KDE 4 pero reemplazando por.

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.


 * Si al conectar con las cosas no parecen funcionar, se puede considerar el uso de ssh con las opciones   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  o cambie el fichero  del servidor.
 * Si al conectar con o  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

 * La página oficial del proyecto Keychain en Funtoo.org
 * Series de artículos de IBM developerWorks que presentan los conceptos detrás de Keychain