6 ms·

macOS Sierra Stores and Syncs SSH Passphrases to iCloud

111 points by zalmoxes 10y ago

zalmoxes 10y ago
Passphrases are stored by default, and if you enable iCloud Keychain, they're also synced.
- pudquick 10y ago
  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.
  - RJIb8RBYxzAMX9u 10y ago
    > 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".
alrs 10y ago
This links to a tweet that links to https://openradar.appspot.com/28394826 https://openradar.appspot.com/28394826
joesmo 10y ago
This is a great default because we all know that iCloud is the most secure cloud service in the universe and can never get hacked.
- matt4077 10y ago
  It certainly can, but as far as I know, it hasn't been hacked. Those leaked photos were protected by weak passwords.
  - justinsaccount 10y ago
    I don't actively use iCloud. I don't have an iPhone. The only reason I even have an iCloud account is that you need to create one to install security updates from the app store. I bet that a lot of people have a stronger ssh key passphrase than the passphrase on their iCloud account. As far as I know I have not enabled iCloud Keychain unless apple decided to turn it on by default. The fact that apple could be protecting my ssh keys that I actually care about with the password for an iCloud account that I DON'T EVEN WANT is fucking stupid.
    - kccqzy 10y ago
      You don't have to create an iCloud account to install security updates. Just run `softwareupdate -i -a` from the Terminal. Moreover, you are confusing an iCloud account and an iTunes store/app store account. You can be logged in to an App Store yet have iCloud turned off.
      - eridius 10y ago
        Also, even if you do have an iCloud account, you can still separately configure whether or not iCloud Keychain is enabled. If it's not enabled, there's no keychain syncing. And IIRC, it's not enabled by default.
      - justinsaccount 10y ago
        > You don't have to create an iCloud account to install security updates How nice of it to tell you that while they are forcing you to create an account. > Just run `software update -i -a` from the Terminal. Looks like it is `softwareupdate -a -i`. > Moreover, you are confusing an iCloud account and an iTunes store/app store account What is the difference? I do not have an iTunes account. I've never even started iTunes. I have the iCloud account the software made me create in order to install updates.
sitharus 10y ago
Only if you enable iCloud Keychain, which is locally encrypted and synced in encrypted form. https://support.apple.com/en-us/HT202303 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.
- AlexeyBrin 10y ago
  > 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.
  - randallsquared 10y ago
    They meant only private keys.
  - bahjoite 10y ago
    > 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.
    - cvwright 10y ago
      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.
0x0 10y ago
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.
- pudquick 10y ago
  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.
  - 0x0 10y ago
    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.
    - pudquick 10y ago
      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 https://news.ycombinator.com/item?id=12654917
deleted 10y ago
[deleted]
okket 10y ago
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-sierra-will-not-forget-my-ssh-keyfile-passphrase http://apple.stackexchange.com/questions/253779/macos-10-12-...
markwaldron 10y ago
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?
- FireBeyond 10y ago
  Have you recently changed your iCloud password?

111 points by zalmoxes 10y ago

zalmoxes 10y ago

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

pudquick 10y ago
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.
- RJIb8RBYxzAMX9u 10y ago
  > 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".

alrs 10y ago

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

joesmo 10y ago

This is a great default because we all know that iCloud is the most secure cloud service in the universe and can never get hacked.

matt4077 10y ago
It certainly can, but as far as I know, it hasn't been hacked. Those leaked photos were protected by weak passwords.
- justinsaccount 10y ago
  I don't actively use iCloud. I don't have an iPhone. The only reason I even have an iCloud account is that you need to create one to install security updates from the app store. I bet that a lot of people have a stronger ssh key passphrase than the passphrase on their iCloud account. As far as I know I have not enabled iCloud Keychain unless apple decided to turn it on by default. The fact that apple could be protecting my ssh keys that I actually care about with the password for an iCloud account that I DON'T EVEN WANT is fucking stupid.
  - kccqzy 10y ago
    You don't have to create an iCloud account to install security updates. Just run `softwareupdate -i -a` from the Terminal. Moreover, you are confusing an iCloud account and an iTunes store/app store account. You can be logged in to an App Store yet have iCloud turned off.
    - eridius 10y ago
      Also, even if you do have an iCloud account, you can still separately configure whether or not iCloud Keychain is enabled. If it's not enabled, there's no keychain syncing. And IIRC, it's not enabled by default.
    - justinsaccount 10y ago
      > You don't have to create an iCloud account to install security updates How nice of it to tell you that while they are forcing you to create an account. > Just run `software update -i -a` from the Terminal. Looks like it is `softwareupdate -a -i`. > Moreover, you are confusing an iCloud account and an iTunes store/app store account What is the difference? I do not have an iTunes account. I've never even started iTunes. I have the iCloud account the software made me create in order to install updates.

sitharus 10y ago

Only if you enable iCloud Keychain, which is locally encrypted and synced in encrypted form. https://support.apple.com/en-us/HT202303 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.

AlexeyBrin 10y ago
> 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.
- randallsquared 10y ago
  They meant only private keys.
- bahjoite 10y ago
  > 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.
  - cvwright 10y ago
    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.

0x0 10y ago

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.

pudquick 10y ago
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.
- 0x0 10y ago
  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.
  - pudquick 10y ago
    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 https://news.ycombinator.com/item?id=12654917

deleted 10y ago

[deleted]

okket 10y ago

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-sierra-will-not-forget-my-ssh-keyfile-passphrase http://apple.stackexchange.com/questions/253779/macos-10-12-...

markwaldron 10y ago

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?

FireBeyond 10y ago
Have you recently changed your iCloud password?