hostname routing

[snek]

Thanks for your reply. I'm aware of the workarounds, I guess to be explicit, by asking this mailing list I was hoping more for a discussion about possible changes/extensions/features/etc to the SSH protocol itself that could improve the experience here. If I could just run `git clone snek at git.example.com/repo.git` without having to configure a vpn or jump proxy, and even better if I could give that clone url to other people without them having to know about the details of my server setup, that would be ideal.

I think this also opens up other interesting use cases as well, for example there are a lot of microvm hosting services popping up, and they all have very weird ways of accessing the microvms via ssh, because they can't use hostnames.

-snek

On Tue, Jun 16, 2026, at 11:23, Brian Candler wrote:
> On 16/06/2026 09:50, snek wrote:
> > I'm trying to figure out if there's a good way to expose my git server's ssh to the world without having to give it a dedicated IP (I do like the idea of using dedicated IPv6 addresses for different services, but I do still need to access my stuff on legacy IPv4 networks...)
> >
> > In the HTTP world we use features like the Host header and TLS SNI/ECH to figure out how to route a request instead of relying on dedicated IPs. I searched through RFCs, docs, and mailing list archives a bit for similar topics and didn't really find anything about such functionality in the SSH protocol.
> 
> You're right: an "SNI" type feature doesn't exist in ssh.
> 
> I looked into this a while ago. The main options that I'm aware of are:
> 
> --------
> 
> 1. Expose a bastion host SSH server, and connect through it using 
> ProxyJump (-J).
> 
> Users need to be able to authenticate to both the bastion host and the 
> target host, but they do not need any shell access to the bastion host.  
> There is the slight extra overhead of double-encryption of the SSH 
> traffic to the target host.
> 
> 2. Expose a SOCKS5 server.  The first bytes of the TCP session let the 
> client select the destination, which functions like the SNI header; the 
> remainder of the session is just proxied through.
> 
> The traffic is single-encrypted end-to-end, but the server sees the 
> source IP address of the proxy. You need a SOCKS5 server instead of 
> bastion host, and the client needs to add the SOCKS5 preamble, which can 
> be done using ProxyCommand and an external helper.
> 
> 3. Port-forward a different port number to each internal SSH server of 
> interest
> 
> 4. Use a VPN like Wireguard
> 
> --------
> 
> Options 1-3 require client configuration, but any client which shells 
> out to `scp`, `sftp` or `scp` can apply options from ~/.ssh/config. This 
> can be made smarter using "Match localnetwork".
> 
> For SOCKS5 you can do automatic fallback. For example, suppose your host 
> lists both A and AAAA records, and you want the connection to be 
> end-to-end over IPv6, but fall back to using SOCKS5 over IPv4 when 
> that's not possible. You can do:
> 
> Host *.mydomain.com
> ProxyCommand sh -c 'ncat -w 5 "%h" "%p" || ncat --proxy-type socks5 
> --proxy 192.0.2.1:11080 "%h" "%p"'
> 
> That example assumes the socks5 server is not performing authentication, 
> which makes sense if you're leaving connectivity open to the world over 
> IPv6 anyway; you can add restrictions in your SOCKS5 server to allow 
> connections only to specific destination IPs and ports. If you want you 
> could turn on authentication on your SOCKS5 server and provide some 
> extra creds as part of the connection setup, but they'll be unencrypted.
> 
> FWIW, I used option (2) for a while, but have gone to (3) and (4), with 
> an aim to deploy (1) at some point in the future.
> 
> Regards,
> 
> Brian.
> 
>