Keychain

Resources

Home

Package information

GitHub

Open Hub

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.

Keychain is a frontend to ssh-agent and ssh-add, allowing long running sessions and letting the user enter passphases just once. It can also be used to allow scripts access to SSH connections.

Conceptos previos

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.

Cómo utilizar la autenticación de clave pública

Generar un par de claves

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

user $ssh-keygen

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

Advertencia
Asegúrese de elegir una contraseña robusta, ¡Especialmente si esta clave se va a utilizar para autenticar al usuario root!

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

Adding or changing a passphrase for the private key can be done as follows:

user $ssh-keygen -p -f ~/.ssh/id_rsa

Preparar el servidor

Se necesita copiar el archivo ~/.ssh/id_rsa.pub al servidor lanzando sshd. Se debe añadir al archivo ~/.ssh/authorized_keys 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:

user $ssh-copy-id usuario_servidor@servidor -i ~/.ssh/id_rsa.pub

ssh-copy-id es un guión envoltorio para realizar estos pasos. Si no se dispone de este guión, entonces se puede serguir estos pasos:

user $scp ~/.ssh/id_rsa.pub usuario_del_servidor@servidor:~/miequipo.pub

user $ssh usuario_del_servidor@servidor "cat ~/miequipo.pub >> ~/.ssh/authorized_keys"

user $ssh usuario_del_servidor@servidor "cat ~/.ssh/authorized_keys"

La salida de la última línea debería mostrar el contenido del fichero ~/.ssh/authorized_keys. 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.

user $ssh <usuario_del_servidor>@<servidor>

Se debería haber pedido una contraseña para id_rsa, y entonces conceder el acceso vía ssh como el usuario <usuario_del_servidor> al servidor. Si no es así, entre como <usuario_del_servidor>, y verifique que el contenido de ~/.ssh/authorized_keys 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.

Hacer que la autenticación por clave pública merezca la pena

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 ~/.bash_profile. 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.

user $eval `ssh-agent`

Nota
Este ssh-agent mantendrá las claves descifradas hasta que acabe con el proceso. Si desea establecer un límite de tiempo de vida para las claves, se usa el argumento -t tal y como se describe en man ssh-agent.

Cuando se corre ssh-agent, se debería motrar el identificador del proceso (PID) además de establecer valores para algunas variables de entorno, en particular, SSH_AUTH_SOCK y SSH_AGENT_PID. Debería también agregar automáticamente ~/.ssh/ir_dsa a su colección y pedirle al usuario la correspondiente contraseña. Si se tienen otras claves privadas que se quieran agregar al ssh-agent que está corriendo, se puede utilizar la orden ssh-add de la siguiente forma:

user $ssh-add algun_fichero_de_claves

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:

user $ssh server

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

user $ssh-agent -k

Nota
Es posible tener varios procesos ssh-agent corriendo, especialmente cuando la configuración inicial necesitó mucho esfuerzo y varias pruebas. Estos procesos se pueden matar igual que cualquier otro proceso lanzando killall ssh-agent.

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:

root #emerge --ask net-misc/keychain

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

Add the following to the shell initialization file (~/.bash_profile, ~/.zshrc, or similar) to enable it:

CÓDIGO Habilitar keychain en .bash_profile

'"`UNIQ--pre-00000001-QINU`"'

ARCHIVO ~/.zshrcEnabling Keychain in zsh

keychain ~/.ssh/id_rsa
. ~/.keychain/${HOST}-sh
. ~/.keychain/${HOST}-sh-gpg

Nota
Si se desea, se pueden agregar más claves privadas a la línea de la orden. Además, si se quiere solicitar la contraseña cada vez que inicie un intérprete de órdenes, agregue la opción --clear.

Nota
Cuándo no se esté usando bash, revise la sección EXAMPLES de man keychain para ver ejemplos de cómo usarlo con otros intérpretes de órdenes. La idea es que estas órdenes se ejecuten cada vez que se utilice un intérprete de órdenes.

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.

All shells opened after that point should reuse the ssh-agent, allowing to use passwordless SSH connections over and over.

Usar keychain con Plasma 5

Los usuarios de Plasma 5, en lugar de utilizar ~/.bash_profile, pueden dejar a Plasma 5 que se encargue del ssh-agent. Para ello, tendrán que editar el fichero /etc/plasma/startup/agent-startup.sh, que se lee durante el inicio de Plasma, y el fichero /etc/plasma/shutdown/10-agent-shutdown.sh, que se ejecuta durante su apagado. A continuación se muestra como podrían editarse estos ficheros:

Here is how one could edit those files:

CÓDIGO Editar /etc/plasma/startup/10-agent-startup.sh

SSH_AGENT=true

CÓDIGO Editar /etc/plasma/shutdown/10-agent-shutdown.sh

if [ -n "${SSH_AGENT_PID}" ]; then
  eval "$(ssh-agent -k)"
fi

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

user $keychain ~/.ssh/id_rsa

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

Alternatively use KWallet with kde-plasma/ksshaskpass under Plasma 5

You can also have Plasma automatically ask you for your passphrase upon desktop login. Emerge kde-plasma/ksshaskpass, which will set up an environment variable to use the ksshaskpass application whenever ssh-add is run outside of a terminal. Then create a script as follows, and install it via the Plasma -> System Settings -> Startup and Shutdown -> Autostart.

ARCHIVO ~/ssh.shCreate ssh.sh script

#!/bin/sh
ssh-add < /dev/null

Nota
Recent versions of plasma seem to require autostart scripts to have user-only permissions. You may need to chmod 700 ssh.sh before adding the script via the Autostart GUI

Comentarios finales

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 -vvv 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 -o con ssh o cambie el fichero sshd_config 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.

See also

• SSH — un programa de terminal cifrado que reemplaza la herramienta clásica telnet en los sistemas operativos tipo Unix., the ubiquitous tool for logging into and working on remote machines securely.

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

---

This page is based on a document formerly found on our main website gentoo.org.
The following people contributed to the original document: Eric Brown, Marcelo Goes,
They are listed here because wiki history does not allow for any external attribution. If you edit the wiki article, please do not add yourself here; your contributions are recorded on each article's associated history page.