Cómo Cambiar el Puerto SSH en Linux (y Por Qué Deberías Hacerlo)
Si tienes un servidor Linux accesible desde internet, el puerto 22 está siendo escaneado ahora mismo. Los bots de fuerza bruta buscan ese puerto de forma continua y automatizada, probando combinaciones de usuario y contraseña durante horas. No es paranoia: es la realidad de cualquier servidor expuesto.
Cambiar el puerto SSH por defecto no es una medida de seguridad definitiva —un escaneo completo de puertos como el que hace Nmap lo encontraría igualmente— pero sí elimina el 99% de los ataques automatizados que apuntan ciegamente al puerto 22. Es una medida de reducción de ruido y superficie de ataque que cualquier sysadmin debería aplicar desde el primer día.
Antes de empezar: asegúrate de tener acceso alternativo al servidor (consola, panel de control del VPS, acceso físico) por si algo sale mal. Nunca cierres la sesión SSH actual hasta haber verificado que el nuevo puerto funciona.
Contexto
¿Por qué el puerto 22 es un problema?
El puerto 22 es el puerto estándar de SSH (Secure Shell), el protocolo que usamos para acceder remotamente a servidores Linux. Por ser estándar, es el primero que comprueban los bots y los scripts de ataque automatizados. Si revisas los logs de autenticación de cualquier servidor con el puerto 22 abierto verás algo así:
Failed password for root from 185.234.218.45 port 54832 ssh2
Failed password for admin from 45.129.14.92 port 41205 ssh2
Failed password for ubuntu from 91.240.118.14 port 38291 ssh2
Failed password for root from 194.165.16.72 port 52104 ssh2
Cientos de intentos por hora, de IPs de todo el mundo, probando usuarios comunes (root, admin, ubuntu, pi) con contraseñas de diccionario. Cambiar el puerto no los detiene si te buscan específicamente, pero elimina el ruido masivo de los ataques genéricos.
Guía práctica
Cómo cambiar el puerto SSH paso a paso
Proceso completo para Ubuntu, Debian y CentOS/RHEL. El procedimiento es prácticamente idéntico en todas las distribuciones.
Elige el nuevo puerto
Elige un puerto entre 1024 y 65535 que no esté en uso por otro servicio. Puertos comunes a evitar: 80 (HTTP), 443 (HTTPS), 3306 (MySQL), 5432 (PostgreSQL), 8080, 8443. Puertos que funcionan bien para SSH: 2222, 2200, 4422, 7822. Evita puertos demasiado obvios como 2222 si quieres reducir el escáneo.
Comprueba que el puerto elegido no está en uso:
ss -tlnp | grep :4422
Si no devuelve nada, el puerto está libre.
Edita el archivo de configuración SSH
Abre el archivo de configuración del servidor SSH con tu editor preferido:
sudo nano /etc/ssh/sshd_config
Busca la línea que contiene #Port 22 o Port 22. Descomenta la línea (quita el #) y cambia el número por el puerto elegido:
# Antes:
#Port 22
# Después:
Port 4422
⚠️ No cierres la sesión SSH actual hasta completar todos los pasos y verificar que el nuevo puerto funciona. Si cierras ahora y hay algún error, te quedarás sin acceso.
Abre el nuevo puerto en el firewall
Este paso es crítico. Si tienes firewall activo (UFW en Ubuntu/Debian, firewalld en CentOS) y no abres el nuevo puerto antes de reiniciar SSH, te quedarás sin acceso.
Con UFW (Ubuntu/Debian):
sudo ufw allow 4422/tcp
sudo ufw status
Con firewalld (CentOS/RHEL):
sudo firewall-cmd --permanent --add-port=4422/tcp
sudo firewall-cmd --reload
Con iptables:
sudo iptables -A INPUT -p tcp --dport 4422 -j ACCEPT
sudo iptables-save | sudo tee /etc/iptables/rules.v4
Si tu VPS tiene firewall propio en el panel de control (DigitalOcean, Hetzner, OVH…), también debes abrirlo ahí.
Reinicia el servicio SSH
Aplica los cambios reiniciando el daemon SSH. Dependiendo de tu distribución:
# Ubuntu / Debian (systemd)
sudo systemctl restart ssh
# CentOS / RHEL
sudo systemctl restart sshd
Verifica que el servicio está corriendo y escuchando en el nuevo puerto:
sudo systemctl status ssh
ss -tlnp | grep ssh
Verifica el acceso desde una nueva sesión
Sin cerrar la sesión actual, abre una nueva terminal y conéctate al servidor especificando el nuevo puerto:
ssh -p 4422 usuario@ip-del-servidor
Si la conexión funciona, ya puedes cerrar la sesión antigua. Si no funciona, revisa los pasos anteriores desde la sesión que tienes abierta.
Cierra el puerto 22 en el firewall
Una vez verificado que el nuevo puerto funciona, cierra el 22 para completar el cambio:
# UFW
sudo ufw deny 22/tcp
# firewalld
sudo firewall-cmd --permanent --remove-service=ssh
sudo firewall-cmd --reload
Actualiza también tu cliente SSH local para no tener que especificar el puerto cada vez. En ~/.ssh/config:
Host mi-servidor
HostName ip-del-servidor
User usuario
Port 4422
Con esto puedes conectar simplemente con ssh mi-servidor
Más allá del puerto
Otras medidas de seguridad SSH que deberías aplicar
Cambiar el puerto es el primer paso. Estas son las configuraciones adicionales que aplico en el sshd_config de cualquier servidor que securizo:
🔑 Autenticación por clave pública
Deshabilitar la autenticación por contraseña y usar solo claves SSH. El cambio más impactante en seguridad.
PasswordAuthentication no
PubkeyAuthentication yes
🚫 Deshabilitar acceso root
Nadie debería poder conectarse como root directamente. Usa un usuario normal con sudo.
PermitRootLogin no
⏱️ Limitar intentos fallidos con Fail2ban
Banear IPs automáticamente tras N intentos fallidos. Complemento perfecto al cambio de puerto.
sudo apt install fail2ban
👥 Limitar usuarios con acceso SSH
Solo los usuarios estrictamente necesarios deben poder conectarse por SSH.
AllowUsers rubén deploy
⏲️ Reducir el timeout de sesión
Cerrar sesiones inactivas automáticamente para evitar sesiones abiertas olvidadas.
ClientAliveInterval 300
ClientAliveCountMax 2
🌐 Restringir por IP con AllowFrom
Si siempre accedes desde la misma IP o rango, limita el acceso SSH solo a esas IPs en el firewall.
ufw allow from 85.x.x.x to any port 4422
Para empresas
¿Tu empresa tiene servidores Linux en producción sin auditar?
Cambiar el puerto SSH es una medida básica. En un servidor de producción hay una docena de configuraciones adicionales que marcan la diferencia entre un sistema seguro y uno que es una invitación abierta. En mis auditorías de seguridad de servidores reviso configuración SSH, permisos de usuarios, firewall, servicios expuestos, parches pendientes y mucho más.
Auditoría de seguridad de servidores
Revisión completa de la configuración de seguridad: SSH, firewall, usuarios, permisos, servicios expuestos y parches pendientes.
Hardening de sistemas Linux
Aplicación de medidas de seguridad preventivas siguiendo guías CIS Benchmark. Para servidores en producción con datos sensibles.
Soporte IT continuo
Mantenimiento proactivo de servidores, actualizaciones de seguridad y monitorización incluidos en el servicio de soporte IT mensual.
Preguntas frecuentes
Dudas habituales sobre el cambio de puerto SSH
¿Cambiar el puerto SSH es seguridad real o solo security through obscurity?
Es un poco de ambas cosas. No es una medida de seguridad robusta por sí sola — un escaneo completo de puertos con Nmap lo encontrará. Pero sí elimina el 99% de los ataques automatizados que solo apuntan al puerto 22. Úsalo como primera capa, no como única medida. La autenticación por clave pública es mucho más importante.
¿Qué hago si me quedo sin acceso al servidor?
Accede por consola desde el panel de control de tu proveedor (DigitalOcean, Hetzner, OVH, AWS…). Todos los proveedores ofrecen acceso de emergencia por consola sin necesidad de SSH. Desde ahí puedes revertir los cambios en /etc/ssh/sshd_config y reiniciar el servicio.
¿Necesito cambiar el puerto en SELinux o AppArmor?
En sistemas con SELinux activo (CentOS, RHEL, Fedora) sí. Debes informar a SELinux del nuevo puerto antes de reiniciar SSH, si no bloqueará el cambio. Ejecuta: semanage port -a -t ssh_port_t -p tcp 4422. AppArmor en Ubuntu generalmente no requiere cambios adicionales para SSH.
¿Puedo tener SSH escuchando en dos puertos a la vez?
Sí. Puedes añadir varias líneas Port en sshd_config. Útil durante la transición para no perder acceso mientras verificas que el nuevo puerto funciona correctamente antes de cerrar el 22.
¿Este proceso funciona igual en Ubuntu, Debian y CentOS?
El proceso es prácticamente idéntico. Las diferencias están en el gestor de firewall (UFW en Ubuntu/Debian, firewalld en CentOS/RHEL) y en el nombre del servicio SSH (ssh en Ubuntu/Debian, sshd en CentOS/RHEL). La edición del sshd_config es igual en todas.
¿Tienes servidores Linux en producción en tu empresa?
Una auditoría de seguridad detecta configuraciones inseguras antes de que lo haga alguien con malas intenciones. La hago de forma remota con informe detallado y plan de corrección.
Solicitar auditoría de seguridad →También disponible como parte del servicio de soporte IT mensual
