SSH sin contraseña: Mejor seguridad en conexiones remotas

El protocolo SSH (Secure Shell) es una herramienta fundamental para la administración de sistemas y redes. Permite conexiones remotas seguras. El uso de SSH sin contraseña es importante dado que la autenticación mediante contraseñas tiene ciertas limitaciones en cuanto a seguridad y conveniencia. Configurar SSH para funcionar sin contraseña, utilizando un par de claves criptográficas (pública y privada) es una alternativa muy recomendable. Este esquema mejora la seguridad, evita la necesidad de recordar contraseñas y es ideal para automatizaciones o scripts.

SSH sin contraseña

Criptografía de llaves públicas y privadas

La criptografía de llaves públicas y privadas es un principio fundamental en la seguridad informática moderna. En este esquema, se genera un par de claves: una clave pública y una clave privada. La clave pública se puede compartir libremente, mientras que la clave privada se mantiene secreta. Lo que se cifra con la clave pública solo puede ser descifrado por la clave privada correspondiente, y viceversa. Este mecanismo permite autenticación y cifrado seguros, ya que solo el propietario de la clave privada puede descifrar los mensajes cifrados con su clave pública.

La longitud de la clave es un aspecto crucial que determina la seguridad del cifrado. A lo largo de los años, se ha incrementado el tamaño recomendado para las claves, debido a que las técnicas de ataque han mejorado. Las claves RSA, por ejemplo, solían generarse con 1024 bits. Hoy en día el tamaño mínimo recomendado es de 2048 bits, siendo preferible incluso 4096 bits para aplicaciones más críticas. La clave más larga ofrece mayor resistencia frente a ataques de fuerza bruta, aunque a costa de un mayor tiempo de procesamiento.

Evolución y estándares predeterminados

Con el tiempo, los valores predeterminados para la longitud de las claves y los algoritmos han cambiado en respuesta a nuevos descubrimientos en criptografía y al aumento de la potencia de cómputo. RSA (Rivest-Shamir-Adleman) ha sido históricamente el algoritmo más utilizado, pero debido a ciertos avances que han revelado vulnerabilidades potenciales en su implementación, cada vez más sistemas adoptan algoritmos más modernos, como Elliptic Curve Cryptography (ECC), que proporciona una seguridad comparable a RSA con claves mucho más cortas, reduciendo el tiempo de procesamiento y el uso de recursos.

Por ejemplo, una clave de 256 bits en ECC proporciona un nivel de seguridad equivalente a una clave RSA de 3072 bits, lo que la convierte en una alternativa cada vez más popular en sistemas como OpenSSH.

Protocolos de cifrado utilizados en SSH y GPG

En cuanto a los protocolos que utilizan este sistema de criptografía, SSH (Secure Shell) emplea comúnmente RSA, DSA, ECDSA y ED25519, este último basado en curvas elípticas, con especial énfasis en la seguridad y eficiencia. El algoritmo ED25519, en particular, ha ganado popularidad debido a su combinación de seguridad y velocidad, siendo resistente a ciertos ataques que afectan a RSA y otros métodos.

Por otro lado, GPG (GNU Privacy Guard), que se utiliza principalmente para cifrado y firma de correos electrónicos, así como para la autenticación de software, soporta una variedad de algoritmos de cifrado, incluyendo RSA, DSA, ElGamal y curvas elípticas. GPG es la implementación libre de PGP (Pretty Good Privacy) y permite la creación de claves públicas y privadas tanto para cifrado como para firmas digitales, haciendo uso de estándares abiertos como OpenPGP.

Tanto SSH como GPG permiten una gestión flexible de claves, y comparten el objetivo común de proporcionar mecanismos de autenticación y confidencialidad robustos. Al preparar una guía práctica de GPG, notarás cómo estos conceptos de criptografía se aplican de manera similar, pero ajustados al contexto de protección de datos y comunicaciones personales.

¿Por qué usar SSH sin contraseña?

El uso de claves públicas para autenticarse en lugar de contraseñas tiene varias ventajas:

1. Mayor seguridad: Las contraseñas pueden ser vulnerables a ataques de fuerza bruta. En cambio, las claves SSH, al ser criptográficamente más complejas, son significativamente más difíciles de vulnerar.

2. Comodidad: Una vez configurado, no tendrás que ingresar la contraseña cada vez que te conectes al servidor, lo cual ahorra tiempo.

3. Automatización: Para tareas automatizadas, como sincronización de archivos o despliegue de aplicaciones, las claves SSH eliminan la necesidad de contraseñas en procesos no interactivos.

¿Cómo funciona la autenticación mediante claves SSH?

Este método utiliza un par de claves:

– Clave privada: Se guarda en el dispositivo desde el cual se conecta el usuario (cliente).

– Clave pública: Se almacena en el servidor al que se quiere acceder. Cuando intentas conectarte al servidor, éste verifica si la clave privada del cliente coincide con la clave pública registrada en el servidor.

Si las claves coinciden, el servidor concede acceso sin necesidad de contraseña.

Habilitación del servidor para usar SSH sin contraseña

