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?
I mean, anytime you use the cloud for anything, you are giving MITM capabilities to the hosting provider. It is their hardware, their hypervisors... they can access anything inside the VMs
SSH has no Host header
41–50 of 181 posts
Re: SSH has no Host header
#42They 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)…
Re: SSH has no Host header
#43Earlier 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.
Re: SSH has no Host header
#44One 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.
Re: SSH has no Host header
#45> We cannot issue an IPv4 address to each machine without blowing out the cost of the subscription. We cannot use IPv6-only as that means some of the internet cannot reach the VM over the web. That means we have to share IPv4 addresses between VMs. 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 thi…
Op solved a problem and your comment is "I wouldn't have solved the problem". >legacy IP lol
Re: SSH has no Host header
#46This 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 wi…
Re: SSH has no Host header
#47SSH 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?
I mean, anytime you use the cloud for anything, you are giving MITM capabilities to the hosting provider. It is their hardware, their hypervisors... they can access anything inside the VMs
Re: SSH has no Host header
#48Re: SSH has no Host header
#49Earlier 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.
Re: SSH has no Host header
#50The solution to this is TLS SNI redirecting. 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.
But... this doesn't work for SSH, which is the problem here?
Provided your users will configure something a little - or you provide a wrapping command - you can setup the tunneling for them.