Cómo proteger tu servidor Linux con SSH: claves y buenas prácticas

Por qué SSH es la puerta de entrada a tu servidor (y cómo blindarla)

Cuando tienes un servidor Linux, SSH (Secure Shell) es tu herramienta principal para administrarlo de forma remota. Es como tener una llave maestra digital: con ella puedes acceder a todo el sistema. Pero esa misma potencia la convierte en el objetivo favorito de los atacantes. Cada día, miles de bots escanean la red buscando servidores con SSH expuesto y contraseñas débiles. Si no tomas medidas, es cuestión de tiempo que alguien intente entrar.

La buena noticia es que proteger tu servidor Linux con SSH no es complicado. Con unos pocos cambios de configuración y buenas prácticas, puedes reducir drásticamente el riesgo de intrusión. En esta guía te explico paso a paso, sin tecnicismos innecesarios, cómo hacerlo.

Lo primero: entiende cómo funciona el acceso por SSH

Antes de tocar nada, es importante que sepas qué estás protegiendo. SSH funciona con un par de claves: una pública y una privada. La clave privada se queda en tu ordenador (nunca debe salir de ahí) y la pública se instala en el servidor. Cuando te conectas, el servidor verifica que tienes la clave privada correspondiente. Es como un candado y una llave: el candado (clave pública) está en el servidor, y tu llave (clave privada) la guardas tú.

El problema es que mucha gente sigue usando solo contraseñas, y las contraseñas son fáciles de adivinar o de obtener mediante ataques de fuerza bruta. Por eso, el primer paso para proteger tu servidor es usar claves SSH en lugar de contraseñas.

Paso 1: Genera tus claves SSH Linux

Para crear tu par de claves, abre una terminal en tu ordenador local (no en el servidor) y escribe:

ssh-keygen -t ed25519 -a 100

Te preguntará dónde guardar la clave. Pulsa Enter para usar la ubicación por defecto (~/.ssh/id_ed25519). Luego te pedirá una frase de contraseña (passphrase). No la dejes vacía. Aunque parezca un paso extra, esa frase protege tu clave privada: si alguien roba tu archivo de clave, sin la frase no podrá usarla.

Este comando genera dos archivos:

• id_ed25519: tu clave privada (no la compartas jamás).
• id_ed25519.pub: tu clave pública (esta es la que irá al servidor).

[TIP] Si tu sistema es antiguo y no soporta Ed25519, usa ssh-keygen -t rsa -b 4096. Es igual de válido, aunque Ed25519 es más rápida y segura.

Paso 2: Copia tu clave pública al servidor

Ahora necesitas instalar esa clave pública en tu servidor. La forma más sencilla es usar ssh-copy-id. Desde tu terminal local:

ssh-copy-id usuario@ip-del-servidor

Te pedirá la contraseña de ese usuario. Una vez introducida, copiará tu clave pública al archivo ~/.ssh/authorized_keys del servidor. A partir de ese momento, podrás conectarte sin contraseña:

ssh usuario@ip-del-servidor

Si ssh-copy-id no está disponible en tu sistema, puedes hacerlo manualmente. Muestra el contenido de tu clave pública:

cat ~/.ssh/id_ed25519.pub

Copia el resultado. Luego conéctate al servidor con tu contraseña, crea el directorio .ssh si no existe, y añade la clave:

mkdir -p ~/.ssh
echo "tu_clave_publica_aqui" >> ~/.ssh/authorized_keys
chmod 700 ~/.ssh
chmod 600 ~/.ssh/authorized_keys

Paso 3: Deshabilita el acceso por contraseña

Una vez que has verificado que puedes entrar con tu clave SSH, es hora de desactivar las contraseñas. Esto es clave para proteger tu servidor Linux con SSH, porque elimina la posibilidad de ataques de fuerza bruta.

Edita el archivo de configuración de SSH:

sudo nano /etc/ssh/sshd_config

Busca la línea PasswordAuthentication y cámbiala a:

PasswordAuthentication no

Guarda el archivo (Ctrl+O, luego Enter) y sal (Ctrl+X). Reinicia el servicio SSH para aplicar los cambios:

sudo systemctl restart sshd

[WARNING] Antes de cerrar tu sesión actual, abre una segunda terminal y prueba conectarte con tu clave. Si algo falla, aún tendrás tiempo de corregirlo sin quedarte fuera de tu propio servidor.

Paso 4: Deshabilitar root SSH (lo primero que debes hacer)

