SSH has no Host header

Eikon

I am not sure to understand what this is this achieving compared to just assigning a ip + port per vm?

dlenski

SSH is an incredibly versatile and useful tool, but many things about the protocol are poorly designed , including its essentially made-up-as-you-go-along wire formats for authentication negotiation, key exchange, etc. 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-... .

3r7j6qzi9jvnve

I wonder if it's something like https://github.com/cea-hpc/sshproxy that sits in the middle (with decryption and everything) or if they could do this without setting up a session directly with the client. 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.

otterley

This is admittedly a clever trick, but I can’t help but wonder where it breaks. There seems to be an invariant that the number of backends a public key is mapped to cannot exceed the number of proxy IPs available. The scheme probably works fine if most people are only using a small number of instances, though.

krautsauer

SSH waits for the server key before it presents the client keys, right? Does this mean that different VMs from different users have the same key? (Or rather, all VMs have the same key? A quick look shows s00{1,2,3}.exe.xyz all having the same key.) So this is full MitM?

morpheuskafka

They are saying they want to directly SSH into a VM/container based on the web hostname it serves. But that's not how the HTTP traffic flows either. With only one routable IP for the host, all traffic on a port shared by VMs has to go to a server on the host first (unless you route based on port or source IP with iptnbles, but that is not hostname based). 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.