SSH cerrado, deploys abiertos: cómo actualizar tu servidor sin exponer el puerto 22
El puerto 22 abierto a internet es el error de seguridad más común en servidores cloud. Te explico cómo seguir haciendo deploys con SSH totalmente cerrado.
Cerrar el puerto 22 (SSH) suena a que te quedas sin acceso al servidor. No es así. Hoy existen mecanismos que permiten deployar, ejecutar comandos y depurar sin exponer SSH a internet.
El problema con SSH abierto
Cuando contratas un servidor cloud (AWS, DigitalOcean, Linode, Lightsail, etc.), por defecto te dan un servidor con SSH expuesto. Aunque uses contraseñas fuertes o llaves, tu servidor recibe miles de intentos de login por día de bots escaneando el internet.
Consecuencias:
- Logs llenos de intentos fallidos (ruido que oculta ataques reales).
- Riesgo de bug en SSH que abra una puerta nueva (ha pasado).
- Consumo de CPU atendiendo conexiones maliciosas.
- Si un día se te cuela una llave débil, se acabó el juego.
¿Y si mi pipeline necesita hacer deploy?
Aquí es donde casi todos tropiezan. Los pipelines (Azure DevOps, GitHub Actions, GitLab CI) corren desde IPs dinámicas, así que "abrir solo mi IP" no funciona.
Las opciones malas:
- Abrir SSH a todo internet (ya sabemos por qué no).
- Agregar los rangos de IPs de tu proveedor CI (son miles y cambian).
- Guardar tu llave SSH en el CI (si se filtra, perdiste el servidor).
La solución moderna: control remoto sin SSH
Los proveedores cloud grandes ya resolvieron esto. En AWS se llama Systems Manager (SSM); en Google Cloud, OS Config; en Azure, Run Command.
La idea es la misma en todos:
- Instalas un pequeño agente en el servidor.
- El agente se conecta hacia fuera al proveedor (no recibe conexiones).
- Tú (o tu pipeline) le mandas comandos al proveedor con permisos IAM.
- El proveedor reenvía los comandos al agente.
Resultado: tu servidor ejecuta comandos sin que el puerto 22 esté abierto. Cero IPs de entrada, cero riesgo de fuerza bruta.
Bonus: los logs quedan centralizados
Cuando usas SSH, los comandos que ejecutas se pierden (solo quedan en el history del servidor). Con SSM cada comando queda registrado con:
- Quién lo ejecutó (qué rol IAM).
- Cuándo.
- Qué se ejecutó exactamente.
- Qué respondió el servidor.
Para auditorías de seguridad esto vale oro.
¿Qué cambia en mi pipeline?
En lugar de:
ssh usuario@servidor "cd /app && docker-compose pull && docker-compose up -d"
Haces algo como:
aws ssm send-command \
--document-name "AWS-RunShellScript" \
--targets "Key=tag:Name,Values=produccion" \
--parameters "commands=['cd /app && docker-compose pull && docker-compose up -d']"
Misma funcionalidad, cero SSH expuesto.
¿Cuándo lo necesitas?
- Tu servidor está expuesto a internet (prácticamente todos los cloud lo están).
- Tu pipeline hace deploys remotos con llaves SSH guardadas.
- Tuviste algún incidente de brute force en el pasado.
- Te piden cumplimiento (ISO, SOC2, PCI) y no puedes justificar SSH abierto.
En ServerStack Solutions
Todos los servidores que configuramos llevan SSH cerrado y deploys automatizados con el mecanismo de control remoto del proveedor. Tú nunca ves una llave SSH, y tu pipeline tampoco la necesita.
Contáctanos si quieres una auditoría rápida de superficie de ataque.
Relacionado: Arquitectura segura en AWS y Nginx reverse proxy + firewall.
Preguntas frecuentes
¿Qué es AWS SSM Session Manager?
Es el servicio de AWS que te permite abrir una sesión interactiva al servidor sin tener puerto SSH abierto. En vez de tu máquina conectarse al servidor, el servidor se conecta a AWS y tú llegas por la consola. Auditable (AWS guarda los comandos ejecutados), sin llaves que gestionar, y sin puerto expuesto. Disponible gratis con EC2/Lightsail que tengan el agente.
¿Cómo hago deploys sin SSH?
Tres opciones estándar: (1) pipeline (Azure/GitHub Actions) dispara un SSM Run Command que ejecuta el deploy en el servidor; (2) el servidor escucha en Redis o Kafka un evento "deploy" y lo ejecuta él mismo (pull-based); (3) runner autohospedado en el servidor que escucha webhooks. Los tres evitan guardar llaves SSH en el pipeline.
¿Tailscale es seguro para producción?
Sí, ampliamente usado en empresas. Tailscale crea una red privada WireGuard entre dispositivos autenticados con tu SSO (Google, GitHub, etc.). Los servidores no exponen puertos al internet público; solo son accesibles dentro de la red Tailscale. Si pierdes acceso a tu SSO, también pierdes acceso a Tailscale — por eso siempre configuras un método de recuperación.