This gist will track the websites that suggest unnecessarily-insecure default ssh-keygen arguments, in an attempt to have their authors update their arguments to safer defaults.

default-ssh-keygen-check.sh

#!/usr/bin/env bash

declare -A LIST_OF_GUIDES
LIST_OF_GUIDES=(
  ["https://confluence.atlassian.com/bitbucketserver/creating-ssh-keys-776639788.html"]="Atlassian"
  ["https://help.github.com/articles/generating-a-new-ssh-key-and-adding-it-to-the-ssh-agent/"]="GitHub"
  ["https://www.digitalocean.com/community/tutorials/how-to-set-up-ssh-keys--2"]="DigitalOcean"
  ["https://www.ssh.com/ssh/keygen/"]="info.us@ssh.com"
  ["https://git-scm.com/book/en/v2/Git-on-the-Server-Generating-Your-SSH-Public-Key"]="Git SCM"
  ["https://www.vultr.com/docs/how-do-i-generate-ssh-keys"]="Vultr"
  ["https://docs.joyent.com/public-cloud/getting-started/ssh-keys/generating-an-ssh-key-manually/manually-generating-your-ssh-key-in-mac-os-x"]="support@joyent.com"
  ["https://help.ubuntu.com/community/SSH/OpenSSH/Keys"]="Ubuntu"
  ["https://docs.gitlab.com/ee/ssh/README.html"]="GitLab"
  ["https://jdblischak.github.io/2014-09-18-chicago/novice/git/05-sshkeys.html"]="admin@software-carpentry.org"
  ["https://www.scaleway.com/docs/configure-new-ssh-key/"]="Scaleway"
  ["https://help.packet.net/quick-start/generate-ssh-keys"]="help@packet.net"
  ["https://inchoo.net/dev-talk/how-to-generate-ssh-keys-for-git-authorization/"]="web@inchoo.net"
  ["https://www.siteground.com/kb/generate_ssh_key_in_linux/"]="sales@siteground.com"
  ["https://www.howtoforge.com/linux-basics-how-to-install-ssh-keys-on-the-shell"]="HowtoForge"
  ["https://kb.iu.edu/d/aews"]="UITS"
  ["http://www.oracle.com/webfolder/technetwork/tutorials/obe/cloud/javaservice/JCS/JCS_SSH/create_sshkey.html"]="Oracle"
  ["https://mediatemple.net/community/products/dv/204644740/using-ssh-keys-on-your-server"]="MediaTemple"
  ["https://www.debian.org/devel/passwordlessssh"]="Debian"
  ["https://wiki.archlinux.org/index.php/SSH_keys"]="Arch Linux"
  ["https://docs.rightscale.com/faq/How_Do_I_Generate_My_Own_SSH_Key_Pair.html"]="RightScale"
  ["https://www.w3docs.com/snippets/git/how-to-generate-ssh-key-for-git.html"]="W3Docs"
  ["https://www.linode.com/docs/security/authentication/use-public-key-authentication-with-ssh/"]="support@linode.com"
  ["https://www.fullstackpython.com/blog/ssh-keys-ubuntu-linux.html"]="mattmakai"
  ["https://support.rackspace.com/how-to/generating-rsa-keys-with-ssh-puttygen/"]="RackSpace"
  ["https://docs.microsoft.com/en-us/azure/virtual-machines/linux/mac-create-ssh-keys"]="Microsoft Azure"
  ["https://www.keycdn.com/support/create-ssh-key/"]="KeyCDN"
  ["https://devcenter.heroku.com/articles/keys"]="Heroku"
)

declare -A SENT_TO
SENT_TO=(
    ["Heroku"]="article feedback"
    ["KeyCDN"]="feature request"
    ["mattmakai"]="https://github.com/mattmakai/fullstackpython.com/pull/182"
    ["support@linode.com"]="docs contributing submission"
    ["RightScale"]="feedback form"
    ["Arch Linux"]="https://bugs.archlinux.org/task/59522"
    ["Debian"]="https://salsa.debian.org/webmaster-team/webwml/merge_requests/15"
    ["MediaTemple"]="feedback form"
    ["UITS"]="feedback form"
    ["HowtoForge"]="feedback form"
    ["sales@siteground.com"]="e-mail"
    ["web@inchoo.net"]="feedback form"
    ["help@packet.net"]="e-mail"
    ["Scaleway"]="https://cloud.scaleway.com/#/tickets/EXOY-8867-NOCP"
    ["admin@software-carpentry.org"]="https://github.com/jdblischak/2014-09-18-chicago/pull/3"
    ["GitLab"]="https://gitlab.com/gitlab-org/gitlab-ee/merge_requests/6796"
    ["Vultr"]="docs contributing submission"
    ["Git SCM"]="https://github.com/progit/progit2/pull/1099"
    ["info.us@ssh.com"]="e-mail"
    ["RackSpace"]="https://community.rackspace.com/feedback/f/how-to-api-documentation/8816/insecure-use-of-ssh-keygen"
    ["DigitalOcean"]="https://cloudsupport.digitalocean.com/s/case/5001N00000dihowQAA"
    ["GitHub"]="feedback form"
    ["Atlassian"]="feedback form"
    ["W3Docs"]="facebook,e-mail"
)


