Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

SSH has no Host header

blog.exe.dev

Post reply on HN
Print view View original

61–70 of 181 posts

Re: SSH has no Host header

#61

Post by sirl1on »

charcircuit wrote: post #37

You don't need SSH. Installing an SSH server to such a VM is a hold over from how UNIX servers worked. It puts you in the mindset of treating your server as a pet and doing things for a single vm instead of having proper server management in place. I would reconsider if offering ssh is an actual requirement here or if it could be better served by offering users a proper control panel to manage and monitor the vms.

Treating your server as pet may perfectly fine. Not everything has to be fully automated cloud cluster cattle.

Re: SSH has no Host header

#62

Post by unsnap_biceps »

ulrikrasmussen wrote: post #43
bauruine wrote: post #28

Earlier quoted context omitted.

ssh by default sends all your public keys to a server. Yes you can limit some keys to specific hosts but it's very easy to dox yourself.

I had never thought about that. Seems like an easy problem to fix by sending salted hashes instead.

The server matches your purposed public key with one in the authorized keys file. If you don't want to expose your raw public key to the server, you'll need to generate and send the hashed key format into the authorized keys file, which at that point is the same as just generating a new purpose built key, no? Am I missing something?

Re: SSH has no Host header

#63

Post by geocar »

morpheuskafka wrote: post #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)…

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

That's one implementation. Another implementation is the proxy looks at the SNI information in the ClientHello and can choose the correct backend using that information _without_ decrypting anything.

Encrypted SNI and ECH requires some coordination, but still doesn't require decryption/trust by the proxy/jumpbox which might be really important if you have a large number of otherwise independent services behind the single address.

Re: SSH has no Host header

#64

Post by est »

bauruine wrote: post #28
Charon77 wrote: post #8

Earlier quoted context omitted.

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.

ssh by default sends all your public keys to a server. Yes you can limit some keys to specific hosts but it's very easy to dox yourself.

so it's good practice to store key in non-default location and use ~/.ssh/config to point the path for each host?

Re: SSH has no Host header

#65

Post by geocar »

c45y wrote: post #26

I would love it if more systems just understood SRV records, hostname.xyz = 10.1.1.1:2222 So far it feels like only LDAP really makes use of it, at least with the tech I interact with

This has history: https://egopoly.com/2008/02/ssh-slow-on-leopard.html

I also know of https://github.com/Crosse/sshsrv and other tricks

I agree more SRV records would have helped with a tremendous number of unnecessary proxies and wasted heat energy from unnecessary computing, but in this day and age, I think ECH/ESNI-type functions should be considered for _every_ new protocol.

Re: SSH has no Host header

#68

Post by unsnap_biceps »

krautsauer wrote: post #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?

You are correct, but I expect they instruct their users to run with a host key validation disabled ( StrictHostKeyChecking=no UserKnownHostsFile=/dev/null) , as they expect these are ephemeral instances.

Re: SSH has no Host header

#69

Post by 9dev »

lifthrasiir wrote: post #58
9dev wrote: post #45

Earlier quoted context omitted.

It's a nice solution for sure, but a problem by choice. You could just have an AAAA record for the domain in addition to the A record, and as GP pointed out, resolve SSH sessions via the IPv6. If the user wants SSH to work with IPv4 for whatever reason—I see the point that there may be some web visitors without IPv6 still, but devs?—they could pay a small extra for a dedicated IPv4 address.

They could buy a dedicated IPv4 address, but that address still has to be tunneled through [EDIT:] IPv6 networks if that dev has no access to [EDIT:] IPv4 networks. Thus DX still suffers. [ADDENDUM: I mistakenly swapped "IPv4" and "IPv6" there. See comments.]

I'm not sure I understand your point; if exe.dev operates a dedicated IP solely so a specific mythical IPv6-less developer can connect to a specific server, then there's no tunnelling involved at all.

Re: SSH has no Host header

#70

Post by unsnap_biceps »

binarin wrote: post #35

In kinda the same situation, I was using username for host routing. And real user was determined by the principal in SSH certificate - so the proxy didn't even need to know the concrete certificates for users; it was even easier than keeping track of user SSH keys. 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 ce…

Can you expand on your solution a little bit? AFAIK principals don't impact the user that is logged in at all. A principal in the cert and in the authorized list just allows the user to log in as any user they want, which is why you have to write a script that validates the username before listing principals to accept.

I'd love to learn more about how you solved it and what I may be mistaken about.

Post reply on HN