SSH Keys (Español)
Las claves SSH sirven como un medio para autenticarse ante un servidor SSH usando criptografía de clave pública y protocolos desafío-respuesta. Una ventaja inmediata de este método sobre la tradicional autenticación por contraseñas es que usted será autenticado por el servidor incluso sin tener que enviar su contraseña por la red. Quienes espíen en su conexión no serán capaces de interceptar ni crackear su contraseña ya que nunca es transmitida. Además, el uso de claves SSH para la autenticación virtualmente elimina el riesgo planteado por los ataques a las contraseñas mediante el método de fuerza bruta al disminuir drásticamente las oportunidades de que el atacante descubra las credenciales apropiadas.
Además de ofrecer seguridad adicional, la autenticación por claves SSH puede ser más conveniente que la autenticación tradicional por contraseñas. Cuando se usan con un programa conocido como SSH agent, las claves SSH le permiten conectarse a un servidor, o a múltiples servidores, sin tener que recordar o ingresar su contraseña en cada sistema.
Las claves SSH poseen algunas desventajas y no son la solución adecuada para todos los ámbitos, pero en muchas circunstancias pueden ofrecer muchas ventajas muy importantes. Una comprensión general de como funcionan las claves SSH le ayudará a decidir cómo y cuándo usarlas para cubrir sus necesidades. Ese artículo supone que usted posee algunos conocimientos acerca del protocolo de shell seguro y tiene instalado el paquete openssh, disponible en los Repositorios oficiales.
Contents
1 Introducción
Las claves SSH siempren vienen en pares, una clave privada y otra pública. La clave privada es conocida sólo por su dueño y debería estar guardada en forma secreta, Por lo contrario, la clave pública puede ser compartida libremente con cualquier servidor SSH.
Cuando un servidor SSH dispone de su clave pública en un archivo y ve sus peticiones de conexión, usará su clave pública para construir y enviarle a usted un desafío. Este desafío es similar a un mensaje codificado y debe ser contestado con la respuesta correcta para que el servidor le garantice el acceso. Lo que convierte a este mensaje codificado en particularmente seguro es que solamente puede ser comprendido por alguien con la clave privada. Mientras que la clave pública puede ser usada para encriptar el mensaje, no puede ser usada para descifrarlo. Solamente usted, quien posee la clave privada será capaz de comprender correctamente al desafío y responderlo acertadamente.
Esta fase de desafío-respuesta sucede detrás de escena y es invisible al usuario. Siempre y cuando disponga de la clave privada, que se almacena generalmente en el directorio ~/.ssh/, su cliente SSH debería ser capaz de responder apropiadamente al servidor.
Debido a que las claves privadas se consideran información sensible, a menudo se almacenan cifradas. En este caso, cuando se requiera la clave privada, se debe introducir primero una frase de contraseña para desencriptarla. Aunque esto puede parecer, a primera vista, similar a introducir una contraseña de inicio de sesión en el servidor de SSH, sólo se utiliza para descifrar la clave privada en el sistema local. Esta frase de contraseña no es, y no debe, ser transmitida por la red.
2 Generación de un par de claves SSH
Un par de claves SSH se puede generar ejecutando el comando ssh-keygen:
$ ssh-keygen -b 521 -t ecdsa -C"$(id -un)@$(hostname)-$(date --rfc-3339=date)"
Generating public/private ecdsa key pair. Enter file in which to save the key (/home/username/.ssh/id_ecdsa): Enter passphrase (empty for no passphrase): Enter same passphrase again: Your identification has been saved in /home/username/.ssh/id_ecdsa. Your public key has been saved in /home/username/.ssh/id_ecdsa.pub. The key fingerprint is: dd:15:ee:24:20:14:11:01:b8:72:a2:0f:99:4c:79:7f username@localhost-2011-12-22 The key's randomart image is: +--[ECDSA 521]---+ | ..oB=. . | | . . . . . | | . . . + | | oo.o . . = | |o+.+. S . . . | |=. . E | | o . | | . | | | +-----------------+
En el ejemplo anterior, ssh-keygen genera un par de claves pública/privada ECDSA (-t ecdsa) de 521 bits (-b 521) de longitud con un comentario extendido que incluye los datos (-C"$(id -un)"@$(hostname)-$(date --rfc-3339=date)). La imagen randomart fue introducida en OpenSSH 5.1 como una manera más sencilla de identificar visualmente la huella digital de la clave.
2.1 Elección del tipo de cifrado
El algoritmo de firma digital de curva elíptica (ECDSA) brinda un menor tamaño de claves y operaciones más veloces para un nivel de seguridad similar al de los métodos previos. Se convirtió en el algoritmo preferido para autenticación a partir de OpenSSH 5.7, vea las OpenSSH 5.7 notas de lanzamiento. Las claves ECDSA pueden ser incompatibles con sistemas que utilizan versiones antiguas de OpenSSH. Algunos vendedores también deshabilitan las implementaciones requeridas debido a potenciales conflictos de patentes.
Si decide crear un par de claves RSA (2048-4096 bit) o DSA (1024 bit) en lugar de ECDSA, use -t rsa o -t dsa en el comando ssh-keygen y no olvide de aumentar el tamaño de la clave. Ejecutar la opción predeterminada ssh-keygen sin -b es una elección razonable.
2.2 Elección de la localizacion de la clave y de la frase de contraseña
Al ejecutar el comando ssh-keygen, se le preguntará por el nombre deseado y el directorio en donde almacenar su clave privada. Las claves se almacenan en forma predeterminada en ~/.ssh/ y se denominan de acuerdo al tipo de cifrado usado. Se le aconseja que acepte el nombre y la ubicación predeterminados para que los ejemplos de código posteriores en este artículo funcionen correctamente.
Cuando le pidan una frase de contraseña, elija una difícil de adivinar para mantener segura su clave privada. Una contraseña más larga, más azarosa, generalmente será más robusta y un hueso duro de roer en caso de caer en las manos equivocadas.
También es posible crear su clave privada sin una frase de contraseña. Aunque esto puede ser conveniente, debe ser consciente de los riesgos asociados. Sin una frase de contraseña, su clave privada será almacenada sin cifrar en un disco. Cualquier persona que tenga acceso a su clave privada podrá asumir su identidad en cualquier servidor al cual usted se conecta usando la autenticación basada en claves. Además, sin una frase de contraseña, también deberá confiar en el usuario root, ya que puede pasar por alto los permisos de archivo y será capaz de acceder a su archivo de clave privada sin cifrar en cualquier momento.
3 Envío de la clave pública a un servidor remoto
Una vez generado el par de claves, necesitará enviar la clave pública a un servidor remoto para poder usar la clave de autenticación SSH. El archivo de clave pública comparte el mismo nombre que la clave privada excepto que se le agrega la extensión .pub. Note que la clave privada no es compartida y debe permanecer en su máquina local.
3.1 Método simple
Si su archivo de clave es ~/.ssh/id_rsa.pub simplemente ingrese el siguiente comando.
$ ssh-copy-id remote-server.org
Si su nombre de usuario difiere en la máquina remota, asegúrese de adosarlo seguido de una @ al nombre del servidor.
$ ssh-copy-id username@remote-server.org
Si su nombre de archivo de la clave pública es diferente al predeterminado ~/.ssh/id_rsa.pub obtendrá un error /usr/bin/ssh-copy-id: ERROR: No identities found. En este caso, debe añadirlo.
$ ssh-copy-id -i ~/.ssh/id_ecdsa.pub username@remote-server.org
Si el servidor ssh está escuchando en un puerto diferente el predeterminado (22), asegúrese de incluirlo.
$ ssh-copy-id -i ~/.ssh/id_rsa.pub '-p 221 username@remote-server.org'
3.2 Método tradicional
Por defecto, para OpenSSH, la clave pública necesita ser concatenada con ~/.ssh/authorized_keys. Comience copiando la clave pública al servidor remoto.
$ scp ~/.ssh/id_ecdsa.pub username@remote-server.org:
El ejemplo anterior copia la clave pública (id_ecdsa.pub) a su directorio home en el servidor remoto via scp. No olvide incluir : al final de la dirección del servidor. También advierta que el nombre de su clave pública puede diferir del ejemplo dado.
En el servidor remoto, necesitará crear el directorio ~/.ssh si no existe aún y agregue su clave pública en el archivo authorized_keys.
$ ssh username@remote-server.org username@remote-server.org's password: $ mkdir ~/.ssh $ cat ~/id_ecdsa.pub >> ~/.ssh/authorized_keys $ rm ~/id_ecdsa.pub $ chmod 600 ~/.ssh/authorized_keys
Los dos últimos comandos removerán el archivo de la clave pública del servidor y configurarán los permisos del archivo authorized_keys para que solamente su dueño pueda leer y escribir en ellos.
3.3 Asegurando el archivo de claves autorizadas
Podrá proteger mejor el archivo authorized_keys de las modificaciones cambiando sus permisos. Cree un grupo, por ejemplo, sshusers, agréguele un usuario (john), y dele al archivo authorized_keys permisos de lectura solamente al grupo. En ese caso, el dueño sería el usuario root y su grupo, sshusers. De esta forma, si su cuenta de usuario es comprometida de alguna manera, el atacante no podrá cambiar el archivo authorized_keys sin contraseña de root. Como root, ejecute los siguientes comandos:
$ groupadd sshusers $ gpasswd -a john sshusers $ chown root:sshusers /home/john/.ssh/authorized_keys $ chmod 050 /home/john/.ssh/authorized_keys
Note que, si no necesita a su usuario para escribir en el directorio .ssh (usted no necesita escribir en known_hosts, por ejemplo), puede restringir .ssh en esta manera. Esto resulta muy útil si el servidor está siendo usado para un propósito restringido, por ejemplo, backups.
Desconéctese del servidor e intente reconectarse: debería pedirle la frase de contraseña de la clave.
$ ssh username@remote-server.org Enter passphrase for key '/home/username/.ssh/id_ecdsa':
Si es incapaz de ingresar con la clave, verifique los permisos del archivo authorized_keys.
Revise también los permisos del directorio ~/.ssh, el cual no debería tener permisos de escritura para 'grupo' y 'otros'. Ejecute el siguiente comando para deshabilitarlos.
$ chmod go-w ~/.ssh
4 Deshabilitando el acceso con contraseñas
Aunque copiar su clave pública al servidor remoto SSH elimina la necesidad de transmitir su contraseña por la red, no le brinda protección adicional alguna contra un ataque de fuerza bruta sobre la contraseña. En ausencia de una clave privada, el servidor volverá a la autenticación predeterminada por contraseñas, permitiendo así que un usuario malintencionado pueda obtener acceso si logra adivinarla. Para desactivar este comportamiento, edite las siguientes líneas en el archivo /etc/ssh/sshd_config en el servidor remoto.
/etc/ssh/sshd_config
PasswordAuthentication no ChallengeResponseAuthentication no
5 Agentes SSH
Si su clave privada está cifrada con una frase de contraseña, deberá ingresarla cada ves que se conecte al servidor SSH usando autenticación por clave pública. Cada invocación individual de ssh o scp necesitará de la frase de contraseña para desencriptar su clave privada antes de proceder con la autenticación.
Un agente SSH es un programa que almacena su clave privada desencriptada y se la pasa al cliente SSH en nombre suyo. En este esquema, sólo deberá ingresar la frase de contraseña una vez, cuando agregue su clave privada al agente SSH. Esto puede ser muy conveniente cuando realice conexiones frecuentes de SSH.
Un agente se configura típicamente para ejecutar en forma automática el inicio de sesión y persistir mientras dure la sesión. Para esto, existe una gran variedad de agentes, interfaces y configuraciones. Esta sección brinda un resumen de varios soluciones diferentes que pueden ser adaptadas según sus necesidades específicas.
5.1 ssh-agent
ssh-agent es el agente predeterminado incluido con OpenSSH. Puede usarse directamente o servir como un back-end para unas cuantas interfaces mencionadas más adelante en esta sección. Cuando ssh-agent corra, se bifurcará a sí mismo en un segundo plano e imprimirá las variables de entorno.
$ ssh-agent SSH_AUTH_SOCK=/tmp/ssh-vEGjCM2147/agent.2147; export SSH_AUTH_SOCK; SSH_AGENT_PID=2148; export SSH_AGENT_PID; echo Agent pid 2148;
Para hacer uso de estas variables, ejecute ssh-agent a través del comando eval.
$ eval $(ssh-agent) Agent pid 2157
Podrá añadir el comando anterior a su script de ~/.bash_profile script para que se ejecute automáticamente cuando inicie un login shell.
$ echo 'eval $(ssh-agent)' >> ~/.bash_profile
Si prefiere ejcuter automáticamente ssh-agent run para todos los usuarios agregue el comando /etc/profile.
# echo 'eval $(ssh-agent)' >> /etc/profile
Una vez en funcionamiento ssh-agent, necesitará agregarle su clave privada.
$ ssh-add ~/.ssh/id_ecdsa Enter passphrase for /home/user/.ssh/id_ecdsa: Identity added: /home/user/.ssh/id_ecdsa (/home/user/.ssh/id_ecdsa)
Para añadir automáticamente su clave privada al inicio de sesión, agregue el siguiente comando a su ~/.bash_profile.
$ echo 'ssh-add' >> ~/.bash_profile
Si su clave privada está cifrada ssh-add le pedirá que ingrese su frase de contraseña. Después de hacerlo, podrá establecer conexiones SSH sin necesidad de ingresarla.
Un aspecto negativo de esta aproximación es que se crea una nueva instancia de ssh-agent por cada login shell y cada instancia persistirá entre sesiones. Con el transcurso del tiempo tendrá docenas de procesos ssh-agent innecesarios en ejecución. Existen varias interfaces para ssh-agent y agentes alternativos descritos posteriormente es esta sección que solucionan este inconveniente.
5.2 Agente GnuPG
El agente GnuPG, distribuido con el paquete gnupg, disponible en los repositorios oficiales, dispone de emulación del agente OpenSSH. Si usa GPG considere usar este agente para proteger todas sus claves. Por otra parte quizás le agrade el cuadro de diálogo para ingresar el PIN que proporciona y su gestión de frases de contraseña, que es diferente de Keychain.
Para usar el agente GPG para sus claves SSH ejecute gpg-agent con la opción --enable-ssh-support. Por ejemplo (no olvide darle permisos de ejecución al archivo):
/etc/profile.d/gpg-agent.sh
#!/bin/sh
# Start the GnuPG agent and enable OpenSSH agent emulation
gnupginf="${HOME}/.gpg-agent-info"
if pgrep -u "${USER}" gpg-agent >/dev/null 2>&1; then
eval `cat $gnupginf`
eval `cut -d= -f1 $gnupginf | xargs echo export`
else
eval `gpg-agent -s --enable-ssh-support --daemon`
fi
Una vez que gpg-agent se esté ejecutando podrá usar ssh-add para aprobar claves, como hizo con el agente ssh. La lista de claves aprobadas se almacena en el archivo ~/.gnupg/sshcontrol. Una vez aprobada la clave le aparecerá un cuadro de diálogo para ingresar el PIN cada vez que necesite su frase de contraseña. Es posible controlar las frases de contraseña almacenadas en el archivo ~/.gnupg/gpg-agent.conf. El siguiente ejemplo almacena en el agente gpg su clave por 3 horas:
# Cache settings default-cache-ttl 10800 default-cache-ttl-ssh 10800
Otras configuraciones útiles para este archivo incluyen el programa de ingreso del PIN (para GTK, QT o ncurses), captura por teclado y así sucesivamente...:
# Environment file write-env-file /home/username/.gpg-agent-info # Keyboard control #no-grab # PIN entry program #pinentry-program /usr/bin/pinentry-curses #pinentry-program /usr/bin/pinentry-qt4 #pinentry-program /usr/bin/pinentry-kwallet pinentry-program /usr/bin/pinentry-gtk-2
5.3 Keychain
Keychain es un programa diseñado para ayudar al usuario a administrar más fácilmente sus claves SSH. Está implementado como un shell script que maneja ssh-agent y ssh-add. Una característica notable de Keychain es que puede mantener un proceso simple de ssh-agent a través de múltiples sesiones. Esto significa que solo necesita ingresar su frase de contraseña una vez con cada booteo de la máquina.
Instale el paquete keychain, disponible en los repositorios oficiales.
Agregue la siguiente líne a ~/.bash_profile, o cree /etc/profile.d/keychain.sh como root y hágalo ejecutable (por ejemplo chmod 755 keychain.sh):
~/.bash_profile
eval $(keychain --eval --agents ssh -Q --quiet id_ecdsa)
En el ejemplo anterior, --eval produce líneas para ser evaluadas al abrir el comando {{ic|eval}. Esto configura las variables de entorno necesarias para que el cliente SSH pueda encontrar a su agente. No es estrictamente necesario --agents, porque Keychain construirá automáticamente la lista basada en la existencia de ssh-agent o gpg-agent en el sistema. El agregado de --quiet limitará la salida de advertencias, errores, y prompts de usuarios. Si desea más seguridad reemplace -Q con --clear pero es tan conveniente.
Si es necesario, reemplace ~/.ssh/id_ecdsa con la ruta a su clave privada. Para aquellos que usen un shell compatible que no sea Bash, consulte keychain --help o man keychain para detalles en otros shells.
Para probar Keychain, cierre su sesión e ingrese nuevamente. Si esta es su primera vez en ejecutar Keychain, le pedirá la frase de contraseña de la clave privada especificada. Como Keychain reutiliza el mismo processo de ssh-agent en sucesivos inicios de sesión, no debería tener que ingresar su frase de contraseña la próxima vez que se conecte. Solamente se le pedirá la frase de contraseña cuando reinicie su máquina.
5.3.1 Métodos alternativos de inicio
Existen numerosas formas de invocar a Keychain y le animamos a experimentar para encontrar un método que funcione para usted. El comando keychain en sí mismo posee docenas de opciones en línea de comandos como se describe en la página man de Keychain.
Una implementación alternativa de un script de inicio de Keychain puede ser crear el archivo /etc/profile.d/keychain.sh como un usuario root y agregar las siguientes líneas.
/etc/profile.d/keychain.sh
/usr/bin/keychain -Q -q --nogui ~/.ssh/id_ecdsa [[ -f $HOME/.keychain/$HOSTNAME-sh ]] && source $HOME/.keychain/$HOSTNAME-sh
Asegúrese también de hacer ejecutable a /etc/profile.d/keychain.sh cambiando los permisos de archivo.
# chmod 755 /etc/profile.d/keychain.sh
Si no desea que se le pregunte por su frase de contraseña cada vez que inicie sesión, sino mas bien la primera vez, añada lo siguiente a su .bashrc:
alias ssh='eval $(/usr/bin/keychain --eval --agents ssh -Q --quiet .ssh/id_rsa) && ssh'
Esto le preguntará si intenta utilizar ssh por primera vez. Recuerde que sin embargo le preguntará SOLO si es aplicable .bashrc. Entonces siempre tendrá su primer comando para ser ejecutado en una terminal.
5.4 x11-ssh-askpass
El paquete x11-ssh-askpass ofrece un cuadro de diálogo para ingresar su frase de contraseña cuando ejecute una sesión en X. x11-ssh-askpass depende solamente de las bibliotecas libx11 y libxt, y la apariencia de x11-ssh-askpass es personalizable. Aunque puede ser invocada por el programa ssh-add que puede cargar sus claves desencriptadas en ssh-agent, las siguientes instrucciones configurarán x11-ssh-askpass para ser invocado por el script de [#Keychain|Keychain]] anteriormente mencionado.
Instale keychain y x11-ssh-askpass, disponibles en los repositorios oficiales.
Edite su archivo ~/.xinitrc para incluir las líneas resaltadas en negrita, reemplazando el nombre y la localización de su clave privada si es necesario. Asegúrese se colocar estos comandos antes de la línea que invoca su gestor de ventanas.
~/.xinitrc
keychain ~/.ssh/id_ecdsa [ -f ~/.keychain/$HOSTNAME-sh ] && . ~/.keychain/$HOSTNAME-sh 2>/dev/null [ -f ~/.keychain/$HOSTNAME-sh-gpg ] && . ~/.keychain/$HOSTNAME-sh-gpg 2>/dev/null ... exec openbox-session
En el ejemplo anterior, la primera línea invoca a keychain y le pasa el nombre y la localización de su clave privada. Si no es la primera vez que lo hace, las siguientes dos líneas carganel contenido de $HOSTNAME-sh y $HOSTNAME-sh-gpg si existen. Estos archivos almacenan las variables de entorno de la instancia previa de keychain.
5.4.1 Temas
La apariencia de x11-ssh-askpass puede ser personalizada configurando sus recursos de X disponibles. Su x11-ssh-askpass página web presenta algunos temas de ejemplo. Consulte la página man de x11-ssh-askpass para obtener información detallada.
5.4.2 Cuadros de diálogo alternativo
Existen otros programas con cuadros de diálogo para frases de contraseña que se pueden usar además de x11-ssh-askpass. La lista siguiente brinda algunas soluciones alternativas.
- ksshaskpass está disponible en los repositorios oficiales. Depende de kdelibs y es adecuada para el entorno de escritorio KDE.
- openssh-askpass depende de las bibliotecas qt, y está disponible en los repositorios oficiales.
5.5 GNOME Keyring
If you use the GNOME desktop, the GNOME Keyring tool can be used as an SSH agent. Visit the GNOME Keyring article.
6 Resolución de problemas
Si el servidor SSH ignora sus claves, asegúrese que dispone del conjunto de permisos apropiados para todos los archivos relevantes.
Para su máquina local:
$ chmod 700 ~/ $ chmod 700 ~/.ssh $ chmod 600 ~/.ssh/id_ecdsa
Para la máquina remota:
$ chmod 700 ~/ $ chmod 700 ~/.ssh $ chmod 600 ~/.ssh/authorized_keys
Si no se soluciona, ejecute sshd en modo debug y monitoree la salida mientras se conecta:
# /usr/sbin/sshd -d
6.1 Usando kdm
Si kdm no lanza directamente el proceso ssh-agent, instale el paquete kde-agent:
pacman -S kde-agent
7 Ver también
- OpenSSH key management, Part 1
- OpenSSH key management, Part 2
- OpenSSH key management, Part 3
- Getting started with SSH
- OpenSSH 5.7 Release Notes
