Autonomía digital y tecnológica

Código e ideas para una internet distribuida

Configurando un acceso SSH más seguro a un servidor: autenticación con clave pública

Imago voragine.net
[actualizado el ]

La autenticación con clave pública para conectarse a un servidor remoto usando el protocolo SSH funciona con dos claves: una pública y otra privada. Para entender el funcionamiento se suele recurrir a la metáfora del candado y la llave. La clave pública funciona como un candado y la privada como la llave. El candado se colocará en el servidor remoto al que se quiere acceder; cuando se intenta acceder se comprobará que la máquina que intenta conectar tiene la llave, la clave privada.

Para configurar el acceso SSH con clave pública hay que:

  • Generar el par de claves pública/privada.
  • Copiar la clave pública al servidor.
  • Deshabilitar el acceso al servidor con contraseña.

Cómo generar el par de claves pública/privada

Para generar las claves se puede usar ssh-keygen en la máquina local desde la que se quiere conectar con el servidor:

ssh-keygen -b 4096

ssh-keygen pide la ruta y el nombre del archivo que alojará las claves pública y privada. Se puede guardar donde se quiera, pero la carpeta debe tener permisos 700 y el archivo con la clave privada 600. De lo contrario la conexión no se establecerá. La clave privada se puede proteger a su vez con una contraseña. De esta manera, si cae en manos no deseadas, lo tendrá un poco más difícil para usarla.

user@localmachine$ ssh-keygen -b 4096
Generating public/private rsa key pair.
Enter file in which to save the key (/home/user/.ssh/id_rsa):
Enter passphrase (empty for no passphrase):
Enter same passphrase again:
Your identification has been saved in /home/user/.ssh/id_rsa.
Your public key has been saved in /home/user/.ssh/id_rsa.pub.

ssh-keygen generará dos archivos:

  • id_rsa es la clave privada, la que permanecerá en la máquina local.
  • id_rsa.pub es la clave pública, la que se tiene que copiar al servidor remoto al que se quiere acceder.

Copiar la clave pública al servidor

Una vez generado el par de claves en la máquina local hay que copiar la clave pública al servidor remoto:

user@localmachine$ scp ~/.ssh/id_rsa.pub user@remotemachine:/home/user/uploaded_key.pub

La clave pública hay que incluirla en el archivo /home/user/.ssh/authorized_keys. Si la carpeta .ssh no existe, la creamos antes de copiar, así como el archivo authorized_keys:

user@remotemachine$ mkdir .ssh
user@remotemachine$ chmod 700 .ssh
user@remotemachine$ touch .ssh/authorized_keys
user@remotemachine$ chmod 600 .ssh/authorized_keys

Por último copiamos la clave y borramos el archivo copiado al servidor:

user@remotemachine$ echo `cat ~/uploaded_key.pub` >> ~/.ssh/authorized_keys
user@remotemachine$ rm /home/user/uploaded_key.pub

Deshabilitar el acceso al servidor con contraseña

Una vez habilitado el acceso SSH mendiante clave pública, se puede deshabilitar el acceso con contraseña. Esto aumentará la seguridad, pero implica que si se pierde la clave privada se perderá el acceso al servidor: hay que guardar cuidadosamente la clave privada.

La configuración del servidor SSH se puede encontrar en el archivo /etc/ssh/sshd_config. Para deshabilitar el acceso SSH con contraseña hay que añadir la siguiente línea, editando el archivo como root:

PasswordAuthentication no

Para aumentar la seguridad se pueden hacer dos ajustes adicionales en el archivo /etc/ssh/sshd_config:

Desactivar el acceso ssh para el usuario root:

PermitRootLogin no

Dar acceso SSH solo a los usuarios que lo necesiten, y no a todos:

AllowUsers usuario1 usuario2

Una vez realizados los cambios, hay que reiniciar el servidor SSH, siempre como root:

service sshd restart

Acceder al servidor con clave pública

Para conectarse al servidor con clave pública en vez de contraseña:

