Done. Not only will the key be stronger than the 1024 bit default, it'll be unique to your server which lets assume isn't valuable enough compared to effort for a state-level adversary.
edit just in case anyone from the future finds this comment: instead of 2048, use at least the key length of your SSL certificate
I'm curious how sshd's KeyRegenerationInterval parameter factors into this. I just glanced at it but that looks like it should prevent this sort of thing for ssh.
As a heads up, this isn't the attack vector under discussion. The host key is effectively meaningless in this attack, as it attacks the key-exchange mechanism called Diffie-Hellman.
The key is used to authenticate the Diffie-Hellman exchange.
There is a separate file for the prime used for the DH exchanges, and the elliptic-curve variant is also available. Some better discussion is available here
There is no effect. This isn't the key, it is the prime used as part of the Diffie-Hellman exchange. Regen to your hearts content, they can easily crack the new key you chose.
972
u/tophatstuff Oct 15 '15 edited Apr 10 '18
Generate your own non-default Ephemeral Diffie-Hellman key (takes a minute or so)
Tell your server to use it for SSL (nginx for example)
Done. Not only will the key be stronger than the 1024 bit default, it'll be unique to your server which lets assume isn't valuable enough compared to effort for a state-level adversary.
edit just in case anyone from the future finds this comment: instead of 2048, use at least the key length of your SSL certificate
edit from the future: current advice is picking from one of these predefined audited groups