Reforzar SSH: lista de comprobación para asegurar un VPS Linux

1. Actualiza el sistema y activa las actualizaciones de seguridad automáticas

Instala primero las actualizaciones pendientes: apt update refresca las listas de paquetes y apt upgrade instala las versiones nuevas. [1]

sudo apt update
sudo apt upgrade

En Ubuntu, las actualizaciones de seguridad se instalan solas mediante el paquete unattended-upgrades, que viene instalado por defecto y se ejecuta una vez al día. Los dos valores de /etc/apt/apt.conf.d/20auto-upgrades deben ser «1», y una simulación muestra qué instalaría. [1]

cat /etc/apt/apt.conf.d/20auto-upgrades
sudo unattended-upgrade --dry-run -v

APT::Periodic::Update-Package-Lists "1";
APT::Periodic::Unattended-Upgrade "1";

El paquete no reinicia el servidor por sí solo, porque Unattended-Upgrade::Automatic-Reboot está en false por defecto, así que reinícialo a mano cuando una actualización lo requiera. [1] En Debian 12, si falta el paquete o el archivo, instala unattended-upgrades y crea el archivo con las dos líneas de arriba.

2. Crea un usuario con sudo que no sea root

Haz las tareas de administración con tu propio usuario y sudo, que pide la contraseña de ese usuario, no la de root. Con este comando, los miembros del grupo sudo obtienen acceso root completo. [2]

sudo adduser deploy
sudo adduser deploy sudo

adduser pide una contraseña y algunos datos opcionales. [2] Elige una contraseña larga: SSH usará claves, pero sudo te la seguirá pidiendo. Después comprueba la cuenta; sudo whoami debe mostrar root.

su - deploy
sudo whoami

En Debian 12, si no tienes el comando sudo, instálalo antes como root con apt install sudo.

3. Genera una clave ed25519 en tu equipo

Crea el par de claves en tu propio equipo, no en el servidor. Ubuntu recomienda el tipo ed25519 porque sus claves son más cortas y su coste computacional es menor, y ssh-keygen pide una frase de contraseña que protege la clave privada. [3]

ssh-keygen -t ed25519

Deja el nombre de archivo predeterminado. La clave privada es ~/.ssh/id_ed25519; la pública, la que copias a los servidores, es ~/.ssh/id_ed25519.pub. [3]

En Windows, ejecuta el mismo comando en PowerShell; el par se guarda en la carpeta .ssh de tu perfil de usuario. Microsoft desaconseja dejar vacía la frase de contraseña y advierte de que cualquiera que consiga la clave privada puede iniciar sesión como tú. [4]

ssh-keygen -t ed25519

4. Copia la clave pública al servidor

En Linux y macOS, ssh-copy-id añade tu clave pública al final del archivo ~/.ssh/authorized_keys del usuario en el servidor. [3]

ssh-copy-id deploy@203.0.113.10

La guía de Microsoft, en cambio, copia las claves con PowerShell o con scp. [4] Para un servidor Linux, esta línea añade tu clave y hace que solo tú puedas escribir en la carpeta y en el archivo:

Get-Content $env:USERPROFILE\.ssh\id_ed25519.pub | ssh deploy@203.0.113.10 "mkdir -p ~/.ssh && chmod 700 ~/.ssh && cat >> ~/.ssh/authorized_keys && chmod 600 ~/.ssh/authorized_keys"

sshd comprueba estos permisos antes de aceptar un inicio de sesión, con la opción StrictModes, que está activada por defecto. [5] Después ejecuta ssh deploy@203.0.113.10 en otra ventana de terminal: deberías entrar sin la contraseña de la cuenta. Si no es así, observa en tiempo real el log de SSH del servidor mientras vuelves a intentarlo: [3]

sudo journalctl -fu ssh.service

5. Escribe tus ajustes en un archivo drop-in

