Funcionamiento normal de SSH
SSH permite autenticarnos a un servidor remoto indicando nuestro usuario y contraseña. Por ejemplo:
ssh usuario@servidor.com
También indicando la IP:
ssh usuario@192.168.1.1
La “desventaja” es que debemos escribir la contraseña cada vez que queremos hacerlo y que alguien podría hacer un ataque de fuerza bruta para autenticarse en nuestro servidor.
Con el tutorial de hoy vamos a usar criptografía asimétrica para autentificarnos sin contraseña y hacer más fuerte el proceso.
Resumen para generar claves
Si solo vienes a copiar y pegar, o a recordar el proceso, lo dejo súper resumido aquí:
# Genera tu par de claves si todavía no existen
ssh-keygen -t ed25519 -C "comentario"
# Cópialas al servidor. Recuerda que "usuario@servidor.com" son el usuario y host como si usaras SSH
ssh-copy-id usuario@servidor.com
# Seguramente se te pedirá la contraseña. No te preocupes, esta es la última vez. Ingrésala y luego intenta autenticarte
ssh usuario@servidor.com
# Lo de arriba ya no debería pedirte contraseña
Suponiendo que quieres autentificarte a otro servidor, la próxima vez solo harías:
ssh-copy-id usuario@otroservidor.com
# Aquí ingresas tu contraseña
ssh usuario@otroservidor.com
# Y arriba ya no se te pedirá contraseña
Eso sí, esto solo cambia la autenticación. Una vez dentro del servidor en caso de que quieras hacer algo
con sudo se te va a pedir tu contraseña como normalmente se hace.
No es obligatorio que uses la misma clave privada, puedes generar y usar varias, ya solo necesitas indicarle a ssh-copy-id cuál
clave quieres, por ejemplo:
ssh-copy-id -i /ubicación/clave/pública usuario@servidor.com
Así que en resumen es
- Genera tu par de claves
- Cópialas al servidor introduciendo tu contraseña cuando se te pida
- Autentificarte con ssh y ya no se te pedirá la contraseña
La próxima vez que quieras autentificarte ya solo debes seguir el paso 3
Sigue leyendo si quieres conocer más sobre este proceso
Evitar uso de contraseña
Existe una manera de evitar el uso de contraseña gracias a las claves privadas y públicas. Es más seguro y nos evitamos escribir la contraseña.
De este modo podemos automatizar procesos como rsync con crontab ya que no se va a solicitar la contraseña. Se me ocurre que con esto podemos beneficiarnos de lo siguiente:
- Autenticación SSH
- SCP para subir archivos
- Rsync para sincronizar y subir archivos de manera eficiente
Gracias a esto también podemos desactivar la autenticación por contraseña evitando ataques de fuerza bruta
Por cierto, este tutorial funciona perfectamente en Windows al usar MSYS2 e instalar las herramientas SSH.
Generando par de claves
Lo primero es generar un par de claves: una clave pública y una privada. Generamos este par de claves en nuestra computadora local, no en nuestro servidor:
ssh-keygen -t ed25519 -C "comentario"
En comentario podemos poner algo que identifique esa clave. Puede ser el nombre de tu PC local. Nos va a pedir
una contraseña opcional y aquí es donde tú decides si pones una.
Si eliges una contraseña, se te pedirá cada vez que autentifiques. Esto elimina la automatización porque siempre se te va a pedir contraseña, pero será más seguro
Si no eliges una contraseña entonces todo será automático, pero toda la seguridad recaerá en la protección de tu clave privada
Yo pienso que si alguien tiene acceso a tu computadora (y por lo tanto a tus claves) entonces es lo mismo que si tuviera acceso SSH, así que recomiendo no elegir contraseña.
Con eso se habrá creado tu clave en ~/.ssh/nombre_clave (el asistente te dirá la ubicación de la misma) por ejemplo /home/parzibyte/.ssh/id_ed25519 que
puede lucir así:
-----BEGIN OPENSSH PRIVATE KEY-----
aquí muchos caracteres
-----END OPENSSH PRIVATE KEY-----
Esa es tu clave privada. No la compartas con nadie. Junto con esa clave se habrá creado otra con el mismo nombre pero que termina en .pub, misma que es
la clave pública y se ve así:
ssh-ed25519 aquí_letras_y_números comentario
Esta es la clave pública que vas a necesitar copiar al servidor. Podrías hacerlo manualmente pero para ello ya existe ssh-copy-id.
Copiar archivo con ssh-copy-id
La manera recomendada es subir la clave usando la herramienta incorporada ssh-copy-id. Su sintaxis es:
ssh-copy-id usuario@servidor.com
Recuerda: usuario@servidor.com es tu usuario y servidor que usarías como si te autenticaras
con SSH.
Si tienes varias claves o deseas copiar una en específico puedes indicarlo así:
ssh-copy-id -i /ubicación/clave usuario@servidor.com
Copiar archivo manualmente
Si quisieras hacerlo manualmente tendrías que iniciar sesión en tu
servidor, editar el archivo ~/.ssh/authorized_keys y añadir una nueva línea con el contenido de la clave pública.
Supongamos que tu archivo está vacío, ahora debe verse así:
ssh-ed25519 caracteres_aquí comentario
Y si ya tuviera claves, por ejemplo:
ssh-rsa aquí_caracteres rsa-key-20190108
ssh-rsa otros_caracteres parzibyte@newdonkcitypc
Ahora se vería así:
ssh-rsa aquí_caracteres rsa-key-20190108
ssh-rsa otros_caracteres parzibyte@newdonkcitypc
ssh-ed25519 caracteres_aquí comentario
Autentificación sin contraseña
Después de haber generado tus claves y subido la clave pública ya sea con ssh-copy-id
o manualmente, ya podrás autentificarte usando exactamente el mismo comando que usabas antes:
ssh usuario@servidor.com
La única diferencia es que ahora no se te pedirá contraseña. Ya puedes automatizar procesos como rsync o scp.
Qué hacer si pierdes tu clave
Si ya no tienes tu clave privada o alguien la ha robado entonces remueve la clave pública de tu servidor por seguridad. Luego vuelve a generar otro par.
Nota sobre la ubicación de la generación
Anteriormente mencioné que el par de claves debe ser generado en nuestra computadora local, pues normalmente siempre nos conectamos desde nuestra PC local al servidor, pero así como podemos usar SSH desde nuestro servidor para conectarnos a otro servidor, también podemos generar las claves en un servidor para conectarnos a otro.
Lo dejo claro para que no creas que el uso es exclusivo en computadoras locales. De hecho no existe algo como computadora local y servidor, simplemente es lo que tomamos como cliente y como servidor, y un servidor puede ser también un cliente de otro.