Cómo frenar los ataques de fuerza bruta SSH

Comprobar si te están atacando

El demonio SSH registra cada intento fallido. Cuenta las últimas 24 horas y mira qué direcciones envían más:

sudo journalctl --since "24 hours ago" | grep -cE "Failed password|Invalid user"

sudo journalctl --since "24 hours ago" \
  | grep -E "Failed password|Invalid user" \
  | grep -oE "from [0-9a-fA-F.:]+ port" | awk '{print $2}' \
  | sort | uniq -c | sort -rn | head -20

Cientos o miles de líneas al día son lo normal para un servidor con IP pública. Si el journal no se conserva entre reinicios, las mismas líneas están en /var/log/auth.log en Debian y Ubuntu y en /var/log/secure en la familia RHEL.

Configurar las claves SSH y probarlas primero

Todo lo que sigue desactiva las contraseñas, así que primero necesitas una clave que funcione. En tu ordenador, crea una clave, cópiala al servidor y entra con ella. Sustituye deploy por tu usuario y SERVER_IP por la dirección del servidor.

ssh-keygen -t ed25519 -C "laptop"
ssh-copy-id -i ~/.ssh/id_ed25519.pub deploy@SERVER_IP
ssh -i ~/.ssh/id_ed25519 deploy@SERVER_IP

El último comando debe dejarte entrar sin pedir la contraseña de la cuenta (puede pedir la frase de paso de la clave, que se queda en tu ordenador).

Crear un usuario sudo antes de desactivar root

Si hoy entras como root, crea primero un usuario normal con permisos de sudo y dale las mismas claves.

sudo adduser deploy
sudo usermod -aG sudo deploy

sudo useradd -m deploy
sudo passwd deploy
sudo usermod -aG wheel deploy

sudo mkdir -p /home/deploy/.ssh
sudo cp /root/.ssh/authorized_keys /home/deploy/.ssh/
sudo chown -R deploy:deploy /home/deploy/.ssh
sudo chmod 700 /home/deploy/.ssh
sudo chmod 600 /home/deploy/.ssh/authorized_keys

sudo restorecon -R /home/deploy/.ssh

Desde el segundo terminal, entra con el nuevo usuario y ejecuta sudo -v: debe aceptar la contraseña del usuario. Solo entonces sigue adelante.

Desactivar el acceso con contraseña y el de root

Las versiones actuales de Debian, Ubuntu, la familia RHEL 9 y Fedora leen archivos adicionales de /etc/ssh/sshd_config.d/. Comprueba que la tuya lo hace:

grep -i '^Include' /etc/ssh/sshd_config

