Lo esencial que conviene tener claro antes de tocar SSH
- SSH usa 22/TCP por defecto, pero el número del puerto no es una medida de seguridad por sí sola.
- La sesión va cifrada y el servidor se autentica, así que el riesgo real suele estar en credenciales, exposición y reglas mal configuradas.
- Desde una red doméstica, abrir acceso al exterior cambia por completo la superficie de ataque, aunque estés detrás de un router.
- Cambiar a un puerto alternativo puede reducir ruido automatizado, pero no sustituye a las llaves, el filtrado por IP ni los logs.
- Para la mayoría de casos, lo más útil es limitar usuarios, desactivar contraseñas débiles y comprobar la huella del host.
Qué hace realmente el puerto 22 en una conexión SSH
Yo no lo interpreto como un “puerto mágico”, sino como el punto de escucha habitual del servicio SSH en el servidor. Cuando un equipo acepta conexiones en ese puerto, está esperando sesiones seguras para entrar por terminal, transferir archivos con SFTP o incluso tunelizar tráfico entre máquinas.
Ese detalle importa porque SSH no se limita a “abrir una consola remota”. En entornos reales también se usa para automatización, copias, saltos entre servidores y administración de infraestructura. Por eso el 22 suele estar tan presente en routers, VPS y equipos de red: centraliza tareas que, si se hicieran por servicios inseguros, dejarían demasiada información expuesta.
La idea clave es sencilla: el puerto identifica el servicio, pero no dice nada por sí mismo sobre si la sesión será segura o no. Esa seguridad depende de cómo autenticas, qué usuarios permites y desde qué red aceptas conexiones. Con eso ya se ve por qué el siguiente paso no es cambiar números al azar, sino entender cómo viaja la sesión.
Cómo viaja la sesión y por qué el cifrado cambia el riesgo
SSH funciona sobre TCP/IP y monta un canal cifrado entre cliente y servidor. En términos prácticos, eso significa que usuario, comandos, archivos y salida de terminal viajan protegidos, con autenticación del servidor e integridad de los datos. Yo suelo resumirlo así: no solo oculta el contenido, también evita que se manipule la conversación sin que lo notes.
La parte que muchos pasan por alto es la verificación de la huella del host. La primera vez que te conectas, el cliente te pide aceptar la clave pública del servidor; si esa huella cambia sin una razón clara, hay que desconfiar. Ese hábito vale tanto en una red doméstica como en una WiFi pública, porque el cifrado protege el contenido, pero no corrige un servidor equivocado o comprometido.
También conviene distinguir entre autenticación por contraseña y por clave pública. La contraseña es más cómoda al principio, pero la clave reduce mucho el margen de ataque por fuerza bruta y, si además añades una frase de paso, la barrera sube bastante. Cuando alguien me pide una recomendación corta, casi siempre empiezo por ahí antes que por cualquier cambio cosmético de puerto.
Con este esquema claro, ya se entiende mejor dónde está el riesgo real: no en el nombre del servicio, sino en cómo lo expones y qué permiso le das para entrar.
Qué pasa cuando expones SSH en Internet
La diferencia entre un acceso interno y uno publicado es enorme. Dentro de tu red local, SSH suele quedar detrás del router y solo es visible para equipos de la LAN. En cuanto abres reenvío de puertos o publicas la máquina en la nube, pasas a estar en el escaparate de escaneos automáticos, pruebas de contraseña y enumeración de servicios.
En una red WiFi doméstica esto se ve muy claro: tu portátil puede hablar con el servidor sin problema dentro de casa, pero si el router redirige el acceso hacia fuera, el servicio queda expuesto a cualquier IP de Internet. El riesgo no viene de que SSH sea “malo”, sino de que dejas de controlar el origen de las conexiones. Y ahí es donde aparecen los problemas de verdad: usuarios genéricos, contraseñas débiles, root accesible o falta de limitación por IP.
Yo separo dos escenarios. Si solo administras una máquina dentro de casa o en una red privada, la prioridad es que no salga nunca al exterior salvo que lo necesites. Si administras un VPS o un servidor de producción, entonces el foco está en reducir el ruido y endurecer la entrada, porque las sondas automáticas no paran. Ese matiz es importante antes de decidir si conviene mover el servicio a otro puerto o no.
Cuándo merece la pena cambiar el puerto y cuándo no
Cambiar el puerto de escucha puede ser útil, pero no por el motivo que mucha gente cree. Lo que consigue, sobre todo, es reducir el ruido de bots que escanean de forma masiva el valor por defecto. No evita un ataque dirigido, no compensa una contraseña pobre y no sustituye a un firewall bien hecho. Si alguien cree que mover SSH a 2222 lo vuelve invisible, se está engañando.
Yo lo veo así: si ya tienes llaves, filtrado y registro correcto, moverlo a un puerto alternativo puede tener sentido operativo. Si todavía dependes de contraseñas y no has cerrado el acceso por origen, cambiar el número aporta muy poco.
| Escenario | Qué haría | Por qué |
|---|---|---|
| Servidor con acceso público | Mantendría SSH bien endurecido y, si hace falta, usaría un puerto alternativo como 2222 o 22022 | Reduce el ruido automatizado, pero solo como capa secundaria |
| NAS o Raspberry Pi detrás del router | Preferiría VPN antes que publicar SSH directamente | La red privada queda cerrada y no expones el panel de administración al exterior |
| Entorno con varios administradores | Limitaría usuarios permitidos y acceso por IP | La reducción de superficie de ataque pesa más que el número de puerto |
| Migración temporal o pruebas | Usaría un puerto adicional durante el cambio | Permite validar el acceso antes de cerrar el anterior sin quedarte fuera |
La conclusión práctica es incómoda, pero útil: el puerto alternativo ayuda como filtro de ruido, no como blindaje. Si esa parte ya la tienes asumida, la conversación útil pasa a ser otra: cómo cerrar de verdad el acceso sin perder control administrativo.
Cómo dejar SSH bien cerrado sin romper el acceso
Cuando endurezo SSH, sigo un orden muy concreto para no bloquearme yo mismo. Primero abro una segunda sesión antes de tocar nada. Luego compruebo que la autenticación por clave funciona. Después limito usuarios, cierro contraseñas si puedo y solo al final reviso el firewall o el puerto de escucha. Ese orden evita el clásico error de dejar el servicio inaccesible por una mala regla.
| Medida | Qué mejora | Cuándo la aplico |
|---|---|---|
| Llaves SSH con frase de paso | Eleva mucho la barrera frente a fuerza bruta | Siempre que el acceso no sea puntual |
| Desactivar contraseña | Elimina el vector más débil | Cuando todos los usuarios ya han migrado a claves |
| Restringir usuarios permitidos | Reduce intentos sobre cuentas innecesarias | En servidores con acceso administrativo real |
| Filtrar por IP o VPN | Limita desde dónde puede entrar alguien | En equipos expuestos a Internet o con datos sensibles |
| Revisar registros | Detecta patrones raros y errores de acceso | Siempre, aunque el sistema parezca estable |
Si trabajas con Linux, merece la pena revisar los registros de acceso con journalctl -u ssh o con el servicio equivalente de tu distribución. Cuando veo muchos fallos seguidos, casi nunca me preocupa el “puerto” en sí; me preocupa la combinación de credenciales flojas, demasiada superficie expuesta y ausencia de alertas. Esa es la parte que de verdad termina causando incidentes.
Lo que yo revisaría hoy en una configuración con SSH
Si tuviera que auditar un acceso SSH ahora mismo, empezaría por tres comprobaciones: que solo escuche donde debe, que use llaves en lugar de contraseñas cuando sea posible y que no esté accesible desde cualquier red sin necesidad. En una red doméstica, eso suele significar no publicar el servicio al exterior salvo caso muy justificado. En un servidor profesional, significa combinar restricciones de origen, registro y autenticación fuerte.
- Confirmar que la huella del host coincide antes de conectarte desde un equipo nuevo.
- Evitar usuarios genéricos y cerrar el acceso directo de administración si no es imprescindible.
- No confiar en el cambio de puerto como medida principal de seguridad.
- Preferir VPN o acceso privado cuando la máquina no necesita estar expuesta a todo Internet.
La lectura práctica es esta: SSH sigue siendo una de las herramientas más útiles de redes y administración remota, pero solo funciona bien cuando lo acompañas de disciplina operativa. Si dejas bien cerrada la entrada, el canal cifrado hace su trabajo; si no, el servicio más cómodo puede convertirse en el punto de entrada más evidente de toda la red.
