Non-Unique SSH Host Keys Ed25519 on Hetzner
wiki.hetzner.de
wiki.hetzner.de
Can someone versed in cryptography comment on whether this allows passive eavesdropping? Active MITM sure, but I thought session keys would be unique.
"Impersonification" of the server, you mean (inservication if that's a word). It would allow an attacker to operate a machine under their control that poses as mine.
But then, for password based logins, that will actually be enough to impersonify the user as well (the attacker will create an ssh connection to the real server with the given password). But I wonder how things work with key based logins.
I've ordered a server from Hetzner recently, I guess I'll just ditch it (and perhaps order a new one). BTW I haven't gotten any email notification from Hetzner about this yet.
If the symmetric session key is chosen by the server and encrypted with the client's public key, the attacker won't know it and cannot mess with the session.
The only thing the attacker can do is completely impersonate the server. But the attacker cannot communicate with the actual server at all.
Re: mail issues. We had the same problem (our IP was green but the block it was in was tainted). We solved the delivery issues by going through the various processes on: https://mail.live.com/mail/postmaster.aspx http://postmaster.google.com and https://postmaster.aol.com/ [ in addition to following all the usual best practices - SPF, DMARC etc. ]
A lot of companies would just fix the issue (or not even that) and try to silently sweep it under the rug.
Sweeping it under the rug would destroy their business. (Not that competitors wouldn’t have done it anyway)
Really. Here I thought their business is renting out servers made from desktop parts for insanely low amounts of money. I have no problems with this strategy, I enjoy my 42EUR a month 2x3TB HDD + 2x120GB SSD, 16GB i7 2600 server, thanks much. It runs hobby sites and such. I know what I bought and what I can expect.
I mean most people's need definitely suites inside the cloud since they don't need to have the full capacity 24 hours. There are some other people who need the full capacity every time, but if you run a globally distributed services you mostly run into other problems than datacenter costs.
The total monthly cost for this (exc. VAT) is €180. I haven't been able to find any co-location or cloud providers that can come anywhere close to that price for a similar resource setup.
I've been a customer for a while but needed some spare, cheap server grade boxes this month. Decided to give their server bidding system a try and picked up two 32GB quad-core Xeon boxes (with 2x3TB SATA disks, Intel NICs and unlimited bandwidth) for €39/month each. So far, no complaints.
It's a pretty noisy flaw and one that's common on virtualized platforms deployed from an image.
1) just don't say anything and hope nobody notices.
2) fix the underlying problem and then regenerate all keys and post some nonsense saying they had to do so for some "not their fault bullshit reason".
3) remove support for the key/cipher type affected with some bs reason and force all customers to use something else.
And some creative persons can probably come up with more...
Good on them that they acknowledged the problem. Warned customers and provide instructions on how to fix things. Makes me want to consider them if I ever need a service like theirs in the future.
Even in countries where this is legal, providers cannot take the risk of running a scan that could possibly crash a customer application, or they could be sued for that.
Which T&Cs do not have a blanket clause to indemnify the hosting company in such situations? If I accidentally reboot the virtualisation host, can my company be sued for making the application "crash"?
If connecting to port 22 and slurping the host fingerprint crashes a customer application... I don't even know.
Like, how is their app even running?
That's several steps beyond connecting to port 22 and slurping up the host fingerprint. At that point, SSH has prompted for credentials, accepted them, and set up a shell or SFTP session for you.
Hell, if the system lets you log in using SSH and read files, that really sounds like the system has granted you permission to access those files. (I'm sure a lawyer could argue with me, but I think we're all aware of how (willfully?) ignorant members of the Judicial branch can be of the nuances of computer things.)
Yeah. It's certainly not the default config. From what I can tell, you can either
* Activate PAM support and have a PAM module that just authorizes users, regardless of credentials.
* Enable PermitEmptyPasswords and have an account on the system that has no password.
So, I guess if you SSH to a machine that lets you log in with no password, or any username/password combo, you might want to consider that maybe your use of the machine is not necessarily authorized. :p
My hypothetical in the previous comment presumed that you presented a username/key or a username/password combo that you knew to the system and it granted you access... but I guess the situation can get a little more murky, if you're accessing a system managed by a pathologically lazy sysadmin. ;)
If all you do is grab a fingerprint, you will interact with the system less than the script kiddies.
So, if it was going to fall over, it would without you grabbing the fingerprint.
It would be great not to publish an article like that until some time later, so that everyone gets a chance to fix the problem on their machines before it goes fully public - especially since it's the holiday season and some people don't check email or news that often.
In anycase, if you are relying on hosting company images (complete with their root backdoor for "performance monitoring control panel!"), it's not like you care very much about your servers' security in the first place...
> In order to be able to intervene on your dedicated server without your root password, the automatic installation of ssh key is done. Only authorized employees of OVH will use it. It is not a gap in security, contrary, thanks to this OVH has root rights to your server and may identify the problems with your server. When you request an intervention, we need to have access to ssh.
A static SSH key for a single human is already risky over a long time period, but for a key that is shared between multiple humans... wow.
Wait, you mean you clone your images instead of installing them from scratch with some automated system? How barbarous!
https://github.com/hannob/ed25519hetzner
(script to check host key and known_hosts file for vulnerable hetzner keys)
I reported a similar issue on Chunkhost (https://chunkhost.com/) back in 2011... They never responded to my email about remediation, but hopefully the issue was fixed.