hostname routing

[Brian Candler]

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.