Cómo cambiar el puerto SSH predeterminado (22) y reducir escáneres automatizados

El puerto 22 es el objetivo predeterminado de prácticamente todo escáner automatizado de SSH en internet. Botnets como Mirai y sus variantes barren el rango IPv4 entero buscando específicamente servicios expuestos en el 22 — no porque sea el único puerto posible, sino porque es la apuesta con mayor retorno. Resultado: incluso una VPS recién aprovisionada acumula cientos de intentos de login fallidos por hora en los logs antes del primer deploy.

Cambiar el puerto predeterminado no es seguridad real contra un atacante dirigido. Un nmap -p- completo encuentra cualquier puerto SSH en segundos. Pero el objetivo aquí es otro: reducir el ruido operacional. Menos líneas en /var/log/auth.log, menos disparos de fail2ban, menos CPU gastada rechazando conexiones obviamente maliciosas. En tutoriales que recomiendan esto hay una trampa frecuente: el cambio en sshd_config por sí solo no funciona en distros modernas porque systemd intercepta el puerto vía socket activation.

Esta guía lleva cerca de 15 minutos y cubre el procedimiento completo en Ubuntu 22.04/24.04, Debian 12 y variantes RHEL — incluyendo el ajuste en el systemd socket, reglas de firewall con UFW y firewalld, configuración de SELinux cuando aplique, y la prueba obligatoria antes de cerrar la sesión actual.

Requisitos previos

Elegir el nuevo puerto

El nuevo puerto debe ser no privilegiado (por encima de 1024) para evitar la exigencia de root en rebinds, y fuera del rango de servicios conocidos. Rango recomendado: 1024–49151. Por encima de 49152 está el rango de puertos efímeros, que el kernel usa para conexiones de salida — funciona, pero técnicamente compite con sockets dinámicos.

Opciones comunes: 2200, 2222, 22022, 4422. Evita puertos asociados a otros servicios (3306 MySQL, 5432 PostgreSQL, 6379 Redis, 8080 HTTP alternativo). Para este tutorial vamos a usar 2222 como ejemplo — sustituye por el valor que elijas.

Antes de continuar, confirma que el puerto está libre en el servidor:

sudo ss -tlnp | grep :2222

Output esperado: vacío. Si aparece algún proceso, elige otro puerto.

Configurar sshd

sudo cp /etc/ssh/sshd_config /etc/ssh/sshd_config.bak

sudo nano /etc/ssh/sshd_config

Port 2222

sudo sshd -t

Ajustar el systemd socket (paso crítico)

En Ubuntu 22.04+, Debian 12+ y algunas versiones de Fedora, SSH se activa vía socket de systemd. Esto significa que systemd escucha en el puerto 22 y solo pasa la conexión al daemon cuando recibe una petición. Cambiar solo el sshd_config no tiene efecto en este caso — el socket sigue en el 22.

sudo systemctl status ssh.socket

sudo systemctl stop ssh.socket
sudo systemctl disable ssh.socket
sudo systemctl mask ssh.socket

sudo systemctl enable ssh

Liberar el nuevo puerto en el firewall

Este paso debe ocurrir ANTES de reiniciar SSH. Si reinicias primero, sshd va a empezar a escuchar en el 2222 pero el firewall va a bloquear las conexiones — y tu sesión actual puede quedar inestable durante el restart.

sudo ufw allow 2222/tcp comment 'SSH custom port'

sudo ufw status numbered

sudo firewall-cmd --permanent --add-port=2222/tcp
sudo firewall-cmd --reload

SELinux (solo RHEL/CentOS/Rocky/AlmaLinux)

En distros con SELinux en modo enforcing, la policy bloquea a sshd de hacer bind en puertos no marcados como ssh_port_t. Sin este ajuste, el servicio falla al reiniciar y el error aparece en /var/log/audit/audit.log.

sudo dnf install -y policycoreutils-python-utils

sudo semanage port -a -t ssh_port_t -p tcp 2222

sudo semanage port -l | grep ssh

Reiniciar y probar

sudo systemctl restart ssh

sudo ss -tlnp | grep ssh

ssh -p 2222 usuario@tu_ip_de_la_vps

Cerrar el puerto 22 antiguo

Solo haz este paso después de confirmar que SSH funciona estable en el 2222 por al menos 10 minutos en una sesión de prueba independiente.

sudo ufw delete allow 22/tcp

O en firewalld:

sudo firewall-cmd --permanent --remove-port=22/tcp
sudo firewall-cmd --reload

Confirma que el 22 ya no responde:

ss -tlnp | grep :22

Output esperado: vacío. A partir de aquí, cualquier conexión en el 22 cae inmediatamente en el firewall — exactamente el comportamiento que reduce el ruido en los logs.

Verificación final

Confirma todo de una vez con un snapshot del estado:

sudo ss -tlnp | grep ssh
sudo systemctl status ssh
sudo ufw status

Debes ver: SSH escuchando solo en el 2222, servicio active (running), firewall con 2222/tcp permitido y 22/tcp ausente. En 24 horas, compara el volumen de intentos fallidos:

sudo journalctl -u ssh --since '24 hours ago' | grep -c 'Failed password'

La caída esperada es del 90%+ en comparación con el 22 expuesto — el resto son escáneres que hacen range scan o ya mapearon tu IP.

Próximos pasos

Cambiar el puerto es solo el primer nivel de hardening. Próximos pasos recomendados:

• Deshabilitar autenticación por contraseña (PasswordAuthentication no en sshd_config) y usar solo claves SSH con ed25519.
• Configurar fail2ban con jail personalizado para el puerto nuevo — el filtro default del paquete asume 22 y necesita override.
• Restringir login root: PermitRootLogin prohibit-password (o no si tienes usuario sudo configurado).
• Habilitar autenticación de dos factores vía Google Authenticator (libpam-google-authenticator).
• Configurar logging centralizado para correlacionar intentos entre múltiples VPS.

Si estás corriendo esto en producción, una VPS Hostini ya viene con consola serial nativa en el panel — así que incluso si te bloqueas fuera por un error de firewall, es posible recuperar el acceso sin soporte. Conoce las opciones en /vps.