Keychain

From Gentoo Wiki
Revision as of 12:26, 10 December 2013 by FuzzyBot (Talk | contribs)

Jump to: navigation, search
Other languages:English 100% • ‎español 100% • ‎français 100% • ‎日本語 5% • ‎русский 100%

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.

Conceptos previos

Descripción del problema

Así que tiene todas esas hermosas máquinas Gentoo corriendo sshd, pero supone un pequeño inconveniente tener que escribir constantemente todas esas claves de acceso, ¿verdad? O tal vez tenga un guión o trabajo programado que necesita una forma adecuada de utilizar una conexión ssh. De cualquier manera, 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 tenemos un cliente que quiere conectarse a un servidor que corre sshd. 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, como habrá adivinado, la respuesta correcta conduce a una autenticación exitosa.

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

Genere su par de claves

El primer paso consiste en crear su par de claves. Para hacer esto, usaremos la orden ssh-keygen de la siguiente forma:

user $ ssh-keygen -t dsa

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

Warning
Asegúrese de usar una contraseña robusta, ¡Especialmente si esta clave se usará para autenticar al usuario root!

Ahora debería tener una clave privada en ~/.ssh/id_dsa y una clave pública en ~/.ssh/id_dsa.pub. Estamos listos para copiar la clave pública al servidor remoto.

Preparar el servidor

Copiaremos el fichero ~/.ssh/id_dsa.pub al servidor que corre sshd. También lo añadiremos al fichero ~/.ssh/authorized_keys que pertenece al usuario que se conectará a este servidor. A continuación se muestra un ejemplo de cómo cómo hacerlo si ya tiene acceso ssh al servidor.

user $ scp ~/.ssh/id_dsa.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 le debería mostrar el contenido del fichero ~/.ssh/authorized_keys. Asegúrese de que es correcto.

Probar la configuración

Teóricamente, si todo ha ido bien y el demonio ssh del servidor lo permite, debería obtener acceso ssh sin contraseña en este momento. Todavía hará falta descifrar la clave privada en el cliente con la contraseña que establecimos anteriormente, pero no confunda esto con la contraseña de la cuenta del usuario en el servidor.

user $ ssh usuario_del_servidor@servidor

Esperemos que se le haya solicitado la contraseña para id_dsa y que haya podido obtener acceso ssh al servidor como usuario_del_servidor. Si no, acceda al servidor como usuario_del_servidor y verifique el contenido del archivo ~/.ssh/authorized_keys para asegurarse de que cada entrada está en su propia línea. Quizás también quiera revisar la configuración de sshd para determinar que prefiere utilizar la autenticación mediante clave pública cuando ésta esté disponible.

En este momento, seguro que está pensando "¿Cuál será la gracia? ¡Solo he cambiado una contraseña por otra!" Relájese, en la siguiente sección le mostraré exactamente lo que tiene que hacer para ahorrar su precioso tiempo.

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

Gestión típica de claves con ssh-agent

Si ha llegado hasta aquí, probablemente piense que sería grandioso si pudiésemos, de alguna manera, descifrar nuestra(s) clave(s) privada(s) una sola vez y así poder usar ssh libremente sin más contraseñas. ¡Es afortunado! porque es exactamente para lo que sirve el programa ssh-agent.

El programa ssh-agent normalmente se inicia al comienzo de una 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 su sesión X si desea usar las claves privadas descifradas en las aplicaciones X posteriores.

user $ eval `ssh-agent`
Note
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, use el argumento -t tal y como se describe en man ssh-agent.

Al correr ssh-agent, le debería notificar su 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/id_dsa a su colección y pedirle la correspondiente contraseña. Si tiene otras claves privadas que quiera agregar al ssh-agent que está corriendo, puede utilizar la orden ssh-add de la siguiente forma:

user $ ssh-add algun_fichero_de_claves

Ahora viene la magia. Ya que debe tener lista su clave privada descifrada, podrá acceder al servidor mediante ssh sin teclear contraseña alguna.

user $ ssh server

¿No sería bueno saber cómo parar ssh-agent cuando se necesite?

