All new Registrations are manually reviewed and approved, so a short delay after registration may occur before your account becomes active.
Hetzner issued a security notice regarding their own OS images.
Security Notice for Ed25519 SSH host keys
>
An SSH server uses host keys to uniquely identify itself to connecting clients. These keys are normally automatically regenerated each time a new installation is done via the Robot or the installimage.
Due to an error in the installation software introduced on April 10th, 2015, the Ed25519 SSH host keys (/etc/ssh/ssh_host_ed25519_key) on our standard images were no longer automatically regenerated.
This resulted in identical Ed25519 SSH host keys for each affected OS image.
An attacker may use this to compromise or eavesdrop on the communication between the client and the server using a man-in-the-middle attack.
However, due to the security of our network setup, such an attack within our network is highly unlikely as each server can only directly communicate with the corresponding router.
Nevertheless we would like to urge you to replace the Ed25519 SSH host key of your server as soon as possible. The other host keys (RSA, DSA, ECDSA) are not affected and are unique.
Comments
Congratulations on the mess you made of things you new installation system.
Regardless of anything I'd always recommend to generate new SSH keys after the installation.
Just to be clear, I don't work for Hetzner. I am also not affiliated to them.
I'm talking about:
I didn't say you. I said "you new installation system". Not even "your". I just meant their installation system.
Well, I may be old fashion, but an IPMI console it's still my preferred way to do it.
That's why we offer 'em to all our customers.
Nah, that's not old fashion. Just completely uninteresting and a bit of uncalled self-promotion.
Yes, wise practice, always generate your own SSH keys! I'm not sure why you would ever use a key from someone else...?
You didn't get it. Did you even understand what the article is about?
SSH server have key sets for encrypted communication. You can find these keys in /etc/ssh/. They are usually unique. However Hetzner being Hetzner and having a installation system based on something like templates where a already installed OS is extracted onto the disk and then updated and modified through post installation scripts... This OS template has SSH keys that were generated when the template was made. The post script usually generate new ones, however this didn't happen since April because of some software issue.
This has nothing to do with your personal key pair for SSH public key login.
... or just use Windows
Say what? It is not so easy to get in the middle to do a MITM, but the "security of [their] network setup" is not doing much to make it harder to MITM. In fact with SSH you cannot do real MITM just by knowing the host key; you need the user's private key as well. Thus preventing server-to-server connections does not defeat any of the attacks opened up by having a single known host key for all servers.
As bad as the issue is, it would be a lot worse if a user with another server on Hetzner's network could masquerade as a victim's server with ARP spoofing. If the victim is logging in with password, then the attacker could easily obtain the victim's credentials this way. If victim is using SSH key, then MITM is harder, but I'm pretty sure given the host key it's still computationally feasible. Anyway, it sounds like Hetzner's network setup prevents this from happening. So then it's much harder for attacker to "get in the middle".
For the host key both keys are on the server. For example in
/etc/ssh/you would see the private key inssh_host_ed25519_keyand the public key inssh_host_ed25519_key.pub. With a large number of virtual machine images sharing the same keys both keys should be considered known to an attacker and could be used in a MITM attack.Most clients use ecdsa anyway, rigt? Which has a NSA backdoor anyway, at least on my online.net servers: "Server host key: ecdsa-sha2-nistp256"
I am tired of all the accidents and backdoors and just set everything to paranoid mode.
https://tech.tiq.cc/2015/10/ssh-configuration-on-ubuntu-14-04-for-tin-foil-hat-owners/ Like this but a bit more and not only with SSH. Thanks to that my Hetzner server was safe, at least in this case.
Hard to say - the NSA seems to want people to have "good" encryption but not "too good". Look at DES - they made sure it was resistant to differential cryptanalysis so it was not trivially breakable but with a 56 bit key which meant if they really wanted or needed to they could brute force the recovery of a specific key.
The production of secure encryption algorithms and key material including initialization parameters have been a major function of the NSA for decades. Not all of the criteria are made public so it is hard to judge if "good" applies to anything non-NSA sanctioned that might be easily broken but also hard to tell how what is NSA-sanctioned is made to be not "too good" and what that means in a specific case.
Without knowing those criteria there is really no way for the common folk to know if some alternatives to NIST P-256 are "weak" while it is "good" but not "too good".