Live data from Hacker News

SSH has no Host header

blog.exe.dev

11–20 of 181 posts

Re: SSH has no Host header

#11
post #6
post #4

Earlier quoted context omitted.

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

[deleted]

Re: SSH has no Host header

#12
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?

Re: SSH has no Host header

#13
post #2

I 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.

[deleted]

Re: SSH has no Host header

#14
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.

Re: SSH has no Host header

#15

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/sshp…

Almost certainly it does, as public key auth takes place after setting up the session encryption

Re: SSH has no Host header

#16
post #4
post #2

I 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.

Middleboxes are not relevant in this scenario.

Re: SSH has no Host header

#17
post #16
post #4

Earlier quoted context omitted.

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.

Middleboxes are not relevant in this scenario.

Uh, why not? Unless your SSH client is on the same network as theirs, there are going to be middleboxes somewhere in the path.

Re: SSH has no Host header

#18
post #4
post #2

I 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.

Why would anyone configure it to do that?

Like, I understand the really restrictive ones that only allow web browsing. But why allow outgoing ssh to port 22 but not other ports? Especially when port 22 is arguably the least secure option. At that point let people connect to any port except for a small blacklist.

Re: SSH has no Host header

#19
post #4

Earlier quoted context omitted.

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.

Why would anyone configure it to do that? Like, I understand the really restrictive ones that only allow web browsing. But why allow outgoing ssh to port 22 but not other ports? Especially when port 22 is arguably the least secure option. At that point let people connect to any port except for a small blacklist.

I’m not a network security expert, so I don’t know the threat model. I just know that this is a thing companies do sometimes.

Re: SSH has no Host header

#20

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)…

If jump host shell aliases were a valid option, then setting a port would be a much easier valid option.
Post reply on HN