macOS Sierra Stores and Syncs SSH Passphrases to iCloud | Hacker News Reader

macOS Sierra Stores and Syncs SSH Passphrases to iCloud

twitter.com

111 pointszalmoxes34 comments

Only if you enable iCloud Keychain, which is locally encrypted and synced in encrypted form. https://support.apple.com/en-us/HT202303 has links to the details.

It's not useful though as you shouldn't share ssh keys between machines anyway.

> you shouldn't share ssh keys between machines anyway.

Are you talking about public or private keys ? I see nothing wrong in using same public key to log in from a particular machine to a number of remote machines.

They meant only private keys.

> I see nothing wrong in using same public key to log in from a particular machine to a number of remote machines.

There is nothing really wrong with it; it's a good way to reduce the burden of managing secrets. The downside though is when multiple remote machines need to be contacted because a private key was revoked. Then again, a common need for revocation is a compromise of the machine on which the private key(s) is stored, which can often mean a number of private keys need to be revoked. I think the ideal is still to have unique key pairs for each client-server combination.

It's worth thinking this through one step further IMO. What kind of event would cause a private key to be compromised, so that it needs to be revoked?

The most likely cases are that (1) the client machine was compromised, or (2) an un-encrypted backup was lost. In either case, I have a hard time seeing how one private key needs to be revoked but others on the same client machine don't.

Agreed - it's what I meant by that third sentence. There are of course reasons to revoke one of a collection of keys, for example natural end-of-life rotation, weak key generation and accidental disclosure.

It's not useful to people who use different private keys on different machines. It is useful to anyone who has a single private key that they use on multiple machines. The latter isn't really a great idea, but I bet a bunch of people do it anyway.

In other words, it is useful to people who are doing it wrong.

Security isn't black and white. Maybe they aren't being as secure as they could be, but they're still more secure than someone who just uses a password. And maybe there's no real security concern at all, because both computers are desktops sitting right next to each other with the same user login credentials, so there's not really any reason why someone would need to cycle the key on one machine but not on the other.

There's also something weird going on with "-o BatchMode=yes", which is used by shells to tab-complete remote files for scp and rsync.

I could ssh into a server without typing the ssh key password, but zsh refused to tab-complete scp and rsync command lines. Turns out it was using "ssh -o BatchMode=yes servername somethingsomething" to retrieve a list of files, but "-o BatchMode=yes" prevented whatever magic is happening from unlocking the ssh key. Figuring this out was tricky because dtruss and lldb refused to attach to /bin/zsh and /usr/bin/ssh because of SIP. (In fact, "dtruss --help" lists "dtruss df -h" as the first example, something that doesn't even work on sierra because /bin/df is protected by SIP)

The fix is to run "ssh-add -A" after booting. Very odd, since there are no password prompts involved anywhere.

The next time you'd like to diagnose, you can reboot into Recovery and use "csrutil enable --without dtrace --without debug" and you should be able to avoid those issues.

That's true. But too much of a hassle.

One workaround is actually to just cp /bin/whatever to /tmp/whatever and debug that, but in this particular case I needed to follow forks (from zsh to ssh) so that wasn't as easy. Or I guess I could have played games with $PATH. Ah well.

Either way, there is something funny going on with ssh and private keys and their passphrases. Very odd how "-o BatchMode=yes" fails to load encrypted private keys that don't require any user input in normal use. And it's definitively something new because this was never a problem in 10.11 or below.

I think Apple stopped loading the passphrases into the agent automatically. I think they're strictly only loaded from the keychain now, per connection, unless you explicitly use -A to add them to the agent.

Edit: Ah, and another comment here provided the answer: https://news.ycombinator.com/item?id=12654917

This links to a tweet that links to https://openradar.appspot.com/28394826

Passphrases are stored by default, and if you enable iCloud Keychain, they're also synced.

This is different than in prior macOS versions.

In prior versions, it was stored in Login keychain, which was not synchronized.

Additionally, the items were visible in the security command line tool and in Keychain Access, so you could delete them.

The Local Items keychain / iCloud Keychain is a new style keychain that was back ported from iOS. The security and Keychain Access tools have no visibility into it, it's 100% handled by the secd service.

Edit: Ah, sorry, you meant in Sierra specifically. Yes. But I'll leave these clarifying details here for posterity :)

Edit2: Additional detail - in prior OSes, there was a GUI prompt asking if you wanted to store the passphrase in the keychain. This is gone now. It just does it (unless you preemptively edited the ssh config file to disable keychain storage in advance)

Edit3: Can confirm that "ssh-add -K -d" does in fact delete the passphrase from the keychain, even though it may throw an agent error.

> The security and Keychain Access tools have no visibility into it, it's 100% handled by the secd service.

That's not quite true: Keychain Access can write to Local Items keychain, but not everything in Local Items are visible to Keychain Access. Apple changed ssh to store private key passphrases differently than before, in a way that's invisible to Keychain Access. However, you can freely move / copy entries from, say your login keychain, to Local Items with Keychain Access, and vice versa, and they would remain visible.

Fortunately, the Local Items keychain, stored in ~/Library/Keychains/<UUID>/keychain-2.db is just a sqlite3 database, with (presumably) encrypted fields. If you run "ssh -vvv" you can even see the query.

> Edit3: Can confirm that "ssh-add -K -d" does in fact delete the passphrase from the keychain, even though it may throw an agent error.

Huh, I thought I'd tried that before resorting more drastic measures. Or maybe "-d" works but not "-D", hmm or maybe I'd neglected to also pass "-K".

FYI: ssh-agent in Sierra needs "AddKeysToAgent yes" in $HOME/.ssh/config to automatically load your keys, see

http://apple.stackexchange.com/questions/253779/macos-10-12-...

Anyone who has upgraded - Have you had issues with it prompting for your keychain password every time you wake your computer up and occasionally throughout the day?

Have you recently changed your iCloud password?

Reply on news.ycombinator.com