HTTP tiene una solución elegante para alojar mil sitios en una sola IP: el encabezado Host. Tu navegador lo envía automáticamente, el servidor lee el dominio, y cada sitio recibe su tráfico. Simple. SSH, en cambio, no tiene nada de eso, y si alguna vez construiste una plataforma SaaS con múltiples VMs por usuario, ya lo aprendiste de la peor manera.
Esto no es un bug ni un descuido. Es una decisión de diseño de un protocolo que lleva décadas resolviendo un problema diferente. Pero cuando mezclas SSH con infraestructura cloud moderna, ese diseño choca de frente con la realidad económica de los IPv4.
¿Por qué HTTP puede hacer virtual hosting y SSH no?
Cuando escribes https://mitiopedia.com, tu navegador abre una conexión TCP a una IP y, dentro del protocolo HTTP, envía un encabezado que dice literalmente: Host: mitiopedia.com. El servidor puede estar alojando cien dominios distintos en esa IP, y el encabezado le dice cuál necesitas.
Claude Desbloqueado
Mi curso avanzado para aprender a sacarle mucho más provecho a Claude en el trabajo y en el día a día, con funciones y usos más potentes. Comienza el 23 de marzo.
→ Inscríbete hoy 🚀SSH opera diferente desde el primer handshake. El protocolo está diseñado para establecer una sesión segura basándose en claves criptográficas, no en dominios. No existe campo de hostname en el flujo inicial del protocolo. El cliente se conecta a una IP (o resuelve un DNS a IP), negocia cifrado, y presenta su clave pública. El servidor valida esa clave y listo: sesión autenticada. Ningún momento en ese flujo existe un “¿a qué host quieres ir?”.
Para la mayoría de los casos de uso clásicos de SSH — conectarte a tu servidor, a tu VPS — esto no es problema. Hay una IP, hay un servidor, hay una sesión.
El problema se vuelve caro cuando construyes SaaS
exe.dev es una plataforma que ofrece VMs en suscripción flat rate. Cada VM tiene una URL única (nombre-vm.exe.xyz) que funciona tanto para HTTPS como para SSH. Perfecto en teoría — pero en la práctica, si tienes cientos o miles de VMs activas, asignar una IPv4 pública a cada una destruye el modelo de negocio.
Las IPv4 públicas escasean. Desde que la demanda de infraestructura digital se disparó, el costo de cada dirección solo sube. IPv6 resuelve el problema de escasez en papel, pero si usas IPv6-only, parte de internet (todavía en IPv4) no puede alcanzar tus VMs. El resultado: compartir IPs entre múltiples VMs es la única opción económicamente viable.
Para HTTPS, compartir IPs es trivial. Para SSH, es un rompecabezas de protocolo.
La solución: cuando no hay Host header, construyes uno implícito
El equipo de exe.dev encontró una salida elegante. En lugar de una IP por VM, mantienen un pool de IPs públicas. La clave del truco: cada IP del pool se asigna a exactamente una VM por usuario.
En DNS esto se ve así:
$ dig undefined-behavior.exe.xyz
undefined-behavior.exe.xyz. → CNAME s003.exe.xyz.
s003.exe.xyz. → A 16.145.102.7La IP 16.145.102.7 puede ser compartida por VMs de muchos usuarios distintos. Pero nunca será compartida por dos VMs del mismo usuario. Esto da al proxy SSH toda la información que necesita: cuando llega una conexión a esa IP, el proxy combina {clave pública del cliente, IP destino} para identificar unívocamente la VM correcta.
La clave pública identifica al usuario. La IP identifica la VM dentro de ese usuario. Tupla única. Routing resuelto.
Por qué importa más allá de exe.dev
Este problema es un caso de estudio en algo que los cursos de cloud no enseñan: la fricción entre los protocolos de red y los modelos de negocio de infraestructura.
Si construyes una plataforma que ofrece acceso SSH a recursos compartidos — ambientes de desarrollo, sandboxes, instancias de prueba, sistemas de monitoreo como Kula — antes o después te topas con esta pared. Las alternativas más simples tienen sus propios costos:
- Puerto diferente por VM: gestión compleja, firewalls corporativos bloquean puertos no estándar, experiencia de usuario degradada.
- Jump host con IPs internas: agrega un salto extra, complica los workflows de herramientas como
rsyncoscp. - SNI-based routing (SSH sobre TLS): existe como técnica, pero rompe el comportamiento esperado de clients SSH estándar.
La solución de pool de IPs asignadas por usuario es elegante porque es transparente: el cliente SSH estándar no necesita saber nada raro. Resuelve el DNS, conecta a la IP, presenta su clave. El proxy hace el trabajo invisible.
La otra lección: soluciones como esta requieren software de gestión propio. Hay que coordinar la asignación de IPs al crear VMs, que el proxy SSH detecte la IP local de destino (más fácil en bare metal que en entornos cloud donde los IPs públicos son NATteados a direcciones privadas de VPC), y mantener la coherencia cuando los usuarios crean o destruyen VMs. No es algo que improvises un viernes.
Para quienes construyen infraestructura escalable: la próxima vez que diseñes la arquitectura de acceso remoto de tu plataforma, este problema aparece antes de lo que esperas. Conocerlo de antemano puede ahorrarte semanas de rediseño.