El usuario root es el administrador absoluto del sistema. Si un atacante consigue entrar como root, tiene control total. Por eso, una de las mejores prácticas de seguridad SSH es deshabilitar el acceso directo de root.

En el mismo archivo /etc/ssh/sshd_config, busca o añade:

PermitRootLogin no

Esto no impide que uses sudo para tareas administrativas. Simplemente obliga a que el acceso remoto se haga con un usuario normal, y luego elevas privilegios con sudo su o sudo comando cuando lo necesites.

[INFO] Algunos sistemas antiguos usan PermitRootLogin yes por defecto. Si ves esa línea, cámbiala a no. Si no existe, añádela al final del archivo.

Paso 5: Cambia el puerto SSH (seguridad por oscuridad)

El puerto por defecto de SSH es el 22. Los bots lo saben y lo escanean constantemente. Cambiarlo a un puerto no estándar reduce muchísimo el ruido de ataques automáticos. No es una medida infalible, pero ayuda.

En /etc/ssh/sshd_config, busca la línea #Port 22 y cámbiala por:

Port 2200

Elige un número entre 1024 y 65535 que no uses para otros servicios. Luego reinicia SSH:

sudo systemctl restart sshd

A partir de ahora, para conectarte tendrás que especificar el puerto:

ssh -p 2200 usuario@ip-del-servidor

También puedes configurar tu archivo ~/.ssh/config local para no tener que escribirlo cada vez:

Host mi-servidor
    HostName ip-del-servidor
    User usuario
    Port 2200

Y luego simplemente usas ssh mi-servidor.

Paso 6: Usa un usuario con permisos limitados

Nunca trabajes como root a diario. Crea un usuario con privilegios sudo para tus tareas administrativas. Si ya tienes un usuario normal, verifica que puede usar sudo:

sudo -l

Si no, añádelo al grupo sudo:

sudo usermod -aG sudo tu_usuario

Este usuario será tu acceso principal. Root queda reservado para emergencias, y solo accesible desde la consola física del servidor (si es que la tienes).

Paso 7: Configura un firewall para SSH

Un firewall limita qué puertos están abiertos al exterior. Es una capa extra de protección muy efectiva. Con ufw (Uncomplicated Firewall) es muy sencillo:

sudo ufw allow 2200/tcp
sudo ufw enable

Esto permite solo el tráfico SSH en el puerto que configuraste antes, y bloquea el resto. Si necesitas otros servicios (como HTTP/HTTPS), añádelos también:

sudo ufw allow 80/tcp
sudo ufw allow 443/tcp

[TIP] Si usas Syspanel (antes conocido como HestiaCP) para gestionar tu servidor, recuerda que su panel de administración accede por el puerto 2106. Añádelo también al firewall si lo usas:

sudo ufw allow 2106/tcp

Paso 8: Limita quién puede conectarse por SSH

Otra buena práctica es restringir el acceso SSH solo a usuarios concretos. En /etc/ssh/sshd_config, añade:

AllowUsers tu_usuario otro_usuario

Esto bloquea automáticamente a cualquier otro usuario del sistema que intente conectarse por SSH, incluso si tiene una contraseña válida.

También puedes limitar por grupos:

AllowGroups ssh-users

Y luego añades los usuarios permitidos a ese grupo:

sudo groupadd ssh-users
sudo usermod -aG ssh-users tu_usuario

Paso 9: Protege contra ataques de fuerza bruta con Fail2ban

Fail2ban es una herramienta que monitorea los logs del sistema y bloquea temporalmente las IPs que intentan acceder repetidamente sin éxito. Es como un portero que expulsa a los que llaman muchas veces a la puerta.

Instálalo:

sudo apt install fail2ban

Crea un archivo de configuración local:

sudo nano /etc/fail2ban/jail.local

Y añade:

[sshd]
enabled = true
port = 2200
maxretry = 3
bantime = 3600

Esto bloquea durante una hora a cualquier IP que falle 3 veces al intentar conectar por SSH. Ajusta los valores a tu gusto. Luego reinicia el servicio:

sudo systemctl restart fail2ban

Paso 10: Mantén tu sistema actualizado

Las vulnerabilidades de seguridad se descubren constantemente, y los parches salen para corregirlas. Un sistema desactualizado es un sistema vulnerable. Configura actualizaciones automáticas de seguridad:

sudo apt install unattended-upgrades
sudo dpkg-reconfigure --priority=low unattended-upgrades

