The MacOS Sierra upgrade breaking SSH keys

After I upgraded MacOS Sierra, my SSH key access to Ubuntu servers broke. I learned that my older ssh-dss (DSA) keys were no longer secure and that I needed to replace them with RSA keys.

Updating server keys is always a bit time consuming. If you want more background on this, check out: Secure Your Instance

Here’s what worked well for me:

Reactivate Password Authentication

Firstly, I logged into my Digital Ocean droplets via the virtual host console they offer. With this, I turned back on PasswordAuthentication temporarily on my servers:

$ sudo nano /etc/ssh/sshd_config

# Change this back temporarily to yes
# Change to no to disable tunnelled clear text passwords
PasswordAuthentication yes

Then, I reset the SSH service:
$ sudo service ssh restart

If you can’t access your server in any way, there may be no easy way to regain access without using another device. For example, I use Panic’s Prompt 2 SSH App on my iPad.

Create a New RSA Key

Next, we’ll create the new RSA key on my Mac.
$ ssh-keygen -t rsa

You’ll see something like this:
$ ssh-keygen -t rsa
Generating public/private rsa key pair.
Enter file in which to save the key (/Users/Jeff/.ssh/id_rsa): id_newkey
Enter passphrase (empty for no passphrase):
Enter same passphrase again:
Your identification has been saved in id_newkey.
Your public key has been saved in
The key fingerprint is:
The key's randomart image is:
+---[RSA 2048]----+
|*B%a .. |
| Fo.+.oo |
|. o C. o |
| ..=..+o.. |
| o 7 +o o |
|.==o.... . |
| o . o.. |
| . o= oS o. |
| . ... |

Then, I copied out the public key so I could upload to a sharing service:
$ cat ~/.ssh/
ssh-rsa AAAAB3NzaC1yxxxxyyyyzzzz123121231jakdljasdasdasdklasjdlakszaC1yxxxxyyyyzzzz123121231jakdljasdasdasdklasjdlakszaC1yxxxxyyyyzzzz123121231jakdljasdasdasdklasjdlakszaC1yxxxxyyyyzzzz123121231jakdljasdasdasdklasjdlakszaC1yxxxxyyyyzzzz123121231jakdljasdasdasdklasjdlaksfTt12MRn Jeff@Skybook-Pro.local

Upload the New Key to Github Gist

Next, I created a new private Gist and pasted the public key into it and saved it.

Visiting the raw page for that gist, I copied the URL for the raw content of the Gist. There may be a more obvious way in the UX but I couldn’t find it.

Sign in to Your Server

Next, I used password authentication to sign in to my server:
$ ssh -p 22

And, I performed the following steps to retrieve the public key from Gist and store it on the server. Then, add it to the authorized_keys file:

$ cd ~
$ wget
$ cd .ssh
$ cat ../id_newkey >> authorized_keys

Verify New Key Authentication to to Your Server

Then, I tested it in another terminal window from my Mac:
$ ssh -p 22 -i ~/.ssh/id_newkey
Everything worked fine!

Turn Off Password Access to Your Server

Then, I returned to the server and turned off PasswordAuthentication:
$ sudo nano /etc/ssh/sshd_config

# Change to no to disable tunnelled clear text passwords
PasswordAuthentication no

Then, I reset the SSH service:
$ sudo service ssh restart

And that was it, just a few hours lost hunting down and duplicating the proper steps.

It’s odd I didn’t know about this and odd that the Sierra upgrade doesn’t warn you about it as it upgrades OpenSSH behind the scenes.

Posted by Jeff Reifman

Jeff is a technology consultant based in the Pacific Northwest.


  1. If you have dsa keys, you may save yourself some time by echoing PubkeyAcceptedKeyTypes=+ssh-dss >> ~/.ssh/config while you update your keys #ssh #macOSSierra


    1. Thanks. I had tried this and didn’t have any success. I tried a few different configurations of the command that I saw online too … just didn’t work for me. Others may have more success. And, I was teased for even considering sticking with dss.


      1. Hi Jeff, thanks for replying and my apologizes for my rushed/peremptory post. The additional PubkeyAcceptedKeyTypes property should be added at the top of the ssh config file and not at the end. It won’t be taken into account, otherwise. My mistake. Using the OSX sed version:

        sed -i -e ‘1i
        ‘ ~/.ssh/config

        I also erased my known_hosts file and did a ssh-add -A

        I know that it didn’t work for you, but for the sake of the thread and avoid confusion to some futur readers, i thought i should fix my mistake. Maybe it can help someone, somewhere, someday.



      2. I use Akamai NetStorage areas that currently only support dss keys (they’re aware of the issue and are working to address it). I was able to restore the dss keys to working by adding this to my ~/.ssh/config file…
        Host *
        HostKeyAlgorithms +ssh-dss


    2. Yes r1k0! This was exactly what I needed (so I could actually ssh into the machines and change my public key to a new one). Much better solution that the actual blog here I think (no offense Jeff!)


    3. I added this line under my “Host *” section of the ~/.ssh/config file


  2. After the above didn’t work I took a closer look and found that Apple seemed to be forcing my ‘identity’ which likely caused a key mismatch when connecting to my servers. In ~/.ssh/config I found this:

    IdentityFile “/Users/me/.ssh/TES.pem” <– new cert helpfully(?) added by Apple

    I commented that out and added a new line:

    IdentityFile "/Users/me/.ssh/myactualkeyfile"

    No restart of any services were required and I was able to log right back into everything without having to enter a password.


    1. Thanks for posting. That’s sort of odd but glad it worked for you. For me, I’m now on RSA keys and that’s working for me.


  3. If you’re on DigitalOcean, it’s actually possible to set/reset the root password, in case you have created the droplet without one.


  4. Thanks for the post.

    For me it wasn’t enough to enable password identification within my DigitalOcean sshd_config, because when trying to login via ssh I still got asked for the ssh key passphrase.

    I had to specify that I want to login using a password:

    ssh -o PreferredAuthentications=keyboard-interactive,password -o PubkeyAuthentication=no username@host

    Further more to make the new keys work with Transmit, I had to add it to my Keychain:

    ssh-add -K path/to/.ssh/key-name


    1. try using ssh -v to see what’s happening in detail. usually if it asks for a passphrase the key login is still not configured properly.


  5. Alexander Tuzhikov January 25, 2017 at 2:30 pm

    Hi Jeff, thank you so much, I have wasted an hour prior to finding this!


Leave a reply

Your email address will not be published. Required fields are marked *