Secure the password encryption of ssh key

[peterwwillis]

I found your guide on generating SSH keys (https://www.fullstackpython.com/blog/ssh-keys-ubuntu-linux.html) after looking at the top 20 Google results for 'how do I generate an ssh key', and it looks like your default suggestions for using ssh-keygen are insecure.

I highly recommend you add this to your guide's ssh-keygen arguments:

ssh-keygen -o

(Note: The -o option was added in 2014; if this command fails for you, simply remove the -o option)

This will ensure the key is password-encrypted properly.

From the ssh-keygen manual:

-o      Causes ssh-keygen to save private keys using the new OpenSSH for‐
        mat rather than the more compatible PEM format.  The new format
        has increased resistance to brute-force password cracking but is
        not supported by versions of OpenSSH prior to 6.5.  Ed25519 keys
        always use the new private key format.

The problem is described in this blog post: https://latacora.singles/2018/08/03/the-default-openssh.html More info can be found on this Hacker News thread: https://news.ycombinator.com/item?id=17682999

By making these changes to your guide, you will be making the internet safer. If the keys used to access servers are secure by default, then both the servers, and all the users who visit websites on those servers, will be more secure.

---

Here is some background on the problem:

• By default, ssh-keygen will try password-protect the ssh key. But the default encoding for the password is actually very easy to crack. By using the -o argument you can change to a newer password encoding which is much more secure.

• Using the default ssh-keygen options are worse than not providing a password at all. The password is so easy to crack that it can then be reused to attack other accounts that use this password. (See the Hacker News thead for more details)

• The only downside to using -o is it may not work for versions of ssh-keygen older than 2014. You can therefore suggest the -o option, and suggest that if it does not work, that the user remove the -o option.

Additional recommendations:

• Your users can upgrade their existing keys with improved password security with this command:

  ssh-keygen -p -o -f (oldfile)

• If you are suggesting the RSA key type, please suggest the -b 4096 options. The reason is that as computers get faster, not only is this not as slow as it used to be, but the default smaller key length of 2048 gets easier to crack.

• If your guide uses the PuTTYgen tool, please suggest 4096 for the number of bits in a generated key. The tool's default of 1024 is far too small to be secure.

Thank you very much for your consideration and help in this matter. Please feel free to contact me if you have any questions.

[mattmakai]

wow, @peterwwillis this is a spectacular pull request. thank you so much. I didn't realize standard Ubuntu was so insecure. I typically use the macOS version of ssh-keygen, which from my initial digging doesn't look like it suffers from the same insecure-by-default issue. Is that your understanding as well?

I'm going to merge this and likely add a bit more of my own context to elaborate on why -o flag is so critical. Thank you again for your work here this is incredibly helpful!

[peterwwillis]

Hi Matt,

Thanks very much for accepting the change!

I'm not aware of the MacOS version used, but this option was introduced in version 6.5 of OpenSSH (https://www.openssh.com/txt/release-6.5). If you're using version 6.5 or later, the option should be available (I use ssh -V to check my OpenSSH version). If you're using a different key-generating tool than OpenSSH's ssh-keygen, you'd have to investigate how it is password-encrypting its keys.