SSH has no Host header
blog.exe.dev
SSH has no Host header
1–10 of 181 posts
Re: SSH has no Host header
#2I am not sure to understand what this is this achieving compared to just assigning a ip + port per vm?
Re: SSH has no Host header
#3SSH 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-....
Re: SSH has no Host header
#4I am not sure to understand what this is this achieving compared to just assigning a ip + port per vm?
Not needing a different port. Middleboxes sometimes block ssh on nonstandard ports. Also, to preserve the alignment between the SSH hostname and the web service hostname, as though the user was accessing a single host at a single public address. Usability is key for them.
Re: SSH has no Host header
#5I am not sure to understand what this is this achieving compared to just assigning a ip + port per vm?
Using nonstandard ports would break the `ssh foo.exe.dev` pattern.
This could also have been solved by requiring users to customize their SSH config (coder does this once per machine, and it applies to all workspaces), but I guess the exe.dev guys are going for a "zero-config, works anywhere" experience.
Re: SSH has no Host header
#6I am not sure to understand what this is this achieving compared to just assigning a ip + port per vm?
Not needing a different port. Middleboxes sometimes block ssh on nonstandard ports. Also, to preserve the alignment between the SSH hostname and the web service hostname, as though the user was accessing a single host at a single public address. Usability is key for them.
They don't want each vm to have different public IP
Re: SSH has no Host header
#7I 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.
Re: SSH has no Host header
#8SSH 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 m…
What good does certificate format do? Certainly won't make people not reuse it the same way.
> where the affected users might be surprised or alarmed to learn that it is possible to link these real-world identities.
I feel like it's obvious that ssh public keys publically identifies me, and if I don't want that, I can make different keys for different sites.
Re: SSH has no Host header
#9I am not sure to understand what this is this achieving compared to just assigning a ip + port per vm?
Using nonstandard ports would break the `ssh foo.exe.dev` pattern. This could also have been solved by requiring users to customize their SSH config (coder does this once per machine, and it applies to all workspaces), but I guess the exe.dev guys are going for a "zero-config, works anywhere" experience.
-p ?
Re: SSH has no Host header
#10This is 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. I assume this is in fact the case.
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.