Si muestra Include /etc/ssh/sshd_config.d/*.conf, escribe los ajustes en un archivo propio. SSH se queda con el primer valor que lee para cada ajuste, y los archivos se leen por orden de nombre, así que el prefijo 00- gana a archivos como 50-cloud-init.conf, que en algunas imágenes cloud vuelve a activar las contraseñas.

sudo tee /etc/ssh/sshd_config.d/00-hardening.conf > /dev/null <<'EOF'
PubkeyAuthentication yes
PasswordAuthentication no
KbdInteractiveAuthentication no
PermitRootLogin no
MaxAuthTries 4
LoginGraceTime 30
EOF

Si no hay línea Include (RHEL 8 y sus derivadas), pon las mismas seis líneas directamente en /etc/ssh/sshd_config, en lugar de las que ya existen. Después prueba la configuración y mira los valores que SSH va a usar de verdad:

sudo sshd -t && echo "config OK"
sudo sshd -T | grep -Ei '^(pubkeyauthentication|passwordauthentication|kbdinteractiveauthentication|permitrootlogin|maxauthtries) '

Cada línea debe mostrar el valor que has puesto. Si root todavía tiene que entrar con una clave, por ejemplo para una copia de seguridad, usa PermitRootLogin prohibit-password en lugar de no. Recarga SSH: las sesiones abiertas siguen conectadas.

sudo systemctl reload ssh

sudo systemctl reload sshd

ssh -o PubkeyAuthentication=no -o PreferredAuthentications=password deploy@SERVER_IP

Cambiar el puerto SSH, sabiendo lo que no resuelve

Sacar SSH del puerto 22 reduce el ruido en los logs, porque la mayoría de los bots solo prueban el 22. No hace SSH más seguro: los escáneres de puertos encuentran el nuevo puerto en pocas horas, y un atacante con un objetivo concreto, enseguida. Con acceso solo por clave, el puerto importa poco. Hazlo para tener logs más limpios, no por seguridad, y solo después de los pasos anteriores.

Elige un puerto (aquí el 2222), ábrelo en el firewall y, en la familia RHEL, dile a SELinux que SSH puede usarlo:

sudo ufw allow 2222/tcp

sudo firewall-cmd --permanent --add-port=2222/tcp
sudo firewall-cmd --reload
sudo dnf install -y policycoreutils-python-utils
sudo semanage port -a -t ssh_port_t -p tcp 2222

Abre el puerto también en el firewall cloud o el security group de tu proveedor. Después configura el puerto y reinicia SSH:

echo "Port 2222" | sudo tee /etc/ssh/sshd_config.d/01-port.conf
sudo sshd -t && echo "config OK"

En Ubuntu 24.04 y posteriores, SSH puede arrancarlo ssh.socket: si el primer comando de abajo muestra active, ejecuta las cuatro líneas; si no, solo la última.

systemctl is-active ssh.socket
sudo systemctl daemon-reload
sudo systemctl restart ssh.socket
sudo systemctl restart ssh

sudo systemctl restart sshd

ssh -p 2222 deploy@SERVER_IP

Banear a quien insiste con fail2ban o sshguard

Con las contraseñas desactivadas los intentos no pueden tener éxito, pero banear las direcciones que siguen probando reduce la carga y el ruido. fail2ban lee el log y banea una dirección en el firewall tras un número de fallos.

sudo apt update
sudo apt install -y fail2ban python3-systemd

sudo dnf install -y epel-release
sudo dnf install -y fail2ban

En RHEL y Oracle Linux, activa EPEL como indica su documentación y después instala fail2ban. En Fedora está en los repositorios principales. Amazon Linux 2023 no puede usar EPEL: usa en su lugar el límite del firewall que se explica más abajo.

Los ajustes van en jail.local, nunca en jail.conf, que las actualizaciones sobrescriben. Comprueba que no tienes ya uno y después créalo. Sustituye YOUR_OFFICE_IP por las direcciones fijas desde las que trabajas, o bórralo, y pon en port tu puerto SSH si lo has cambiado.

ls -l /etc/fail2ban/jail.local

sudo tee /etc/fail2ban/jail.local > /dev/null <<'EOF'
[DEFAULT]
ignoreip = 127.0.0.1/8 ::1 YOUR_OFFICE_IP
bantime = 1h
bantime.increment = true
findtime = 10m
maxretry = 5

[sshd]
enabled = true
backend = systemd
port = ssh
EOF

Así se banea una dirección durante una hora tras 5 fallos en 10 minutos, y durante más tiempo cada vez que vuelve. backend = systemd lee el journal, lo que funciona en Debian 12 y posteriores, donde /var/log/auth.log puede no existir.

sudo systemctl enable --now fail2ban
sudo fail2ban-client status sshd

Durante un ataque, Total failed y Currently banned crecen en pocos minutos. Si Total failed se queda en 0 mientras el journal muestra accesos fallidos, la jail no está leyendo el log correcto. Para levantar un baneo:

sudo fail2ban-client set sshd unbanip 203.0.113.7

sshguard, la alternativa más ligera

sshguard hace el mismo trabajo con menos configuración y está empaquetado para Debian y Ubuntu (y en EPEL). Pon primero tus propias direcciones en su lista blanca y después mira sudo journalctl -u sshguard -f durante un ataque para ver los bloqueos. Usa uno de los dos, no ambos.

sudo apt install -y sshguard
echo "YOUR_OFFICE_IP" | sudo tee -a /etc/sshguard/whitelist
sudo systemctl restart sshguard

Limitar o restringir SSH en el firewall

En Ubuntu y Debian con ufw, limit rechaza una dirección que abre 6 o más conexiones en 30 segundos. Sustituye a una regla allow 22/tcp simple. Si sudo ufw status muestra también una regla OpenSSH, bórrala cuando el límite esté activo (sudo ufw delete allow OpenSSH): se aplicaría antes que el límite.

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

Las rich rules de firewalld tienen un limit, pero cuenta todos los orígenes juntos, así que un ataque puede agotar el cupo y dejarte fuera también a ti. En la familia RHEL, usa fail2ban para los límites por dirección.

Permitir SSH solo desde tus direcciones

El paso más fuerte, si trabajas desde direcciones fijas o una VPN: nadie más puede siquiera llegar a SSH.

sudo ufw allow from YOUR_OFFICE_IP to any port 22 proto tcp
sudo ufw delete limit 22/tcp
sudo ufw status numbered

sudo firewall-cmd --permanent --zone=trusted --add-source=YOUR_OFFICE_IP
sudo firewall-cmd --reload
sudo firewall-cmd --permanent --zone=public --remove-service=ssh
sudo firewall-cmd --reload

Preguntas

¿Basta con cambiar el puerto SSH para frenar la fuerza bruta?

No. Reduce el número de intentos en los logs, porque la mayoría de los bots solo prueban el puerto 22, pero los escáneres encuentran el nuevo puerto enseguida. Lo que hace inútiles los intentos es el acceso solo con clave.

¿Uso fail2ban o sshguard?

Para SSH sirven los dos. fail2ban tiene más filtros para otros servicios y más opciones; sshguard necesita menos configuración. Usa uno, no los dos, para que no se peleen por las mismas direcciones.

He desactivado las contraseñas y sigo viendo accesos fallidos. ¿Pasa algo?

No. Los bots siguen probando porque no saben que las contraseñas están desactivadas. Los intentos fallan antes de que se compruebe ninguna contraseña. Los baneos y los límites reducen el ruido.