Re: hostname routing

SRV could work. Would it wait until the default port failed before trying DNS? I imagine some people would complain very loudly if they had to wait for a NXDOMAIN /before/ it tried the default port, though I think it's a very worthwhile tradeoff. If I had some indication of what the openssh maintainers were willing to accept I would definitely be up to try writing a patch for this.

> Whichever way it's done, until versions of ssh with support for that
> method are common in the wild, you'll be needing to explain it to
> people.

That I don't mind so much, I'd rather apply a good solution that takes time rather than a quick band-aid, especially if it can improve things for other people as well.

On Tue, Jun 16, 2026, at 12:11, Stuart Henderson wrote:
> On 2026/06/16 11:34, snek wrote:
> > 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.
> 
> The simplest way to handle this would be to add support for SRV records
> to ssh. Then you would add port-forwardings using different ports.
> This avoids the need for changing the SSH protocol, and could be
> retrofitted into old installed ssh binaries if needed via ProxyCommand
> (and I think would be a much simpler thing for distros to backport than
> a protocol extension if they wanted to do that).
> 
> > If I could just run `git clone [email protected]/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.
> 
> Whichever way it's done, until versions of ssh with support for that
> method are common in the wild, you'll be needing to explain it to
> people.
> 
> > > 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.  
> 
> This could be done without requiring authentication on the 'jump' host.
> 
> > > There is the slight extra overhead of double-encryption of the SSH 
> > > traffic to the target host.
> 
> Also a big downside in that the ssh endpoint doesn't see the client's IP,
> so can't make auth / blocklist decisions based on that.
> 
> > > 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.
> 
> Same issue here.
> 
> Possible workaround for those would be to add support for PROXYv2 or
> similar protocol on the onward connection from the proxy or jump host,
> and to sshd on the target endpoint.
> 
>