exe.dev engineers confront SSH's inherent limitation—the absence of a host header—by developing a novel IP sharing system that routes connections using cryptographic identity and IP tuple mapping.
Modern infrastructure often relies on shared resources to maintain economic viability, yet foundational protocols occasionally resist such optimization. This tension becomes particularly acute when considering SSH access in multi-tenant environments. Unlike HTTP, which effortlessly routes requests using the Host header to direct traffic for multiple domains sharing a single IP, SSH provides no equivalent mechanism. This architectural gap creates significant challenges for platforms like exe.dev that offer numerous virtual machines under a flat-rate subscription model—where dedicating individual IPv4 addresses per VM would render the service financially unsustainable.
IPv6-only solutions prove insufficient due to lingering global connectivity limitations, leaving shared IPv4 addressing as the sole practical approach. The core problem manifests clearly: when multiple VMs share an IPv4 address, incoming SSH connections lack any inherent identifier specifying which VM the user intends to access. Traditional reverse proxies cannot function without this routing signal, creating an infrastructure deadlock.
exe.dev's engineers addressed this through a layered solution centered on cryptographic identity. Rather than assigning IPs randomly from a shared pool, they implemented deterministic IP allocation relative to user ownership. Each VM receives a CNAME record resolving to a subdomain like s003.exe.xyz, which points to a shared IPv4 address (e.g., 16.145.102.7). Crucially, this IP is reused only across VMs owned by different users—never within the same user's resources.
When a user initiates an SSH connection, two critical data points converge: the public SSH key presented during authentication (identifying the user) and the destination IP address. The combination forms a unique tuple: {user, IP}. This tuple serves as a routing coordinate, allowing exe.dev's proxy infrastructure to pinpoint the exact target VM among thousands.
Implementing this requires sophisticated orchestration. Allocation systems must track IP assignments per user to prevent collisions, while the SSH proxy must decode the tuple in real-time. Cloud environments add complexity, as public IPs often undergo NAT translation before reaching internal VPCs—demanding careful mapping between external and internal addressing. This entire architecture operates through custom-built management software, highlighting why such solutions remain impractical for generalized adoption despite their elegance.
The engineering investment underscores a broader principle: uniform access patterns matter. By ensuring ssh your-vm.exe.xyz works identically across HTTP and SSH realms—without port suffixes or secondary domains—exe.dev preserves developer ergonomics. This commitment to seamless abstraction reflects infrastructure design at its most user-centric, transforming protocol limitations into opportunities for innovation. While not universally applicable, their approach demonstrates how cryptographic identity can effectively substitute for missing protocol features when layered atop thoughtful network design.
For technical implementation details, refer to exe.dev's infrastructure documentation.
Comments
Please log in or register to join the discussion