SSH has no Host header

Original Article ↗ Hacker News Discussion ↗

Running many SSH-accessible VMs behind a single IPv4 address is hard because SSH lacks an HTTP-style Host header, forcing providers to choose between awkward port schemes, client-side config, or custom proxies. Commenters explore a service that routes SSH connections by public key as a UX-friendly workaround and compare it with alternatives like jump hosts, SRV records, username-based routing, and per-port mapping. The exchange surfaces broader tensions between usability, security (key exposure, MITM risks), and infrastructure choices such as continued reliance on IPv4 versus pushing harder toward IPv6.

Motivation vs. Simpler Alternatives

  • Many ask why not just give each VM a distinct IP and/or port.
  • Proponents of the described design emphasize:
    • IPv4 scarcity and cost; IP-per-VM is too expensive.
    • Desire for “ssh hostname” to match the web hostname with no extra flags.
    • “Zero-config” UX for developers, especially in corporate environments where only port 22 is reliably allowed.
  • Critics argue port-based routing or a simple jump host/ProxyJump would be easier, more standard, and avoid complex key-based routing logic.

SSH Protocol Limitations & Workarounds

  • Core issue: SSH lacks a Host/SNI-like field to multiplex multiple backends on one IP:port.
  • Suggested workarounds:
    • Nonstandard ports combined with SRV records (not widely supported by SSH clients).
    • ProxyCommand/ProxyJump plus wildcards in ssh config.
    • Username-encoded routing (e.g., user+host@domain).
    • Port knocking and NAT rules per user.
  • Several note that “zero config” just pushes complexity onto the service operator.

Security, Host Keys, and Identity Leakage

  • Concern: all VMs behind the proxy appear to share the same host key, effectively enabling full MITM by the provider and possibly weakening host key pinning.
  • Some expect users will be told to disable host key checking for ephemeral instances, further weakening security.
  • Separate thread: SSH clients may present multiple public keys to a server, allowing correlation of identities across services; advice includes using different keys per host and restrictive ssh configs.
  • SSH certificates and CAs are mentioned as an underused but powerful mechanism for scoping and managing access.

IPv4 vs IPv6 and Network Reality

  • Some argue the “real” solution is IPv6 and/or charging extra for dedicated IPv4.
  • Others counter that many ISPs and corporate networks still lack reliable IPv6, so IPv4-only compatibility remains essential.
  • NAT, CGNAT, and lack of IPv6 are seen as practical blockers to “v6-only” deployments despite ideological support for IPv6.

Broader Reflections

  • Several see this as a pure Developer Experience optimization, similar in spirit to GitHub’s SSH UX.
  • Others question whether SSH itself is even necessary for such services, suggesting richer control panels instead, though this is contested.