Acceso SSH Seguro con Claves: Guía para Servidores

¿Cansado de escribir contraseñas cada vez que te conectas a tu servidor? ¿Te preocuparía que alguien las adivine o las robe? Si es así, estás en el lugar correcto.

Hoy vamos a aprender una de las mejores prácticas de ciberseguridad para administrar cualquier servidor: proteger el acceso SSH con claves en lugar de contraseñas. Este método no solo es más seguro, sino que también es más cómodo a largo plazo. Al final de esta guía, podrás configurar tu propio acceso SSH sin contraseña, como todo un profesional.

¿Por qué deberías dejar de usar contraseñas para SSH?

Las contraseñas son el eslabón más débil en la seguridad de un servidor. Son fáciles de adivinar si son simples, y si son complejas, son difíciles de recordar. Además, son vulnerables a ataques de fuerza bruta, donde los atacantes prueban miles de combinaciones por segundo.

Cuando usas ssh claves, estás utilizando un par de archivos criptográficos: una clave privada (que guardas como un tesoro en tu computadora) y una clave pública (que instalas en el servidor). Es como tener una cerradura y una llave maestra: sin la llave privada, es matemáticamente imposible entrar, incluso si conoces el nombre de usuario.

Beneficios clave de este método:

Seguridad superior: Las claves son de 2048 o 4096 bits. Romperlas tomaría billones de años con la tecnología actual.
Adiós a los ataques de fuerza bruta: Al deshabilitar la autenticación por contraseña, los bots que intentan entrar con diccionarios de contraseñas simplemente no pueden hacer nada.
Comodidad total: Una vez configurado, te conectas al instante, sin escribir nada. Puedes automatizar copias de seguridad o sincronizaciones sin intervención humana.
Control de acceso granular: Puedes revocar el acceso de un empleado simplemente eliminando su clave pública del servidor, sin cambiar la contraseña de todos.

Requisitos previos antes de empezar

No te preocupes, no necesitas ser un gurú de la informática. Solo necesitas:

Un servidor con SSH activo: Puede ser un VPS, un servidor dedicado o incluso una Raspberry Pi en tu casa. Lo importante es que tengas acceso de administrador (root) o un usuario con permisos sudo.
Una computadora local: Desde donde te conectarás. Puede ser Windows, macOS o Linux.
Un poco de paciencia: La configuración inicial toma unos 10 minutos. Después, todo es coser y cantar.

[INFO] Si tu servidor usa un panel de control como Syspanel (que se accede por el puerto 2106), el proceso de configuración de SSH es el mismo que explicamos aquí, ya que se realiza a nivel del sistema operativo.

Paso 1: Generar tu par de claves SSH

Este es el primer paso y el más importante. Vamos a crear tu "llave maestra". Lo haremos desde tu computadora local, no desde el servidor.

En Windows (usando PowerShell o CMD)

Abre PowerShell o el símbolo del sistema. Escribe el siguiente comando:

ssh-keygen -t rsa -b 4096 -C "tu_correo@ejemplo.com"

-t rsa: Especifica el tipo de cifrado (RSA es el más compatible).
-b 4096: El tamaño de la clave (4096 bits es la recomendación actual).
-C: Es un comentario para que sepas de quién es la clave. Usa tu correo o un alias.

En macOS o Linux

Abre la Terminal y usa el mismo comando:

ssh-keygen -t rsa -b 4096 -C "tu_correo@ejemplo.com"

¿Qué pasará después?

El sistema te preguntará dónde guardar la clave. Por defecto, la guardará en ~/.ssh/id_rsa. Puedes pulsar Enter para aceptar la ubicación predeterminada.

Luego te pedirá una frase de contraseña (passphrase). Este es un paso crucial. No la dejes vacía.

[WARNING] Mucha gente deja la frase de contraseña vacía por comodidad. ¡No lo hagas! Si alguien roba tu archivo de clave privada, sin la frase de contraseña no podrá usarla. Es tu última línea de defensa. Piensa en ella como una contraseña maestra para tu llave.

