Lo hice y lo entendí

El blog de Vicente Navarro
13 ene

Autentificación trasparente por clave pública/privada con OpenSSH

El protocolo SSH está preparado para que podamos autentificarnos de forma transparente (sin introducir una contraseña manualmente). Para ello, lo que hacemos es generar una pareja de claves pública/privada (podemos tener varias, una por protocolo) en el cliente de SSH y a continuación, al servidor de SSH le especificamos una serie de claves públicas de clientes que, si acceden con la clave privada asociada, pueden entrar sin especificar una contraseña.

Cómo hacer esto en concreto varía entre implementaciones de cliente y servidor de SSH, pero si estamos usando OpenSSH, que es lo estándar tanto en Linux y *BSD, como en Cygwin, sólo hay que seguir unos sencillos pasos que vamos a ver a continuación.

El primer paso es generar la pareja de claves pública/privada en el cliente con el comando ssh-keygen:

$ ssh-keygen
Generating public/private rsa key pair.
Enter file in which to save the key (/home/supercoco/.ssh/id_rsa):
Enter passphrase (empty for no passphrase):
Enter same passphrase again:
Your identification has been saved in /home/supercoco/.ssh/id_rsa.
Your public key has been saved in /home/supercoco/.ssh/id_rsa.pub.
The key fingerprint is:
5c:7b:3d:44:21:09:84:a1:e6:8b:42:4e:ec:39:d6:92 supercoco@cliente

Si no le especificamos opciones, el comando crea una clave RSA de 2048 bits, pero podemos cambiar este comportamiento. Por ejemplo, para clave DSA de 1024 bits, sería:

$ ssh-keygen -t dsa -b 1024
Generating public/private dsa key pair.
Enter file in which to save the key (/home/supercoco/.ssh/id_dsa):
Enter passphrase (empty for no passphrase):
Enter same passphrase again:
Your identification has been saved in /home/supercoco/.ssh/id_dsa.
Your public key has been saved in /home/supercoco/.ssh/id_dsa.pub.
The key fingerprint is:
91:84:38:fd:03:b4:74:5a:1c:ad:48:c4:da:57:3b:cc supercoco@cliente

Hay que tener en cuenta que si le especificamos una passphrase, tendremos que introducirla manualmente cada vez que queramos usar la clave privada, por lo que la autentificación no será transparente. Por ello, aunque no sea lo más seguro, para nuestro propósito es necesario dejarla en blanco.

Y ahora sólo tenemos que copiar el contenido el fichero id_dsa.pub o del id_rsa.pub en el fichero authorized_keys del directorio $HOME/.ssh/ del usuario del sistema con servidor SSH al que queremos acceder.

Por ejemplo, si queremos entrar en el servidor SSH con el usuario ranagustavo, tendríamos que añadir el contenido de los ficheros /home/supercoco/.ssh/id_dsa.pub o /home/supercoco/.ssh/id_rsa.pub del cliente de SSH al fichero /home/supercoco/.ssh/authorized_keys del servidor de SSH.

Si tenemos la contraseña para entrar, podríamos incluso hacerlo desde el cliente con un par de comandos:

$ scp $HOME/.ssh/id_dsa.pub ranagustavo@servidor:id_dsa.pub.supercoco.cliente
Password:
id_dsa.pub
$ ssh ranagustavo@servidor 'cat id_dsa.pub.supercoco.cliente >> .ssh/authorized_keys'

y ya podemos entrar sin introducir la contraseña:

$ ssh ranagustavo@servidor
Linux servidor 2.6.22 #2 SMP Sun Dec 9 19:33:44 CET 2007 x86_64

