macOS Sierra 10.12 SSH Keys

I updated to macOS Sierra 10.12 (GM) tonight and surprisingly everything seemed to work without any issues … at least so far. One thing that did come up, but was easily remedied, was that all of my SSH keys stopped working.

ssh git@github.com

The above command prompted for a password (assuming you use GitHub), which is should not do if SSH keys are set up properly.

Assuming your SSH keys are RSA-based, I have a quick solution:

cd ~/.ssh

This will get us into our user SSH folder

ssh-add -l

This lists all keys that the SSH agent knows about. After upgrading, this returned zero keys! Note: In reality ssh-add is session-based, and so each time you log in this command will show zero results (see below).

ssh-add -K ~/.ssh/[your-private-ssh-key-name]

You’ll be asked for the password (if one is set) for this private key

-K tells ssh-add to save the key into your Keychain, so that on subsequent logins, even if ssh-add -l shows nothing, ssh will also look in your Keychain to see if the key is save there.

[your-private-ssh-key-name] is likely id_rsa, but it could be others as well

Repeat step 3 as needed

ssh-add -l

You should now see you SSH key(s) listed

That worked for me, though oddly I had to do this process twice as the first time I made it to step four, then exited Terminal, none of my applications using SSH worked, I opened Terminal again and found that nothing was listed when I ran the ssh-add list command.

UPDATE:

This doesn’t seem to do what I thought it should, namely, upon reboot I had to repeat this process again. I have since added the following steps:

cd ~/.ssh/
sudo vim config

I then added this line to my SSH config file:

IdentityFile ~/.ssh/[your-private-ssh-key-name]

I saved the config file, and now my SSH keys work as expected.

UPDATE 2 (19 Dec 2016):

With Apple’s update to 10.12.2 I found myself having SSH issues yet again. A bit of searching pointed me to the updated man pages as seen via Terminal:

man ssh_config
AddKeysToAgent
    Specifies whether keys should be automatically added to a running ssh-agent(1). If this option is set to ``yes'' and a key is loaded from a file, the key and its passphrase are added to the agent with the default lifetime, as if by ssh-add(1). If this option is set to ``ask'', ssh will require confirmation using the SSH_ASKPASS program before adding a key (see ssh-add(1) for details). If this option is set to ``confirm'', each use of the key must be confirmed, as if the -c option was specified to ssh-add(1). If this option is set to ``no'', no keys are added to the agent. The argument must be ``yes'', ``confirm'', ``ask'', or ``no''. The default is ``no''.
UseKeychain
    On macOS, specifies whether the system should search for passphrases in the user's keychain when attempting to use a particular key. When the passphrase is provided by the user, this option also specifies whether the passphrase should be stored into the keychain once it has been verified to be correct. The argument must be ``yes'' or ``no''. The default is ``no''.

I eventually landed on the following inside my config file (~/.ssh/config), erasing everything I had added in the first UPDATE.

Host *
  AddKeysToAgent yes
  UseKeychain yes
  IdentityFile ~/.ssh/[your-private-ssh-key-name]

Afterwards I restarted to flush anything in SSH and noticed that everything was working correctly again. At this point, it’s probably a good idea just to start with this, assuming you’re running at least macOS 10.12.2.

Note: The above example I actually repeated three times since I have more than one SSH key that I need to use. Just copy and paste, being sure to update your private key filename.

20 Replies to “macOS Sierra 10.12 SSH Keys”

    1. I had thought the same initially, but none of my keys were that type. I haven’t had an issue since I followed the steps above, but as you point out, if you’re having a separate issue, the solution here might not help.

  1. Regarding your UPDATE 2 for macOS 10.12.2.

    Perhaps I’m doing something wrong but it doesn’t seem to store the keys in the keychain for me.

    I tried finding them in Keychain Access, but there’s nothing there.

    Then I locked the login keychain, and did `kill-all ssh-agent`. It still gets the passphrase from somewhere without unlocking the keychain.

    I’m not an expert with this. Can you shed some light on this?

    1. I just double-checked and I don’t see my SSH keys within the Keychain (Keychain Access) either. That said, it is working for me and as you pointed it, macOS is clearly pulling the passphrase(s) from somewhere — maybe a hidden part of the Keychain? I’m no expert either, just someone trying to help others with a solution to the crazy SSH behavior found in macOS 10.12!

      1. Thanks, I’m happy how it is right now, but it’s a bit strange. I don’t think it is stored in the Keychain. Perhaps that part isn’t implemented yet or some other option has to be set? Perhaps we find out some time.

  2. Thanks. Adding “UseKeychain yes” and “AddKeysToAgent yes” at the top of ~/.ssh/config outside of any host context works too, making active for all.

    Using ‘/usr/bin/security find-generic-password’ one can see the relevant password is indeed stored within Keychain.

  3. I’m using version 10.12.2 but I can’t use the UseKeychain in my config file, when I try to connect to a host it says “Bad configuration option: usekeychain”. UseKeychain is also not listed in the ssh_config man page on my machine.

    What could cause this issue?

    1. Hmm, the keyword may be case-sensitive, so use UseKeychain instead of usekeychain. Also, if you don’t see UseKeychain listed in the ssh_config man page, could you by chance be using a 3rd party version of SSH and not the one that comes with macOS?

  4. I have the correct case-sensitive UseKeychain in the config file, the error message just converted it to lower case.
    The issue was that I was using a third party SSH version, thanks for pointing that out!

Leave a Reply

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

This site uses Akismet to reduce spam. Learn how your comment data is processed.