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

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

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.

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

Using keychain with 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.


 * Si al conectar con ssh-agent 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 ssh o cambie el fichero  del servidor.
 * Si al conectar con ssh-agent o keychain 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

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