user $ ssh-agent -k
Note
Si ha tenido algún problema en hacer funcionar ssh-agent, tal vez sea porque sigue corriendo. Puede acabar con él como cualquier otro proceso mediante killall ssh-agent.

Si desea aún más comodidad para 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 tal y como se muestra en el ejemplo anterior, si así lo desea.

Sacar hasta la última gota de comodidad de ssh-agent

Keychain le permitirá reutilizar un ssh-agent entre un acceso y otro y opcionalmente, le pedirá la contraseña cada vez que el usuario acceda. Pero, antes de avanzar demasiado, vamos a correr emerge.

root # emerge --ask keychain

Asumiendo que no hubo problemas, ahora podemos utilizar keychain libremente. Agregue lo siguiente a su ~/.bash_profile para activarlo:

CodeHabilitar keychain en .bash_profile

 
keychain ~/.ssh/id_dsa
. ~/.keychain/$HOSTNAME-sh
. ~/.keychain/$HOSTNAME-sh-gpg
Note
Puede agregar tantas claves privadas como desee a la línea de la orden. Además, si quiere que solicite la contraseña cada vez que inicie un intérprete de órdenes, agregue la opción --clear.
Note
Si no 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 utilice un intérprete de órdenes.

Ahora vamos a probarlo. En primer lugar asegúrese de que ha acabado con el ssh-agent iniciado 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 pedirle 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ía reutilizar a ssh-agent, permitiéndole realizar conexiones ssh sin utilizar contraseña una y otra vez.

Usar keychain con KDE

If you are a KDE user, instead of using ~/.bash_profile , you can let KDE manage ssh-agent for you. In order to do so, you will have to edit /etc/kde/startup/agent-startup.sh , which is read during KDE's startup, and /etc/kde/shutdown/agent-shutdown.sh , which is executed during KDE's shutdown. Here is how you could edit those files:

CodeEditing /etc/kde/startup/agent-startup.sh

if [ -x /usr/bin/ssh-agent ]; then
  eval "$(/usr/bin/ssh-agent -s)"
fi
CodeEditar /etc/kde/shutdown/agent-shutdown.sh

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

Ahora, todo lo que tiene que hacer es iniciar el terminal que desee, por ejemplo, Konsole, y cargar las claves que le gustaría usar. Por ejemplo:

user $ keychain ~/.ssh/id_dsa

Se recordarán sus claves hasta que finalice su sesión de KDE o acabe manualmente con el proceso ssh-agent.

Comentarios finales

Consideraciones sobre la seguridad

Por supuesto, el uso de ssh-agent puede añadir un poco de inseguridad a su sistema. Si alguien utiliza el intérprete de órdenes mientras hemos ido al baño, podría acceder a todos nuestros servidores sin utilizar contraseña alguna. Por tanto, esto es una amenaza para los servidores a los cuales se conecta, por lo que debiera consultar la directriz de seguridad local. Si utilizar ssh-agent, asegúrese de tomar las medidas apropiadas para garantizar la seguridad de sus sesiones.

Solución de problemas

La mayoría de lo que hemos visto debería funcionar correctamente, pero si encuentra algún problema, valdrá la pena recordar algunas cosas útiles.

  • Si no puede conectarse sin ssh-agent, considere usar ssh con el argumento -vvv para averiguar qué está ocurriendo. A veces el servidor no está configurado para hacer uso de autenticación con claves públicas y ¡A veces está configurado para pedir contraseñas locales de todos modos! Si este es el caso, tal vez quiera usar también la opción -o con ssh o cambiar el archivo sshd_config del servidor.
  • Si tiene problemas con ssh-agent o keychain, podría ocurrir que no esté usando un intérprete de órdenes que comprenda las órdenes utilizadas. Consulte las páginas del manual de ssh-agent y de keychain para conocer los detalles de cómo trabajar con otros intérpretes de órdenes.
  • Puede también visitar la página oficial de keychain para recomendaciones de uso.

Agradecimientos

Nos gustaría dar las gracias a los siguientes autores y editores por sus contribuciones a esta guía:


  • Eric Brown
  • Marcelo Goes
  • nightmorph