Guía Keychain en Gentoo Linux

1.  Información de fondo

El problema

Así que tiene todas esas hermosas máquinas Gentoo ejecutando sshd, pero es algo inconveniente tener que constantemente escribir todas esas claves de login, ¿verdad? O tal vez tenga un guión o trabajo programado que requiere una manera conveniente de usar una conexión ssh. De cualquier manera, hay una solución a este problema, comenzando con autenticación con clave pública.

¿Cómo funciona la autenticación con clave pública?

Asumamos que tenemos un cliente que requiere conectarse a un servidor por medio de sshd. El cliente primero genera el par de claves y le entrega la clave pública al servidor. Luego, cuando 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í que como puede haber adivinado, la respuesta correcta conduce a la autenticación exitosa.

2.  ¿Cómo usar la autenticación con clave pública?

Genere su par de claves

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

$ ssh-keygen -t dsa
(Acepte los valores por defecto y asegúrese de ingresar una
contraseña de frase (passphrase) fuerte)

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 archivo ~/.ssh/id_dsa.pub al servidor que corre sshd. Agregaremos la clave al archivo ~/.ssh/authorized_keys del usuario que se conectará a este servidor. Aquí está un ejemplo de cómo hacerlo si ya tiene acceso por vía de ssh al servidor.

$ scp ~/.ssh/id_dsa.pub server_user@server:~/myhost.pub
$ ssh server_user@server "cat ~/myhost.pub >> ~/.ssh/authorized_keys"
$ ssh server_user@server "cat ~/.ssh/authorized_keys"

La salida del comando de la última línea le mostrará el contenido del archivo ~/.ssh/authorized_keys. Revise para ver si está bien.

Probar la configuración

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

$ ssh server_user@server

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

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

3.  Hacer que la autenticación por clave pública sea conveniente

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

Si nos ha seguido la corriente hasta ahora, probablemente piense que sería grandioso si pudiésemos, de alguna manera, descifrar nuestra(s) clave(s) privada una sola vez y así poder usar ssh libremente sin más contraseñas. ¡Es su día de suerte! 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. Funciona creando una conexión (socket) y registrando las variables de entorno apropiadas para que cualquier aplicación posterior pueda aprovechar sus servicios al conectarse a este "enchufe" (socket). Por supuesto, tiene mucho sentido ejecutarlo a nivel del proceso padre de su sesión X si desea usar las claves descifradas en las aplicaciones X posteriores.

$ ssh-agent

Al ejecutar ssh-agent, le notificará del identificador del proceso (PID) y además establecerá valores para algunas variables de entorno como SSH_AUTH_SOCK y SSH_AGENT_PID. Debería también automáticamente agregar ~/.ssh/id_dsa a su propia colección y pedirle la contraseña de frase apropiada. Si tiene otras claves privadas, puede agregarlas al mismo ssh-agent con el comando ssh-add de la siguiente manera:

$ ssh-add somekeyfile

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

$ ssh server

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

$ ssh-agent -k

Si desea aún más comodidad del ssh-agent, proceda a la siguiente sección sobre el uso de keychain. Asegúrese de acabar con el ssh-agent que esté siendo ejecutar tal como 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 ingreso y otro y opcionalmente, pedirle la contraseña de frase cada vez que un usuario haga ingreso. Pero, antes de adelantarnos demasiado, vamos a ejecutar emerge.

# emerge keychain

Asumiendo que esto ocurrió sin problemas, podemos ahora usar keychain libremente. Agregue lo siguiente a su ~/.bash_profile para activarlo:

keychain ~/.ssh/id_dsa
. ~/.keychain/$HOSTNAME-sh

Ahora vamos a probarlo. Primero aseguremos que hemos acabado con el ssh-agent iniciado en la sección anterior e iniciamos un nuevo shell, usualmente haciendo ingreso o abriendo otro terminal. Deberá entonces pedirle la contraseña para cada clave especificada en la línea del comando. Todos los shells abiertos después de este punto deben reutilizar al ssh-agent, permitiéndole realizar conexiones ssh sin contraseña una y otra vez.

Usar keychain con KDE

Si es usuario de KDE, en vez usar ~/.bash_profile le puede dejar a KDE que se encargue del ssh-agent por Ud. Para ello, tendrá que editar tanto el fichero /usr/kde/${KDE_VERSION}/env/agent-startup.sh, el cual es leído al iniciarse KDE, como /usr/kde/${KDE_VERSION}/shutdown/agent-shutdown.sh, el cual es ejecutado en el cierre de KDE, donde ${KDE_VERSION} corresponde a los primeros dos componentes de su instalación de KDE. Por ejemplo, si está usando KDE 3.5.1, le mostraremos cómo se editarían esos archivos:

if [ -x /usr/bin/ssh-agent ]; then
  eval "$(/usr/bin/ssh-agent -s)"
fi

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

Ahora, todo lo que tiene que hacer es iniciar un terminal de su elección, como Konsole, y cargar las claves que le gustaría usar. Por ejemplo:

keychain ~/.ssh/id_dsa
(Ingrese su contraseña de frase)

Sus claves serán recordadas hasta que finalice su sesión de KDE o finalice manualmente el proceso ssh-agent (vía el comando kill).

4.  Comentarios al concluir

Consideraciones de seguridad

Por supuesto, el uso de ssh-agent podrá agregarle un toque de inseguridad a su sistema. Si otro usuario se apoderara de su shell mientras use el baño, pudiese hacer ingreso a todos sus servidores sin contraseña. Como resultado, es un riesgo de seguridad para los servidores a los cuales se conecta, por lo que debiera consultar la política de seguridad local. De hacer uso de ssh-agent, tome las medidas apropiadas para asegurar la seguridad de sus sesiones.

Solución de problemas

La mayoría de lo que hemos visto debe funcionar bien, pero si halla problemas, valdrá la pena conocer 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 ser que no esté usando un shell que entienda los comandos utilizados. Consulte las páginas del manual de ssh-agent y keychain para los detalles de cómo trabajar con otros shells.

El contenido de este documento está registrado bajo los términos de la licencia Creative Commons - Reconocimiento / Compartir Igual