Pon una frase larga que recuerdes (puede ser una frase completa). No te preocupes, solo la escribirás una vez por sesión (o cada vez si configuras un agente SSH).

Al finalizar, verás dos archivos en la carpeta ~/.ssh/:

id_rsa: Tu clave privada. NUNCA la compartas, ni la subas a ningún sitio, ni la envíes por email.
id_rsa.pub: Tu clave pública. Esta sí puedes compartirla; es la que instalaremos en el servidor.

Paso 2: Copiar la clave pública a tu servidor

Ahora necesitamos llevar tu clave pública al servidor. Hay una forma muy fácil y una forma manual.

Método fácil: usando `ssh-copy-id` (Linux y macOS)

Este comando hace todo el trabajo por ti. En tu Terminal local, escribe:

ssh-copy-id usuario@tu-servidor.com

Te pedirá la contraseña de tu usuario en el servidor (solo esta vez). Después, copiará automáticamente tu clave pública al archivo authorized_keys del servidor.

Método manual (para Windows o si no tienes `ssh-copy-id`)

Muestra el contenido de tu clave pública. En tu computadora local, escribe:
```
cat ~/.ssh/id_rsa.pub
```
Copia la salida completa (empieza con ssh-rsa AAAA... y termina con tu correo).
Conéctate a tu servidor con tu método actual (usando contraseña):
```
ssh usuario@tu-servidor.com
```
Una vez dentro, crea la carpeta .ssh y el archivo authorized_keys con los permisos correctos:
```
mkdir -p ~/.ssh
echo "PEGA_AQUI_TU_CLAVE_PUBLICA" >> ~/.ssh/authorized_keys
chmod 700 ~/.ssh
chmod 600 ~/.ssh/authorized_keys
```
[TIP] Es importante que authorized_keys tenga permisos 600 (solo lectura y escritura para el dueño) y la carpeta .ssh tenga 700. Si los permisos son demasiado abiertos, SSH los rechazará por seguridad.

Paso 3: Probar la conexión con tu clave

Antes de deshabilitar las contraseñas, vamos a asegurarnos de que todo funciona. Desde tu computadora local, intenta conectarte de nuevo:

ssh usuario@tu-servidor.com

Si configuraste una frase de contraseña, te la pedirá. Si todo fue bien, ¡estarás dentro sin necesidad de escribir la contraseña del servidor! Habrás logrado un acceso ssh sin contraseña (del servidor, no de tu clave local).

Si no funciona, revisa los permisos del archivo authorized_keys en el servidor o asegúrate de haber copiado la clave sin saltos de línea extra.

Paso 4: Desactivar el acceso por contraseña (el paso crítico)

Una vez que confirmes que puedes entrar con tu clave, es hora de dar el golpe final a las contraseñas. Vamos a editar el archivo de configuración del demonio SSH.