LETTER_TO_THE_EDITOR=" echo \"
To: \$TO_EMAIL
From: \$FROM_EMAIL
Subject: Insecure use of ssh-keygen

Hello, this is \$MY_NAME. I found your guide on generating SSH keys (\$URL) 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 default may introduce compatibility issues for users of older computers.
In that case, please simply provide the following paragraphs in your SSH guide:

  > The default password encryption used for ssh keys is MD5(plaintext | IV). 
  > The security of the MD5 hash has been severely compromised, and such passwords
  > are easily cracked using modern computers and techniques.

  > Since 2014, ssh-keygen has provided a new key format with greatly improved 
  > password encryption. To use this new format, simply add the '-o' option to 
  > ssh-keygen. No further steps are required. Keys using this format will be 
  > incompatible with versions of OpenSSH older than 6.5 (released in 2014).

  > If you will be using your key with versions of SSH older than this, it is
  > suggested NOT to set a password on your key. The password will be easily 
  > decrypted by any modern attacker and then used to attack other accounts.


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 more background on the problem.

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.

By default, ssh-keygen will try to 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 key encryption is actually 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 above articles 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 your guide uses the PuTTYgen tool, please suggest AT LEAST 2048 for the number of bits in a generated key. PuTTYgen'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.
\"
"

#[ -n "$TO_EMAIL" ] || read -p "Enter the recipient e-mail address: " TO_EMAIL
[ -n "$FROM_EMAIL" ] || read -p "Enter your e-mail address: " FROM_EMAIL
[ -n "$MY_NAME" ] || read -p "Enter your name: " MY_NAME

[ -d "letters" ] || mkdir letters

for URL in "${!LIST_OF_GUIDES[@]}" ; do

    #echo ""
    #read -p "Press Enter to generate the next letter..."

    TO_EMAIL="${LIST_OF_GUIDES[$URL]}"
    LETTER=`eval "$LETTER_TO_THE_EDITOR"`
    echo "$LETTER" > letters/"$TO_EMAIL".txt

done

It's been a while since I originally reached out to these sites to see if they would update their documentation.

Some organizations and individuals have been really supportive of the added documentation, and worked quickly to update their docs. These were mostly sites where I could e-mail the product owner directly, or if it was a very small company or project, or where I could submit a pull-request directly against the documentation.

Some (mostly corporations) were hesitant to include the new documentation, and replied that they'd discuss it internally. These sites do not appear to have updated their documentation. This includes GitHub, one of the first search results for ssh key generation.

One just refused outright. I'll name them below because I think their users are at risk, and the reasons for their refusal are dumbfounding.

Indiana University's University Information Technology Services refused to modify their documentation. The reasoning I was given were:

1. "Because our systems are using an older version of SSH that doesn't support the -o option"
2. "because the content is primarily meant for students and beginner-level Linux users" and "To avoid confusing students"

The first may be confusion on their part, because the server shouldn't need to support the new private key format. Only the client needs to. If you use RSA keys with the -o option, even old servers should support it.

The second is just silly. This is an educational institution, saying they will not educate their students, because to do so might confuse them.

If you go to the UITS ssh key page, it states now that beginning in October 2018, their services will require two-factor auth - unless an individual signs a pledge and agrees to password protect their SSH key. But they still don't tell those users that the default password protection method is bunk. They explicitly mention multiple times that all users should password protect their key, but refuse to tell their users how to do this safely.

What I take from these examples is that organizations prefer the perception of security to the reality. I think this is a good lesson in security design. If you design a security feature in a way that it can be implemented poorly without raising suspicion, people will continue to implement it poorly. So the ability to flag bad security practices may be even more important than having security features at all.