Give a user a option for use IPv6 only, and if the user need legacy IP add it as a additional cost and move on.

Trying to keep v4 at the same cost level as v6 is not a thing we can solve. If it was we wouldn't need v6.

The HTTP traffic goes to a server (a reverse proxy, say nginx) on the host, which then reads it and proxies it to the correct VM. The client can't ever send TCP packets directly to the VM, HTTP or otherwise. That doesn't just magically happen because HTTP has a Host header, only because nginx is on the host.

What they want is a reverse proxy for SSH, and doesn't SSH already have that via jump/bastion hosts? I feel like this could be implement with a shell alias, so that:

ssh user@vm1.box1.tld becomes: ssh -j jumpusr@box1.tld user@vm1

And just make jumpusr have no host permissions and shell set to only allow ssh.

In 2024-2025, I did a survey of millions of public keys on the Internet, gathered from SSH servers and users in addition to TLS hosts, and discovered—among other problems—that it's incredibly easy to misuse SSH keys in large part because they're stored "bare" rather than encapsulated into a certificate format that can provide some guidance as to how they should be used and for what purposes they should be trusted:

https://cryptographycaffe.sandboxaq.com/posts/survey-public-....

So far it feels like only LDAP really makes use of it, at least with the tech I interact with

I have an architecture with a single IP hosting multiple LXC containers. I wanted users to be able to ssh into their containers as you would for any other environment. There's an option in sshd that allows you to run a script during a connection request so you can almost juggle connections according to the username -- if I remember right, it's been several years since I tried that -- but it's terribly fragile and tends to not pass TTYs properly and basically everything hates it.

But, set up knockd, and then generate a random knock sequence for each individual user and automatically update your knockd config with that, and each knock sequence then (temporarily) adds a nat rule that connects the user to their destination container.

When adding ssh users, I also provide them with a client config file that includes the ProxyCommand incantation that makes it work on their end.

Been using this for a few years and no problems so far.

Setting it up like this where you just assume:

> The public key tells us the user, and the {user, IP} tuple uniquely identifies the VM they are connecting to.

Seems like begging for future architectural problems.

Another thing that just crossed my mind is that the proxy IP cannot be reassigned without the client popping up a warning. That may alarm security-conscious users and impact usability.

1. Client side: ProxyJump, by far the easiest

2. Server side: use ForceCommand, either from within sshd_config or .ssh/authorized_keys, based on username or group, and forward the connection that way. I wrote a blogpost about this back in 2012 and I assume this still mostly works, but it probably has some escaping issues that need to be addressed: https://blog.melnib.one/2012/06/12/ssh-gateway-shenanigans/

Certificate signing was done by a separate SSH service, which you connected too with enabled SSH agent forwarding, pass 2FA challenge, and get a signed cert injected into your agent.

I even do this despite having a small range of routable IPv4s pointing at home, so I don't really need to most of the time. And as an obscurity measure the jump/bastion host can only be contacted by certain external hosts too, though this does still leave my laptop as a potential single point of security failure (and of course adds latency) and one or any bot trying to get in needs to jump through a few hoops to do so.

Not exactly what i built in for, but it'll do the job here too, and able to connect to private addresses on the server side.

Well, we're implicitly trusting the host when running a VM anyway (most of the time), but it's something I'd want to check before buying into the service.

EDIT: Ah, it's probably https://github.com/boldsoftware/sshpiper

will try to remember to look later.

> unexpected-behaviour.exe.dev

That is not a URL, that's a fully qualified domain name (FQDN), often referred to as just 'hostname'.

Good write up of a tricky problem, and glad to real-world validate the solution I was considering.

One similar example of SSH related UX design is Github. We mostly take the git clone git@github.com/author/repo for granted, as if it were a standard git thing that existed before. But if you ever go broke and have to implement GitHub from scratch, you'll notice the beauty in its design.

[0]: https://www.ietf.org/archive/id/draft-michel-ssh3-00.html

You can front a TLS server on port 443 and then redirect without decrypting the connection based on the SNI name to your final destination host.

Take a look at this repo: https://github.com/mrhaoxx/OpenNG

It allows you to connect multiple hosts using the same IP, for example:

ssh alice+hostA@example.com -> hostA

ssh alice+hostB@example.com -> hostB

SSH cannot multiplex to different servers on the same host:port. But you can use multiple ports and forwarding.

You could give each machine a port number instead of a host name:

   ssh-proxy:10001
   ssh-proxy:10002

It would be interesting to know why they rejected the port number solution, but the only hit for "port" in the article is in the middle of the word "important" in the sentence:

But uniform, predictable domain name behavior is important to us, so we took the time to build this for exe.dev.

You can have uniform, predictable domain + port behavior. Then you don't need a smart proxy which routes connections based on identities like public keys. Just manipulation of standard port forwarding (e.g. iptables).