The programs included with the Debian GNU/Linux system are free software;
the exact distribution terms for each program are described in the
individual files in /usr/share/doc/*/copyright.

Debian GNU/Linux comes with ABSOLUTELY NO WARRANTY, to the extent
permitted by applicable law.
No mail.
Last login: Sun Jan 13 22:12:58 2008 from cliente
ranagustavo@servidor ~ $  

Si no funciona, es porque los permisos del directorio .ssh y del fichero authorized_keys son demasiado permisivos, por lo que puede ser necesario hacer lo siguiente en el servidor usando el usuario apropiado (es recomendable hacerlo siempre por si acaso):

$ chmod 700 $HOME/.ssh
$ chmod 600 $HOME/.ssh/authorized_keys

Una vez que esté configurado correctamente, podemos incluso querer configurar el servidor de SSH para que no acepte clientes que quieran entrar por el método estándar, la contraseña. Para ello, partiendo de la configuración estándar de Debian (con otras configuraciones base, puede ser necesario hacer más cosas), sólo tenemos que cambiar los parámetros ChallengeResponseAuthentication y PasswordAuthentication del fichero /etc/ssh/sshd_config a “no“:

# Change to yes to enable challenge-response passwords (beware issues with
# some PAM modules and threads)
ChallengeResponseAuthentication no

# Change to no to disable tunnelled clear text passwords                                            
PasswordAuthentication no

Con un “/etc/init.d/ssh reload” conseguiremos que el sshd relea la configuración.

Y como apunte extra, cómo configurar PuTTY para acceder a OpenSSH: Secure Linux/UNIX access with PuTTY and OpenSSH

Actualización 11/12/13: Para acceder a sistemas RHEL 6 y CentOS 6 con SELinux activado, adicionalmente, puede ser necesario ejecutar en ellos (RedHat 6/Oracle Linux 6 is not allowing key authentication via ssh):

restorecon -R -v ~/.ssh

:wq

Entradas relacionadas

15 Comentarios a “Autentificación trasparente por clave pública/privada con OpenSSH”

  • Juampa dice:

    En mi caso me toca administrar en ocasiones el ordenador de mi novia (lo cual me evita ir hasta su casa constantemente…). Cree una cuenta en dyndns, y le abrí el puerto 22 en el router. Siempre accedo con su usuario y me toca introducir la contraseña. Mi pregunta es :

    ¿Conviene crear un usuario aparte del suyo para la administración externa? Por el tema de que el usuario y la contraseña estén constantemente viajando…
    ¿Aporta mas seguridad el tener las claves publica/privada? ¿O se trata sólo de comodidad ?

    Muchas gracias, y un saludo.

  • raul dice:

    Juampa lo recomendable IMHO para tener mas seguridad creo que seria configurar el servidor ssh modficando el archivo /etc/ssh/sshd_config.

    permetir solo los usuarios que tu decidas
    AllowUsers usuario_que_tu_decidas

    No permitir que root se pueda conectar
    PermitRootLogin no

    Con ssh la contraseña y el usuario viajan pero no en texto plano como en el caso de telnet por esa parte no habria problema ninguno.

    Tambien puedes poner que la autentificacion ademas de por clave publica/privada debas poner la passphrase (no se como se dice en castellano), ya seria un plus de seguridad mas.

    eso es lo poco que puedo aportar.

  • @Juampa Estoy de acuerdo con los comentarios de raul y aún añado más: No veo ningún problema por trabajar con un usuario distinto al habitual o no. Lo que sí que veo conveniente es, puesto que tú vas a ser el único en acceder a esta máquina remotamente, que deshabilites la autentificación con contraseña y le dejes sólo la de clave pública. Y si le pones passphrase, pues mucho más seguro.

    Si sólo permites autentificación con clave pública, no es necesario que pongas ni el AllowUsers ni el PermitRoot ya que en definitiva sólo podrán entrar usuarios con la clave privada adecuada y que tu hayas autorizado previamente añadiéndolos al authorized_keys.

    @raul Muchas gracias por colaborar con tus comentarios.

  • Adolfo dice:

    Todo me funciona bien, pero el servidor ssh me pide la passphrase (que he dejado en blanco a la hora de generar las claves) ¿que pasa, por que no funciona?

    Gracias

  • @Adolfo Es difícil saber cuál es tu problema en concreto, pero lo normal es que cuando no pones passphrase, no te la pide.

  • sefokuma dice:

    Al contrario si que es normal, ya que por defecto todos los sistemas no ejecutan ssh-agent por defecto y almacena las claves.

  • Carlos dice:

    Hola, les cuento que soy usuario de Mac OsX 10.3.9, estoy tratando de trabajar con SSH utilizando el programa FUGU o el MacSftp, y no me deja ingresar al servidor que quiero. O entra y no me muestra los directorios, o bien me pide contraseña constantemente, aunque la ingrese indefinidas veces.

    Tienen idea cual puede ser el problema?, se puede trabajar en SSH con el OSX 10.3.9? Hay algo que debo hacer o configurar que no estoy haciendo?

    Les agradeceria me puedan dar una mano con este tema, ya que necesito hacer unos trabajos y estoy trabado por esto.

    Desde ya muchas gracias, quedo a espera de su respuesta.
    Saludos. Charly
    carlos.baez.73@gmail.com

  • Rem dice:

    Hola a todos,

    Gracias por este súper manual, que me ha ido genial para hacer y entender la autenticación por clave pública. Sólo un pequeño detalle. Para anular la entrada “tradicional” (usuario y contraseña) no me ha funcionado con la línea de “ChallengeResponseAuthentication no”. Modificaba esto y dejaba que los usuarios sin clave pública se autenticaran. He modificado la opción “PasswordAuthentication no” y esta sí que lo ha dejado anulado.

    Saludos.

  • @Rem Tienes razón. No había caído en mencionarlo porque yo ya la tenía deshabilitada:

    # Change to yes to enable challenge-response passwords (beware issues with                          
    # some PAM modules and threads)                                                                     
    ChallengeResponseAuthentication no                                                                  
                                                                                                        
    # Change to no to disable tunnelled clear text passwords                                            
    PasswordAuthentication no

    Actualizo la entrada. ¡Gracias por el comentario!

Trackbacks y pingbacks:

Tema LHYLE09, creado por Vicente Navarro