Ya argumentamos antes que el final del camino para SSH es sacarlo por completo de la internet pública — sin un listener que los escáneres encuentren, sin prompt que forzar, sin un demonio alcanzable para el próximo 0-day de OpenSSH. La maniobra técnica es trivial: una regla de firewall y el puerto 22 desaparece.
¿Por qué sigue abierto entonces en casi todas las flotas? No porque cerrarlo sea difícil — sino porque quedarte afuera de tu propio servidor da pánico, y un solo deny tcp/22 es exactamente cómo pasa. Cierra el puerto antes de tener otra vía de entrada y la próxima vez que el panel vaya lento, o un deploy se cuelgue a las 2 a. m., tu único recurso es la consola web del proveedor.
Así que la tarea real no es “cerrar el puerto”. Es “arreglar primero dos vías de entrada confiables y recién entonces cerrar el puerto”. Este post es la segunda mitad — hecha con las propias herramientas de CentralHost, no con reglas de firewall editadas a mano. Dos puertas:
- una puerta diaria para el trabajo del día a día, y
- una puerta de emergencia para cuando todo lo demás está en llamas.
Acceso diario: un terminal que no necesita ningún puerto abierto
La primera puerta es la que ya usas, y es la razón de que el puerto 22 pueda cerrarse siquiera. El agente de CentralHost en cada host mantiene una única conexión saliente hacia el control plane — la misma dirección en la que cualquier cliente HTTPS cruza un firewall. Nada en el host queda a la escucha esperándote.
Cuando abres el Terminal de un servidor, tu sesión viaja por el canal que el agente ya tiene abierto. Obtienes un shell root real en el navegador, atado a tu cuenta con nombre, y — por ser el control plane y no SSH crudo — grabado para auditoría como cualquier otra sesión. No interviene ningún puerto entrante en ningún momento, así que esto sigue funcionando después de cerrar el puerto 22. Para el 99% del trabajo diario, esto es tu SSH.
Pero un canal que depende del agente tiene un modo de fallo honesto: si el agente está caído, o el control plane mismo es inalcanzable, esa puerta no abre. Que es justamente la razón de la segunda.
Acceso de emergencia: el bastión break-glass
La segunda puerta es deliberadamente independiente de la primera. CentralHost opera un bastión — un jump host endurecido, solo-túnel — que te deja llegar a tus servidores con SSH nativo aun cuando el control plane esté teniendo un mal día, o cuando simplemente necesitas herramientas SSH de verdad: rsync, scp, un IDE remoto, Ansible.
Lo importante es lo que el bastión no hace: nunca guarda credenciales de tus hosts. Es un ProxyJump puro — un conmutador TCP autenticado. Tu servidor sigue siendo bring-your-own: entras con tu propia clave, de extremo a extremo, invisible al bastión. Nada en nuestra infraestructura puede obtener root en tu flota.
Para armarla, registras una clave pública en Claves del bastión. Pega una, sube un .pub, o deja que el navegador genere un par Ed25519 en el momento — en cuyo caso la mitad privada se ofrece como descarga única y nunca toca nuestros servidores.
Fíjate en la columna Último uso. Una clave registrada que nunca se ha autenticado por el bastión es solo una teoría — y una teoría no es un plan de break-glass. Así que antes de confiar en ella, haz el simulacro una vez:
ssh -J jump@bastion.centralhost.sh root@tu-host
Si eso te deja en el host, tu puerta de emergencia funciona. Esa única conexión exitosa es lo que pasa la clave de “Nunca” a una vía de entrada real y probada.
Cerrar el puerto — con una guarda contra ti mismo
Ahora, y solo ahora, es seguro cerrar la puerta. Abre la sección Firewall del servidor. Con ambas vías arregladas, el Modo bastión restringe el SSH del puerto 22 al conjunto del bastión y lo cierra para todos los demás.
Es un botón en lugar de sintaxis de firewall escrita a mano — y trae la salvaguarda que la vía manual no puede. CentralHost no te deja cerrar el puerto 22 hasta que esa puerta de emergencia se haya probado al menos una vez. Si pulsas Restringir SSH al bastión antes de que alguna clave muestre una marca de Último uso, se niega y te devuelve a registrar y verificar una clave. El quedarse afuera del que trata todo este post es justamente el fallo que la herramienta está construida para evitar.
También verifica el puerto correcto. Si un host movió sshd fuera del 22, restringir el puerto guardado bloquearía el equivocado y dejaría el SSH real abierto de par en par — por eso el apply reconcilia contra el puerto que el agente realmente detecta antes de tocar nada.
Y cuando vuelvas a necesitar acceso directo, la misma tarjeta tiene un botón Reabrir SSH al mundo — break-glass en la otra dirección, un clic, sin arqueología de reglas.
La forma de todo esto
diario tú ─▶ control plane ◀─ agente ─▶ tu host (sin puerto entrante)
emergencia tú ─▶ bastión (ProxyJump) ──────▶ tu host:22 (clave BYO, solo bastión)
el mundo ✕ ─────────────────────────────── puerto 22 cerrado
- Usa el terminal web para el trabajo diario — ya no necesita ningún puerto abierto.
- Registra una clave del bastión y haz una conexión
ssh -Jreal para probarla. - Activa el Modo bastión en la sección Firewall; el puerto 22 se cierra para todos menos el bastión.
Después de eso, el contador de fuerza bruta marca cero — y la razón de que por fin puedas permitirte eso es que nunca renunciaste a una vía de regreso.