user@localmachine$ ssh user@remotemachine

Podemos especificar la clave privada a usar con la opción -i:

user@localmachine$ ssh -i id_rsa user@remotemachine

35 comentarios

    • Por Patux

    Gracias por la información, me sirvió mucho.

    • Por diego •

    Tu articulo me ha parecido muy interesante.
    Aunque me surge una duda.
    Te pongo en antecedentes:
    – tengo un servidor donde entrar varios usuarios por sftp, cada uno con su user/pass y puerto diferente.
    – De estos usuarios solo uno en concreto usa la autenticacion por clave privada/pública
    ¿ Como podria configurar mi servidor SFTP para que sólo a ese usuario le permita no entrar con password, pero al resto si.
    Muchas gracias

    1. Hola diego, hasta donde yo sé no se puede hacer.

    • Por ajim •

    mm y si creo una clave con un nombre de fichero personalizado cuando lanzo el comando «ssh-keygen -b 4096» me debería funcionar? he creado una clave con un nombre, digamos casa y aun habiendo realizado todos los pasos me pide siempre el login

    1. Hola ajim, sí debería funcionarte siempre que le digas dónde ir a buscar la clave con el modificador -i:

      user@localmachine$ ssh -i casa user@remotemachine

    • Por Mario •

    Puedo agregar mas claves a un mismo authorized_keys?

    1. Puedes añadir todas las que quieras. Una por línea.

    • Por Marce •

    EL servidor al que me quiero conectar me mandaron un archivo .pub. como lo instalo en mi servidor para conectarme con el? atravez de un sftp

    1. Hola Marce,

      para conectarte a un servidor con clave SSH la que tienes que enviar la clave al servidor eres tú. Una vez que tu clave esté en el servidor, ya deberías poder conectarte.

  1. Si te mudas de un ordenador a otro y quieres mantener las claves:
    1. Copia tus dos claves (id_rsa y id_rsa.pub) a /home/user/.ssh/
    2. Cambia los permisos de la carpeta y del archivo de clave privada>
    sudo chmod 600 id_rsa
    sudo chmod 700 .ssh

    Lo hice, pero no sé si es necesario hacer ssh-keygen o reactivar ssh de alguna forma.

    1. ssh-keygen sirve únicamente para generar el par de claves pública y privada, nada más. Así que si se tienen las claves no hace falta para nada.

      ¿Tras hacer lo que dices no te funciona? Si tienes problemas puedes ejecutar ssh con el modificador -v para ver cuál es el problema en la conexión.

  2. Sí me funcionó. Mi duda era si al haber hecho un restart ssh sevice o algún comando similar de los varios que probé era la razón para que funcionara o no hacía falta nada más que cambiar los permisos.

    1. Tras cambiar los permisos vale, no hace falta reiniciar el servicio ssh. Solo hace falta reiniciar el servicio tras hacer cambios en el archivos de configuración.

    • Por oscar ismael Frausto Perez •

    Tengo una maquina que quiero usar como servidor como genero el usuario y la ip, le verdad no entiendo muy bien , tal vez no tenga sentido como estoy preguntando , el fin, es que tengo una maquina que quiero usar como servidor

    1. Hola Óscar, ¿qué tipo de servidor estás montando? Este tutorial no explica cómo montar un servidor, únicamente cómo acceder a uno que ya está montado usando un par de claves SSH.

    • Por Nataly •

    Hola.

    Gracias por la información.

    Seguí los pasos, sin embargo cuando quiero conectarme de otro equipo a mi servidor por medio de la llave pública aparece el siguiente mensaje clientex@x.x.x.x : permission denied (publickey).
    Versión que utilizo en ambos equipos ubuntu 19.04.

    Gracias y saludos

    1. Hola Nataly,

      ¿tienes en ese «otro equipo» desde el que quieres conectarte tu clave privada?

    • Por Nataly •

    Hola, volví a realizar el procedimiento y funcionó, seguramente estaba realizando algún paso de forma incorrecta. Una consulta más, si quisiera ocupar un sistema externo para generar mi par de llaves (pública y privada), tendría que guardarlas en el mismo directorio que utiliza ssh-keygen (/home/user/.ssh/id_rsa)? Tengo algunos detalles más que aún estoy revisando, la idea es tener un sistema propio para generar las llaves. Gracias por tu ayuda! Saludos!

    1. Hola Nataly,

      sí, a la pregunta de dónde guardar las claves. Sin embargo, no suele ser buena idea generar las claves en un sistema externo, por seguridad. Yo nunca generaría una de mis claves en un sistema que puede estar siendo observado.

      La regla general es generar la clave desde el mismo sistema desde el que te vas a conectar.

    • Por Txema •

    Hola, no me cuadran los directorios que indicas en este articulo que son los que usa el sistema ssh. Al entrar a editar por Webmin los directorios don de se guardan las keys son otros totalmente distintos que no cuelgan de home/user/.ssh sino de etc/ssh, por ejemplo, el archivo que almacena las keys públicas de otros host no es /home/user/.ssh/authorized_keys sino etc/ssh/ssh_host_rsa_key.pub

    1. Hola Txema,

      son pares de claves diferentes los que se guardan en /home/user/.ssh/ y en /etc/ssh/. En el servidor remoto al que te quieres conectar:

      + en /etc/ssh se guardan los pares de claves del servidor. Estas claves le dicen a tu compu que el servidor que te está respondiendo cuando te intentas conectar a él, es el que dice ser: es el servidor auténtico al que te quieres conectar.
      + en /home/user/.ssh/ se guarda la clave pública del usuario que se quiere conectar al servidor. Esta clave pública le dice al servidor que tú eres quien dices ser.

      Una explicación más detallada en este hilo de StackExchange.

    • Por Angel •

    Tu articulo me fue de mucha ayuda Gracias por compartir

    • Por Ignacio •

    Perdona,

    ¿Sabes si se puede crear un usuario que solo tenga permiso para el uso de scp a un directorio? No quiero que pueda entrar con ssh y ver todos los archivos.

    Muchas gracias.

    1. Hola Ignacio,

      ssh y scp da acceso a todo el árbol de directorios. Varias estrategias para modificar esto:

    • Por Bryan Salas •

    Gracias por la información, me has ayudado mucho

    • Por luis •

    hice todos los pases pero al intentar conectarme al servidor me da este error:
    Permission denied (publickey,gssapi-keyex,gssapi-with-mic).

    1. Hola Luis, lugares donde puede estar el problema, cosas a comprobar:

      • Prueba con una clave publica/privada que tenga el nombre por omisión (id_rsa)
      • Comprueba que no estás intentando acceder con el usuario root si has configurado la opción PermitRootLogin no
      • Comprobar que el usuario con el que estás intentando acceder está en la lista de usuarios autorizados (AllowUsers)
      • Comprobar que el usuario con el que estás intentado acceder existe en el sistema remoto
    • Por Chiwy

    Según he leído por ahí las llaves ed25519 son mas seguras que las RSA, además de que son mas cortas :)

    • Por deberia

    para que diablos ocupo generar un ssh si solo tengo un ordenado? digo si no le se mejor no le muevo

    • Por monica •

    Hola, me cambiaron la password del servidor de donde me conecto a tomar archivos y no se como son los pasos a seguir para autentificarla nuevamente al servidor asi puedo volver a tomar archivos, me guias ?

    • Por Antonio Soliz •

    Muchas gracias por esto, me a sido de gran ayuda.

    Un saludo a la familia.

    • Por bit10

    y por lo contrario, es decir yo quiero deshabilitar la autenticación por clave de un servidor, si intento conectarme por ssh al servidor me arroja el siguiente error: unable to negotiate with 192.168.0.252 port 15000: no matching key exchange method found. their offer: diffie-hellman-group-exchange-sha1, diffie-hellman-group1-sha1

Dejar un comentario

*
*

 

3 trackbacks