Not much movement has occurred on projects like SSHKeychain.app or SSHAgent.app in the last couple of years. The reason is that it’s not necessary to use them these days; you can get all of the convenience of keychain-stored SSH passphrases using the built in software. Here’s a guide to using the Keychain to store your pass phrases.
Create the key pair
We’ll use the default key format, which is RSA for SSH protocol 2.0. We definitely want to enter a passphrase, so that if the private key is leaked it cannot be used.
jormungand:~ leeg$ ssh-keygen Generating public/private rsa key pair. Enter file in which to save the key (/Users/leeg/.ssh/id_rsa): Enter passphrase (empty for no passphrase): Enter same passphrase again: Your identification has been saved in /Users/leeg/.ssh/id_rsa. Your public key has been saved in /Users/leeg/.ssh/id_rsa.pub. The key fingerprint is: ff:ce:0a:f6:ee:0d:e8:a5:aa:56:a0:f3:0b:81:80:cc email@example.com The key's randomart image is: +--[ RSA 2048]----+ | | |+ | |oE | |.. . | |. .. . S | | o. . o | | .o . + + | | .o o = = | | .oo..oo=o= | +-----------------+
If you haven’t seen it before, randomart is not a screenshot from nethack; rather it’s a visual hashing algorithm. Two different public keys are not guaranteed to have different randomart fingerprints, but the chance that they are close enough to pass a quick visual inspection is small.
Deploy the public key to the SSH server
Do this using any available route; I choose to use password-based SSH.
jormungand:~ leeg$ ssh heimdall.local 'cat - >> .ssh/authorized_keys' < .ssh/id_rsa.pub Password:
There is no step three
Mac OS X automatically runs ssh-agent, the key-caching service, as a launchd agent. When SSH attempts to negotiate authentication using your key-based identity, you automatically get asked whether you want to store the passphrase in the keychain. Like this:
Now the passphrase is stored in the keychain. Don't believe me? Lookie here:
So your SSH key is protected by the passphrase, and the passphrase is protected by the keychain.
Update: Minor caveat
Of course (and I forgot this :-S), if you use FileVault to protect the home folder on the SSH server, the user's home folder isn't mounted until after you authenticate. This means that the authorized_keys file can't be consulted during negotiation. Once you have logged in once (using your password), subsequent logins will use the keys (as PAM automatically mounts the FileVault volumes the first time, so authorized_keys becomes available).