En Ubuntu, /etc/ssh/sshd_config empieza con Include /etc/ssh/sshd_config.d/*.conf, y, en la mayoría de los ajustes, OpenSSH se queda con el primer valor que lee, así que los archivos de esa carpeta tienen prioridad sobre el archivo principal. [3] Los archivos incluidos se leen en orden lexicográfico y, para cada palabra clave, gana el primer valor que obtiene sshd, [5] así que llama al tuyo 00-hardening.conf.

PermitRootLogin no
PasswordAuthentication no
KbdInteractiveAuthentication no
AllowUsers deploy

Según el manual de sshd_config:

• PermitRootLogin no impide que root inicie sesión por SSH. El valor por defecto, prohibit-password, rechaza las contraseñas de root, pero sigue aceptando claves. [5]
• PasswordAuthentication no desactiva el inicio de sesión con contraseña, que está permitido por defecto. [5]
• KbdInteractiveAuthentication no desactiva el inicio de sesión keyboard-interactive (interactivo por teclado), un método distinto que también está activado por defecto; su nombre antiguo es ChallengeResponseAuthentication. [5]
• AllowUsers deploy (opcional) solo deja iniciar sesión a los usuarios de la lista. A diferencia de la mayoría de las palabras clave, cada línea AllowUsers amplía la lista. [5] Escribe el nombre sin errores, o no podrá entrar nadie.

A partir de ahora, trata la cuenta con sudo como si fuera root: las notas del paquete openssh de Ubuntu consideran que, frente a ataques externos, cualquier cuenta desde la que se pueda escalar a root equivale a root. [6] En Debian 12, comprueba primero la línea Include con grep -n Include /etc/ssh/sshd_config.

6. Busca archivos que vuelvan a activar las contraseñas

Como gana el primer valor, cualquier archivo que vaya antes que el tuyo en ese orden tiene prioridad sobre él. Revisa la carpeta:

ls /etc/ssh/sshd_config.d/
sudo grep -riE 'passwordauthentication|kbdinteractive|permitrootlogin|allowusers' /etc/ssh/sshd_config /etc/ssh/sshd_config.d/

En las imágenes para la nube, cloud-init escribe los ajustes de SSH que gestiona en /etc/ssh/sshd_config.d/50-cloud-init.conf siempre que sshd_config incluya esa carpeta. [7] Si ese archivo contiene PasswordAuthentication yes, tiene prioridad sobre todos los archivos que van después, y por eso el tuyo empieza por 00. Cámbialo también a no para que los archivos coincidan.

7. Comprueba la configuración y reinicia SSH

Comprueba los archivos antes de reiniciar: un ajuste erróneo puede impedir que sshd arranque, y SSH puede ser tu única forma de entrar. [3]

sudo sshd -t
sudo systemctl restart ssh.service

Corrige primero todo lo que señale sshd -t. Después del reinicio, mantén tu sesión abierta y prueba desde una segunda ventana de terminal:

ssh deploy@203.0.113.10
ssh root@203.0.113.10

El primer inicio de sesión debe funcionar, y el servidor debe rechazar el segundo. Si no puedes entrar, deshaz el cambio en la sesión abierta y revisa el log de SSH del paso 4. [3]

8. Cambia el puerto en Ubuntu 24.04 (opcional)

En Ubuntu 24.04, ssh.socket escucha en el puerto 22 mediante la activación por socket de systemd. Un generador convierte las líneas Port de sshd_config y de sus archivos drop-in en ajustes del socket, así que, después de cambiar el puerto, hay que recargar systemd y reiniciar ssh.socket. [6]

sshd admite más de una línea Port, [5] así que mantén el 22 mientras pruebas el nuevo puerto:

Port 22
Port 2222

sudo sshd -t
sudo systemctl daemon-reload
sudo systemctl restart ssh.socket

Prueba el nuevo puerto desde una segunda ventana de terminal. Después borra Port 22, repite los tres comandos y usa el puerto 2222 en los pasos 9 y 10.

ssh -p 2222 deploy@203.0.113.10

En Debian 12, comprueba primero si se usa el socket. Si está inactivo, basta con reiniciar el servicio para aplicar el cambio.

systemctl is-active ssh.socket
sudo systemctl restart ssh.service

9. Permite SSH en UFW y después actívalo

UFW viene instalado pero desactivado y, una vez activado, deniega por defecto el tráfico entrante. Su manual advierte de que ufw enable puede cortar las conexiones SSH, así que añade primero la regla de SSH. [8]

Para SSH, usa limit en lugar de allow. Una regla limit sigue permitiendo las conexiones, pero deniega el acceso a una dirección que intente abrir 6 o más en 30 segundos. No añadas las dos reglas, porque UFW aplica la primera regla que coincide. [8]

sudo ufw limit 22/tcp
sudo ufw enable
sudo ufw status verbose

UFW pide confirmación cuando lo activas por SSH. [8] Si has movido SSH a otro puerto, limita 2222/tcp en su lugar. En Debian 12, si no tienes el comando, instala UFW primero. Para que SSH no sea accesible en absoluto desde internet, accede a él solo a través de una red privada con WireGuard. Para protegerte más allá del propio servidor, consulta nuestra lista de comprobación de protección DDoS para VPS.

10. Añade Fail2ban con la jail sshd

En Ubuntu 24.04, el paquete incluye /etc/fail2ban/jail.d/defaults-debian.conf, que activa la jail sshd, define backend = systemd y aplica los bloqueos mediante nftables. [9] El backend systemd lee el journal de systemd, así que la jail no necesita un archivo de log aparte. [10]

sudo apt install fail2ban
cat /etc/fail2ban/jail.d/defaults-debian.conf

El propio jail.conf de Fail2ban bloquea una dirección durante 10 minutos cuando esta acumula 5 fallos en 10 minutos, y te pide que no edites ese archivo: pon tus cambios en jail.local. [10]

[sshd]
enabled = true
backend = systemd
maxretry = 5
findtime = 10m
bantime = 1h
ignoreip = 127.0.0.1/8 ::1 198.51.100.7

Sustituye 198.51.100.7 por tu propia dirección fija, o bórrala. La jail que viene de serie usa port = ssh, así que añade port = 2222 si has movido SSH. [10] En Debian 12, deja backend = systemd aquí e instala python3-systemd, la biblioteca de Python para systemd que usa este backend. [10] Después reinicia Fail2ban y comprueba que está en marcha:

sudo systemctl restart fail2ban
sudo systemctl status fail2ban

11. Comprueba qué más está escuchando

Cada puerto abierto es otra vía de entrada. El informe de puertos en escucha de UFW muestra cada puerto TCP en escucha y cada puerto UDP abierto, su dirección (* significa todas las interfaces), el programa que hay detrás y las reglas que se le aplican. [8]

sudo ufw show listening

Un servicio que escucha en 127.0.0.1 solo es accesible desde el propio servidor. Desactiva los servicios públicos que no necesites con systemctl disable --now, como hacen las notas de openssh de Ubuntu con ssh.socket. [6]

sudo systemctl disable --now SERVICE_NAME