Los archivos de configuración del servicio de SSH se encuentran en la carpeta /etc/ssh. En esta carpeta, del servidor, deberemos editar el archivo sshd_config. En particular, debemos localizar las líneas que definan los valores de las variables PasswordAuthentication, UsePAM, RSAAuthentication, PubKeyAuthentication y ChallengeResponseAuthentication. Si alguna de ellas no se encontrara en el archivo, habría que añadirla

Usando el editor de tu preferencia (nano, pico, vi, …) edita el archivo y define los siguientes valores. Observa que algunas de las variables pudieran estar comentadas.

PasswordAuthentication no
UsePAM no
RSAAuthentication yes
PubkeyAuthentication yes
ChallengeResponseAuthentication no

¡Atención! Los valores anteriores harán que el acceso por SSH SOLAMENTE sea posible mediante el uso del esquema de claves públicas y privadas.

Configuración de SSH sin contraseña

A continuación, describo el proceso paso a paso para configurar SSH sin contraseña. Este ejemplo asume que estás utilizando un sistema basado en Linux o macOS como cliente y un servidor remoto que también use Linux.

1. Generar el par de claves SSH

El primer paso es generar el par de claves en el equipo desde el que te conectarás al servidor (el cliente).

1. Abre una terminal en el cliente y ejecuta el siguiente comando:

ssh-keygen -t rsa -b 4096
  • `-t rsa`: Especifica el tipo de clave a generar. En este caso, RSA.
  • `-b 4096`: Indica el tamaño de la clave (en bits). Cuanto mayor sea, más segura será la clave. 4096 bits es un tamaño comúnmente recomendado.

2. El sistema te pedirá una ruta para guardar la clave. Por defecto, se guardará en `~/.ssh/id_rsa` para la clave privada y `~/.ssh/id_rsa.pub` para la clave pública.

3. Opcionalmente, puedes establecer una frase de seguridad (passphrase) para proteger la clave privada en caso de que alguien obtenga acceso no autorizado a tu máquina. Esta frase será solicitada cada vez que uses la clave, salvo que configures un agente de SSH para almacenarla temporalmente.

2. Copiar la clave pública al servidor remoto

Una vez generado el par de claves, el siguiente paso es copiar la clave pública al servidor remoto. Existen varias formas de hacerlo, pero una de las más simples es usando el comando `ssh-copy-id`.

1. Desde la terminal del cliente, ejecuta:

ssh-copy-id usuario@servidor_remoto
  • Reemplaza `usuario` con tu nombre de usuario en el servidor y `servidor_remoto` con la dirección IP o el dominio del servidor.

2. El sistema te pedirá la contraseña del usuario en el servidor remoto (solo esta vez). Después de introducirla, la clave pública se agregará al archivo `~/.ssh/authorized_keys` en el servidor remoto, que es donde SSH almacena las claves autorizadas.

Si el comando `ssh-copy-id` no está disponible en tu sistema, puedes hacer el proceso manualmente:

  • Conecta al servidor usando SSH:
   ssh usuario@servidor_remoto
  • Crea el directorio `.ssh` si no existe:
   mkdir -p ~/.ssh
  • Copia la clave pública desde el cliente al servidor usando SCP:
  scp ~/.ssh/id_rsa.pub usuario@servidor_remoto:~/.ssh/temp_pub_key
  • En el servidor, agrega la clave pública al archivo `authorized_keys`:
     cat ~/temp_pub_key >> ~/.ssh/authorized_keys
     rm ~/temp_pub_key
     chmod 600 ~/.ssh/authorized_keys

3. Probar la conexión SSH sin contraseña

Después de copiar la clave pública, ya deberías poder conectarte al servidor sin usar contraseña. Desde el cliente, intenta conectarte de nuevo:

ssh usuario@servidor_remoto

Si todo está correctamente configurado, ya no se te pedirá la contraseña.

4. Mejoras adicionales de seguridad

Para fortalecer aún más la seguridad de tu servidor, puedes considerar las siguientes medidas:

  • Deshabilitar la autenticación con contraseña: Una vez que SSH sin contraseña esté funcionando correctamente, puedes desactivar la autenticación mediante contraseñas para evitar posibles ataques de fuerza bruta. Para hacer esto, edita el archivo de configuración de SSH en el servidor (`/etc/ssh/sshd_config`), y cambia o añade la siguiente línea:
  PasswordAuthentication no

Luego, reinicia el servicio SSH:

  sudo systemctl restart ssh
  • Usar un agente SSH: Si has establecido una frase de seguridad para tu clave privada, puedes usar un agente SSH para evitar tener que escribirla cada vez. El agente SSH almacena la clave privada en memoria y gestiona las solicitudes de autenticación.

Conclusión del uso de SSH sin contraseña

Configurar SSH sin contraseña es una manera eficiente de mejorar la seguridad y la eficiencia al gestionar conexiones remotas. Además de evitar la necesidad de ingresar contraseñas repetidamente, el uso de claves públicas y privadas añade una capa significativa de protección frente a ataques. A medida que la automatización y los entornos multi-servidor se vuelven más comunes, este enfoque de emplear SSH sin contraseña se convierte en una práctica esencial para administradores de sistemas y desarrolladores.

Nota final: He descrito aquí el esquema de conexión usando claves públicas y privadas. También es posible configurar este acceso usando certificados SSH. El método es muy similar, pero lo dejaré para otro artículo, de manera que no te confundas con los dos métodos.