27348363: Mac OS X 10.12: ssh-agent does not automatically load passphrases on the keychain during startup

[openradar-mirror]

Description

Summary:
In previous versions of macOS, ssh-agent used to remember the passphrases for the keys I added to the keychain with “ssh-add -K ”. After a reboot (or logout/login), it automatically picked up the passphrases from the keychain with no extra step.

In Sierra, I have to manually poke the agent to recognize there are passphrases on the keychain.

Steps to Reproduce:

1. Create an ssh key with a passphrase
2. Add its passphrase to the keychain using “ssh-add -K ”. It prompts for the passphrase and adds it to the keychain.
3. Enjoy passwordless authentication to GitHub, your servers, etc. (“ssh-add -l” confirms ssh-agent knows about the keys.)
4. Reboot your Mac
5. “ssh-add -l” shows the agent is empty. Applications using SSH authentication do not work or constantly prompt for a passphrase.
6. Run “ssh-add -K ” again. It returns immediately without a passphrase prompt, as it finds the correct passphrase already on the keychain.
7. SSH authentication now works fine.

Expected Results:
The agent should automatically load keys whose passphrases it can access on the keychain.

Actual Results:
I need to manually poke the agent after each logout/login.

Regression:
This used to be automatic before the Sierra betas. On one of my secondary Macs running El Capitan, ssh-agent still remembers SSH keys across reboots, with no special configuration (as far as I can tell).

Notes:

Here is a metadata dump of the two passphrase entries on my keychain. Keychain access shows that their ACLs always allow access to “ssh-agent”, “ssh-add” and “ssh”.

$ security find-generic-password -s "SSH" -a "/Users/lorentey/.ssh/id_rsa"
keychain: "/Users/lorentey/Library/Keychains/login.keychain-db"
version: 512
class: "genp"
attributes:
0x00000007 ="SSH: /Users/lorentey/.ssh/id_rsa"
0x00000008 =
"acct"="/Users/lorentey/.ssh/id_rsa"
"cdat"=0x32303130303932343138333830345A00 "20100924183804Z\000"
"crtr"=
"cusi"=
"desc"=
"gena"=
"icmt"=
"invi"=
"mdat"=0x32303130303932343138333830345A00 "20100924183804Z\000"
"nega"=
"prot"=
"scrp"=
"svce"="SSH"
"type"=

$ security find-generic-password -s "SSH" -a "/Users/lorentey/.ssah/git-fusion"
keychain: "/Users/lorentey/Library/Keychains/login.keychain-db"
version: 512
class: "genp"
attributes:
0x00000007 ="SSH: /Users/lorentey/.ssh/git-fusion"
0x00000008 =
"acct"="/Users/lorentey/.ssh/git-fusion"
"cdat"=0x32303133313131353130353430335A00 "20131115105403Z\000"
"crtr"=
"cusi"=
"desc"=
"gena"=
"icmt"=
"invi"=
"mdat"=0x32303133313131353130353430335A00 "20131115105403Z\000"
"nega"=
"prot"=
"scrp"=
"svce"="SSH"
"type"=

Product Version: Mac OS X 10.12 (16A239j)
Created: 2016-07-14T14:01:35.005190
Originated: 2016-07-14T16:01:00
Open Radar Link: http://www.openradar.me/27348363

[donCarlosOne]

Confirmed that this problem still exists in OSX 10.12 GM Candidate

[daenney]

According to https://twitter.com/lorentey/status/753581927412686850's interaction with Apple this is now the expected behaviour.

Basically the -K is still there and it'll store the thing in the Keychain but it never gets loaded from it.

[zwily]

In the past, when you'd create an ssh-agent it would automatically load all keys from the keychain. I use a utility that creates separate agents for each key that I use, so I don't forward personal agents to work servers (for example), and the utility had to start an agent then delete all unexpected keys from it. With this change, I just start an agent and add the desired agent with ssh-add -K /path/to/key and no cleaning up necessary.

Overall, this is probably a good change.

[zenopopovici]

Dunno about this... this was also present in last year's beta (10.11) and was fixed in the first bugfix release after launch.

[mgrandi]

running ssh-add -K still asks me for a password when it should be in the keychain. The keychain entry hasn't changed since may of 2015

[jimcistaro]

@mgrandi

You should be able to do an ssh-add -A (Add identities to the agent using any passphrases stored in your keychain.). -K is to store it to keychain the first time.

[supryan]

This kinda sucks if this was intentional behavior. I liked not having to think about it between reboots. I hope they fix this.

[karlhorky]

Some things that look like they could be helpful:

• difficulties with ssh-agent in macOS Sierra (self.osx)
• jirsbek/SSH-keys-in-macOS-Sierra-keychain

I'm going to try the ~/.ssh/config file with the AddKeysToAgent option from the first link.

[donCarlosOne]

I've found that the best way (for me) to deal with this is to execute a script upon opening a terminal window/tab. I use iTerm2, which does this automatically for me.

The script simply runs a basic command:

ssh-add -K .....

followed by each key that I need to have available whilst in a terminal session.

[jbz]

I just ran into ssh-agent problems with a new mac running El Cap. I can't use donCarlosOne's solution because my keys have passphrases. Basically, as far as I can tell, launchd is not starting an ssh-agent process at login - so I don't have the env var SSH_AUTH_SOCK set, so nothing can talk to the agent from my login process tree. I have no idea why it's not starting and providing the socket info. This is utterly maddening - I don't care about between reboots (although I'd like the Keychain to mean I don't need to re-add keys to the damn agent) but the agent won't run at all now. It runs if I start it manually with launchctl start, but of course the launchctl getenv SSH_AUTH_SOCK is still null. AIIIGH. Currently troling the net looking for a fix that doesn't involve installing an entire new openssh setup via brew.

[mgrandi]

@jbz when you do ssh-add -K it prompts you for the passphrase, and then it stores it in some magical keychain (that is no longer the Mac OS X keychain), so that when you do ssh-add -A later, it reads said magical keychain and loads them even if they have passwords.

and not sure your problem is related to this thread, ssh_agent should still be using the mac os x keychain (which is what we are talking about), something else is wrong for you =(