Cambiar el puerto SSH 22: qué arregla y qué no

El resumen honesto

Sacar SSH del 22 recortará tu volumen de inicios de sesión fallidos en torno a un 90% de la noche a la mañana. También es cierto que no es un control de seguridad, y tratarlo como tal es la forma en que se comprometen servidores de administradores que creían haber terminado.

Ambas afirmaciones son ciertas porque responden a preguntas distintas. La caída de volumen es real, medible y útil. La protección es prácticamente nula frente a cualquiera que dedique treinta segundos a mirar.

¿Merece la pena? Normalmente sí — como reducción de ruido, junto a una defensa real, nunca en su lugar.

Lo que sí detiene

La inmensa mayoría del tráfico de ataque SSH viene de escáneres no dirigidos que hacen una sola cosa: conectarse al puerto 22 a lo largo de grandes rangos de IP y probar credenciales en lo que responda. No escanean puertos: comprobar un puerto en todo internet cuesta órdenes de magnitud menos que 65.535, y hay máquinas de sobra en el 22 para mantenerlos ocupados.

Múdate al 52200 y sales por completo de esa población. La gráfica se desploma, el registro de autenticación deja de rotar cada pocas horas, y volver a encontrar un evento real en él pasa a ser posible.

Ese último punto está infravalorado. Un registro legible vale dinero durante un incidente, y con tres mil fallos al día no tienes uno.

Lo que no detiene

Cualquiera que escanee todo el rango de puertos te encuentra en minutos. SSH se anuncia en claro — el banner de versión es lo primero que envía el servicio — así que un escáner que recorra todos los puertos y lea banners etiquetará tu servicio correctamente a la primera.

Shodan y Censys hacen exactamente eso de forma continua y publican los resultados como un índice consultable. Tu puerto SSH no estándar está ahí, localizable por cualquiera, en cuestión de días.

Así que frente a un bot no dirigido, cambiar el puerto funciona. Frente a alguien que te ha elegido, le cuesta unos minutos. Y no hace nada contra contraseñas débiles, una clave filtrada, un sshd sin parchear o una aplicación vulnerable en el mismo host.

También hay un inconveniente activo: los puertos poco habituales rompen cosas. Los firewalls corporativos que permiten el 22 saliente bloquearán el 52200 saliente, y te enterarás por un compañero que no puede desplegar.

Cambiarlo sin quedarte fuera

Dos pasos faltan en la mayoría de guías y ambos te dejarán fuera en una distribución moderna: el etiquetado de puerto de SELinux en la familia RHEL, y la activación por socket de systemd en Debian y Ubuntu recientes, donde sshd ya no escucha por sí mismo.

Mantén tu sesión actual abierta todo el rato y ve por orden:

NEWPORT=52200

# 1. El firewall PRIMERO — antes de que sshd se mueva a ningún sitio
sudo ufw allow ${NEWPORT}/tcp                                          # Debian/Ubuntu con ufw
sudo firewall-cmd --permanent --add-port=${NEWPORT}/tcp && sudo firewall-cmd --reload   # familia RHEL

# 2. SELinux: etiquetar el puerto, o sshd se negará a enlazar (familia RHEL)
sudo semanage port -a -t ssh_port_t -p tcp ${NEWPORT} || \
  sudo semanage port -m -t ssh_port_t -p tcp ${NEWPORT}

# 3. Avisar a sshd. Mantener el 22 de momento — dos puertos, para no quedarte cortado
printf 'Port 22\nPort %s\n' "$NEWPORT" | sudo tee /etc/ssh/sshd_config.d/20-port.conf
sudo sshd -t                            # comprobación de sintaxis antes de recargar

# 4. Activación por socket: en Debian/Ubuntu recientes sshd no enlaza por sí mismo
systemctl is-enabled ssh.socket 2>/dev/null && \
  echo 'ssh.socket está activo — hay que sobrescribir ListenStream ahí, ver la nota'

sudo systemctl reload ssh               # 'sshd' en la familia RHEL

Terminar la mudanza

Ahora verifica desde una segunda terminal en el puerto nuevo — ssh -p 52200 user@server — antes de tocar nada más. Solo cuando eso funcione, quita Port 22 de la configuración, recarga otra vez y cierra la regla antigua del firewall.

Después actualiza todo lo que guardaba el puerto viejo: entradas de ~/.ssh/config, scripts de despliegue, runners de CI, inventarios de Ansible, comprobaciones de monitorización, tareas de copia de seguridad y la documentación de tu equipo. Un cambio de puerto que rompe la copia nocturna es peor que no cambiarlo.

No quites el puerto 22 antes de confirmar que el nuevo funciona desde fuera de tu red. Dentro de la LAN funciona igual, que es exactamente como la gente se convence de que va bien.

Con qué combinarlo

Cambiar el puerto reduce el ruido. Algo tiene que seguir gestionando los intentos que llegan — y tras un cambio de puerto, los que llegan vienen de alguien que te buscaba específicamente, que son precisamente los que te importan.

SSH Protector detecta el puerto SSH real desde la configuración efectiva de sshd en lugar de asumir el 22, así que un servidor ya movido queda cubierto sin configurar nada, y reconstruye sus reglas si el puerto vuelve a cambiar.

Cambia el puerto para tener un registro legible. Mantén una defensa para el tráfico que te encuentra igualmente.