Durante años, una de las recomendaciones más comunes para proteger un servidor Linux fue utilizar llaves SSH en lugar de contraseñas. Y sí: una llave SSH es mucho más segura que una contraseña correctamente implementada. Pero el problema es pensar que una llave .ssh por sí sola hace seguro un servidor.
En 2026, los servidores expuestos a Internet están sometidos constantemente a escaneos automatizados. Bots recorren rangos completos de IP buscando puertos abiertos, servicios, versiones, configuraciones vulnerables y posibles puntos de entrada. Y ahora existe un factor adicional: la inteligencia artificial. La IA puede acelerar el análisis de grandes cantidades de información y ayudar a identificar patrones, configuraciones débiles y posibles vectores de ataque.
Por eso, la pregunta ya no debería ser "¿tengo una llave SSH?".
La pregunta correcta es: ¿cuántas capas de seguridad tiene mi infraestructura?
El problema de dejar SSH expuesto en Internet
El puerto TCP 22 es el puerto estándar utilizado por SSH. Cuando un servidor tiene el puerto 22 abierto públicamente, cualquiera puede intentar conectarse:
Todo Internet llega hasta tu SSH — la llave es la única barrera.
Tener una llave SSH correctamente configurada puede impedir que un atacante que no posee la llave se autentique. Pero eso no significa que sea buena práctica mantener SSH disponible públicamente para todo Internet. Si nadie necesita acceder a SSH desde Internet, ¿por qué debería estar expuesto?
La primera capa: cerrar el puerto 22
Para un servidor que publica únicamente una aplicación web, una arquitectura mucho más razonable es permitir únicamente los servicios que realmente necesita: 80 para HTTP y 443 para HTTPS. Todo lo demás — incluido SSH — cerrado desde Internet.
Denegar por defecto: el 22 y los servicios internos mueren en el firewall.
Esto reduce considerablemente la superficie de exposición. Pero hay una consideración importante: cerrar SSH no significa perder el acceso administrativo. Significa cambiar cómo se obtiene ese acceso.
¿Entonces cómo administramos el servidor?
Una opción mucho más robusta es utilizar una VPN para acceder a la red de administración. SSH puede continuar funcionando, pero no está disponible públicamente en Internet: el servidor acepta SSH únicamente desde la red privada de administración.
SSH sigue funcionando — pero ya no existe para Internet.
¿Y si necesito publicar una aplicación web?
Entonces normalmente necesitamos exponer el puerto 80 (HTTP) — en muchos escenarios solo para redireccionar tráfico hacia HTTPS o para procesos de validación — y el puerto 443 (HTTPS), que es el puerto realmente importante para una aplicación web moderna.
Cada salto es una capa con sus propias reglas.
Y la base de datos no debería estar expuesta directamente a Internet. Nunca.
Segunda capa: firewall
Cerrar el puerto 22 no sirve de mucho si posteriormente dejamos abiertos decenas de servicios que no necesitamos. El firewall debería seguir una regla sencilla: denegar por defecto y permitir únicamente lo necesario.
| Puerto | Servicio | Internet |
|---|---|---|
| 22 | SSH | ❌ Cerrado |
| 80 | HTTP | ✅ Abierto |
| 443 | HTTPS | ✅ Abierto |
| 5432 | PostgreSQL | ❌ Cerrado |
| 3306 | MySQL | ❌ Cerrado |
| 8000 | API interna | ❌ Cerrado |
| Otros | Servicios internos | ❌ Cerrado |
Los puertos y reglas exactos dependerán de la arquitectura, pero el principio es el mismo: no expongas un servicio simplemente porque está instalado.
Tercera capa: Cloudflare
Si quieres llevar la arquitectura un paso más adelante, puedes colocar servicios como Cloudflare delante de tu infraestructura. Cloudflare puede actuar como una capa adicional entre Internet y tu servidor, proporcionando CDN, protección contra determinados tipos de tráfico malicioso, WAF y otras capacidades de seguridad.
La seguridad no consiste en esconder el puerto 22
Cambiar SSH del puerto 22 al 2222, 2200 o cualquier otro puede disminuir algunos escaneos automáticos basados en el puerto estándar. Pero un scanner puede descubrir puertos. Cambiar el puerto no debe confundirse con proteger el servidor: es una medida secundaria.
La arquitectura debería preocuparse por preguntas de fondo:
- ¿Qué puertos están expuestos y qué servicios están escuchando?
- ¿Quién puede acceder y desde dónde?
- ¿Qué permisos tiene cada usuario?
- ¿Qué pasa si una credencial es comprometida?
- ¿Existe monitoreo y logs? ¿Cómo se detecta una intrusión?
- ¿Cómo se revoca un acceso y cómo se recupera el servidor?
Una llave SSH no es una muralla
Una llave SSH es una excelente herramienta de autenticación. Pero si tu arquitectura es Internet → puerto 22 → SSH → servidor, la única gran barrera entre Internet y el acceso administrativo termina siendo la autenticación SSH. Compárala con una arquitectura por capas:
Defensa en profundidad: cada capa puede detener lo que la anterior dejó pasar.
La diferencia es enorme. Eso es defensa en profundidad.
La era de la IA cambia el escenario
La seguridad informática siempre ha sido un problema. Pero la IA está modificando la velocidad a la que determinadas tareas pueden realizarse. Los atacantes pueden automatizar cada vez más procesos:
- 1Descubrir activos
- 2Identificar servicios
- 3Analizar respuestas
- 4Correlacionar información
- 5Buscar configuraciones vulnerables
- 6Priorizar objetivos
- 7Automatizar determinadas acciones
Por eso ya no es suficiente pensar "tengo una contraseña fuerte", "tengo una llave SSH" o "cambié el puerto 22". La seguridad debe plantearse como un sistema de capas.
Checklist básico de seguridad para un VPS
Antes de poner un servidor en producción, como mínimo deberías revisar:
Red
- Firewall habilitado con política de denegación por defecto
- Puerto 22 cerrado públicamente cuando no sea necesario
- Solo 80/443 expuestos cuando se trate de un servidor web
- Bases de datos sin exposición pública
- Servicios internos restringidos
SSH
- Autenticación por contraseña deshabilitada; acceso mediante llaves
- Acceso root directo deshabilitado
- Usuarios individuales con mínimo privilegio
- Acceso administrativo mediante VPN cuando sea posible
Aplicación
- HTTPS obligatorio
- Secretos fuera del código
- Dependencias actualizadas
- Logs habilitados y gestión adecuada de sesiones y autenticación
Infraestructura
- Sistema operativo, Docker y componentes actualizados
- Backups, monitoreo y alertas
- Plan de recuperación
Capa externa
- DNS correctamente configurado
- WAF cuando sea necesario
- Protección DDoS según el nivel de riesgo
- CDN / reverse proxy cuando aporte valor
La pregunta correcta
No preguntes "¿cómo escondo mi puerto SSH?". Pregunta "¿por qué mi servidor necesita estar expuesto a Internet?". Si la respuesta es únicamente "porque necesito administrarlo", entonces probablemente hay una arquitectura mejor: cerrar SSH al Internet público, mantener únicamente los servicios necesarios — por ejemplo 80 y 443 para una aplicación web — y utilizar una red privada o VPN para la administración. Y si el proyecto lo requiere, añadir capas como Cloudflare, WAF, monitoreo, segmentación y controles de acceso.
Porque en ciberseguridad no existe una única configuración mágica. Una llave .ssh no te va a salvar de una arquitectura insegura. La seguridad real está en las capas: menos superficie expuesta, más control, más visibilidad, más capas de defensa.