Responde "Sí" cuando te pregunte si quieres descargar e instalar actualizaciones automáticamente.

Paso 11: Monitorea los intentos de acceso

Saber quién intenta entrar (y cuándo) te da pistas sobre posibles ataques. Revisa los logs de SSH periódicamente:

sudo journalctl -u sshd

O si usas el sistema de logs tradicional:

sudo cat /var/log/auth.log | grep sshd

Verás líneas como Failed password for invalid user admin from 203.0.113.5 port 52340 ssh2. Si ves muchos intentos desde la misma IP, Fail2ban debería estar bloqueándola. Si no, puedes bloquearla manualmente:

sudo ufw deny from 203.0.113.5

Paso 12: Buenas prácticas adicionales de seguridad SSH

Para terminar, aquí tienes una lista de hábitos que marcan la diferencia:

• Mantén tus claves privadas seguras: guárdalas en un gestor de contraseñas o en un dispositivo cifrado. No las subas a servicios de nube sin cifrar.
• Usa frases de contraseña largas para tus claves. Cuanto más larga, mejor.
• Cambia tus claves periódicamente. Si sospechas que una clave se ha comprometido, revócala y genera una nueva.
• No compartas tu clave privada con nadie. Si trabajas en equipo, cada persona debe tener su propio par de claves.
• Desactiva el reenvío de agente SSH si no lo necesitas. En /etc/ssh/sshd_config, añade AllowAgentForwarding no.
• Usa un banner de advertencia legal si tu servidor es corporativo. En /etc/ssh/sshd_config, añade Banner /etc/ssh/banner y crea un archivo de texto con el aviso.

Preguntas frecuentes (FAQ) sobre seguridad SSH

¿Es obligatorio deshabilitar root SSH?
No es obligatorio, pero es altamente recomendable. Es una de las primeras cosas que los atacantes prueban. Deshabilitarlo cierra una puerta muy peligrosa.

¿Qué hago si pierdo mi clave privada?
Si pierdes la clave privada y has deshabilitado las contraseñas, no podrás acceder por SSH. Tendrás que usar la consola del proveedor del servidor (si la ofrece) para restaurar el acceso. Por eso, guarda una copia de seguridad de tu clave privada en un lugar seguro.

¿Puedo usar el mismo par de claves para varios servidores?
Sí, puedes, pero no es lo ideal. Si una clave se compromete, todos tus servidores están en riesgo. Es mejor generar un par de claves por servidor o por grupo de servidores.

¿Fail2ban es suficiente para detener ataques?
Fail2ban es una capa de defensa muy útil, pero no es infalible. Combínalo con las demás medidas de esta guía: claves SSH, firewall, puerto no estándar y deshabilitar root.

¿Qué es Syspanel y por qué usa el puerto 2106?
Syspanel es un panel de control para servidores (anteriormente llamado HestiaCP). Facilita la gestión de sitios web, correos y bases de datos. Su interfaz web se accede por el puerto 2106, por lo que si lo usas, debes tener ese puerto abierto en tu firewall y protegerlo con una contraseña fuerte.

Resumen: tu checklist de seguridad SSH

Si has llegado hasta aquí, ya tienes todo lo necesario para proteger tu servidor Linux con SSH. Repasemos rápido:

1. ✅ Genera claves SSH (Ed25519) con frase de contraseña.
2. ✅ Copia la clave pública al servidor.
3. ✅ Deshabilita el acceso por contraseña.
4. ✅ Deshabilita el acceso root por SSH.
5. ✅ Cambia el puerto SSH por defecto.
6. ✅ Crea un usuario con sudo para administrar.
7. ✅ Configura un firewall (ufw) y abre solo los puertos necesarios.
8. ✅ Limita los usuarios que pueden acceder por SSH.
9. ✅ Instala y configura Fail2ban.
10. ✅ Mantén el sistema actualizado automáticamente.
11. ✅ Revisa los logs de acceso periódicamente.

Con estos pasos, tu servidor estará mucho más seguro. Recuerda que la seguridad no es un destino, sino un proceso continuo. Revisa tus configuraciones de vez en cuando, mantente informado sobre nuevas vulnerabilidades y ajusta tus defensas según sea necesario.

Y si en algún momento te sientes abrumado, no pasa nada. Empieza por lo básico: deshabilitar root y usar claves SSH. Esos dos cambios ya eliminan la mayoría de los riesgos. Luego, ve añadiendo el resto de medidas poco a poco. Tu servidor te lo agradecerá.