Conéctate a tu servidor (ya con tu clave).
Abre el archivo de configuración con un editor de texto. Usamos nano porque es fácil:
```
sudo nano /etc/ssh/sshd_config
```
Busca las siguientes líneas. Si están comentadas (empiezan con #), elimina el # para activarlas. Cambia sus valores a los siguientes:
```
PasswordAuthentication no
ChallengeResponseAuthentication no
UsePAM no
```
[INFO] UsePAM (Módulos de Autenticación Conectables) a veces puede interferir. Al ponerlo en no, nos aseguramos de que solo se use el método de claves.
Guarda el archivo. En nano, presiona Ctrl + O para guardar, luego Enter, y Ctrl + X para salir.
Reinicia el servicio SSH para que los cambios surtan efecto:
```
sudo systemctl restart sshd
```
(En algunos sistemas puede ser sudo systemctl restart ssh o sudo service ssh restart)

[WARNING] ¡ATENCIÓN! Este es el momento de la verdad. NO cierres la sesión actual todavía. Abre una nueva ventana de terminal y prueba a conectarte de nuevo. Si la conexión falla, aún tienes tiempo de revertir los cambios en la ventana original. Si funciona, ya puedes cerrar la sesión vieja. Este es un paso de seguridad fundamental para no quedarte fuera de tu propio servidor.

Paso 5: Configuración adicional para la seguridad (Opcional pero recomendado)

Ahora que tienes lo básico, vamos a ponerle el cinturón de seguridad al coche.

Cambiar el puerto de SSH

Por defecto, SSH usa el puerto 22. Los bots escanean todo internet buscando este puerto. Cámbialo a un número alto (ej. 2200, 5522) para reducir drásticamente los ataques.

En el mismo archivo sshd_config, busca la línea #Port 22 y cámbiala a:
```
Port 2200
```
Guarda, reinicia SSH y recuerda usar el nuevo puerto al conectarte:
```
ssh -p 2200 usuario@tu-servidor.com
```

[TIP] Si usas Syspanel, el acceso a tu panel es por el puerto 2106, pero esto es independiente del puerto de SSH. No los confundas. El puerto de SSH lo defines tú.

Deshabilitar el acceso del usuario root

Es una mala práctica conectarse directamente como root. Es mejor usar un usuario normal con permisos sudo.

Asegúrate de tener un usuario con privilegios sudo.
En sshd_config, busca PermitRootLogin y cámbialo a:
```
PermitRootLogin no
```

Preguntas frecuentes (FAQ)

¿Qué hago si pierdo mi clave privada?

Si pierdes tu clave privada, perderás el acceso a tu servidor. Por eso es crucial tener una copia de seguridad en un lugar seguro (como un gestor de contraseñas o un USB cifrado). Si no tienes acceso físico al servidor, tendrás que usar el panel de control de tu proveedor de hosting (como Syspanel, por el puerto 2106) para restablecer el acceso o montar un modo de rescate.

¿Puedo tener varias claves públicas?

Sí. Cada usuario que necesite acceso puede tener su propia clave pública en el archivo authorized_keys. Simplemente añade cada clave en una línea nueva. Esto te permite revocar el acceso a una persona específica sin afectar a los demás.

¿Qué es un agente SSH y por qué es útil?

Un agente SSH (como ssh-agent) guarda tu clave privada en memoria tras introducir tu frase de contraseña una vez. Así, no tienes que escribirla cada vez que te conectas a un servidor. Es muy útil si te conectas a varios servidores seguidos.

¿Por qué no debería usar el puerto 22?

El puerto 22 es el estándar y, por lo tanto, el objetivo número uno de ataques automatizados. Cambiarlo a un puerto no estándar no es una solución definitiva (un escáner de puertos puede encontrarlo), pero reduce el ruido y los intentos de conexión maliciosos en un 99%.

¿Es más seguro usar una clave Ed25519 en lugar de RSA?

Sí, las claves Ed25519 son más modernas, más rápidas y ofrecen un nivel de seguridad similar con claves más cortas. Puedes generarlas con ssh-keygen -t ed25519. Sin embargo, la compatibilidad con sistemas muy antiguos puede ser un problema. Para la mayoría de los casos, RSA de 4096 bits es perfecto.

Conclusión: Tu servidor ahora es una fortaleza

Felicidades, has dado un paso gigante en la seguridad ssh de tu servidor. Has pasado de usar un método vulnerable (contraseñas) a un método criptográfico robusto (claves). Los beneficios son inmensos:

Tranquilidad mental: Saber que los ataques de fuerza bruta son inútiles contra tu servidor.
Eficiencia: Te conectarás más rápido y podrás automatizar tareas.
Profesionalismo: Estás aplicando las mejores prácticas que usan los administradores de sistemas en todo el mundo.

Recuerda que la seguridad es un proceso, no un destino. Sigue explorando, sigue aprendiendo y no olvides mantener tu sistema actualizado.

[TIP] Programa una tarea en tu calendario para revisar cada pocos meses los archivos authorized_keys de tu servidor y eliminar las claves que ya no se usen. Es una buena higiene digital.

Ahora que tienes tu acceso ssh sin contraseña configurado, navega tranquilo. ¡Tu servidor te lo agradecerá!