Skip to content

Integrating SSH with the keychain on Snow Leopard

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 leeg@jormungand.local
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:

ssh-add.png

Now the passphrase is stored in the keychain. Don't believe me? Lookie here:

ssh-keychain.png

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).

{ 8 } Comments

  1. David V. | September 29, 2010 at 4:40 am | Permalink

    Somehow this doesn’t work for me (OS X 10.6.4): When I enter an ssh command in the terminal I get no dialog and instead it asks me for a password:

    $ ssh other
    dx@other’s password:

    “other” is a Linux box.

  2. Graham | September 29, 2010 at 8:05 am | Permalink

    it looks like your SSH key isn’t being picked up. Either it isn’t in ~/.ssh/ (in which case, use the -i option to tell ssh where it is), or the filesystem permissions on the private key are too permissive. Off the top of my head, the key file’s mode should be 0400 I think.

  3. David V. | September 29, 2010 at 2:32 pm | Permalink

    Thanks for the suggestions. That doesn’t seem to be the problem though (the keys are in ~/.ssh and I changed the permissions from 0600 to 0400 without a change in effect).

  4. LF | November 9, 2010 at 4:39 pm | Permalink

    David, did you found a solution?..

    I have the same problem, I had a private key in my PC, copy it to my Mac, and when I tried to connect to the linux server, doesn’t get it

  5. Michael | February 26, 2011 at 1:47 am | Permalink

    Thanks for the tips, but I’m afraid I have the same problem as these other people – I’ve generated a key pair, added the public key to the remote machine, and now anything that uses ssh asks me to use the key’s passphrase and works like a charm.

    However, at no point has Keychain popped up and asked me if I wanted to store the passphrase. I wonder if it’s a problem with Keychain’s settings?

    Much thanks for publishing this workthrough, though.

  6. Michael | February 26, 2011 at 2:05 am | Permalink

    Update to my post, I’ve found a solution for my particular problem (http://discussions.apple.com/message.jspa?messageID=6746629)

    I had MacPorts installed. Although doing:
    which ssh-agent

    pointed to the system version, /opt/local/bin is before /usr/bin in PATH. So I was unwittingly using that version instead of the Snow Leopard flavour.

    Uninstalling MacPorts solved the problem. Of course, if you need MacPorts you could just uninstall the ssh stuff, or rename it.

    What goes around comes around – thanks for this post!

  7. Martin Allert | November 15, 2011 at 4:00 pm | Permalink

    First of all, just copying the files from a PC, where probably PuTTY is installed does not work, as PuTTY is using the PEM key format introduced by F-Secure ssh2. Therefore you have to convert the keys to the OpenSSH format using Puttygen.

    Second, if you try a ssh connection and it keeps asking for your password, see the sshd config of the remote machine whether public key authentication is enabled and/or password authentication is preferred.

    Third, OpenSSH is very picky about the permissions. The .ssh directory needs to have 0755 (rwxr-xr-x) permissions, the authorized_keys file 600 or 0644 and the private keys 0600.

    Fourth, try “ssh -vvv ” and you will see many many debug output where you can see whether your public-key is accepted. With “ssh-add -l” you can also see if the ssh-agent is running and if the private keys are loaded.

    Fifth, if the destination ssh server allows only ssh protocol 2 and you are coming along with an ssh1 key, you also get kicked out.

    Sixth, if the destination ssh server does not allow agent forwarding, you are screwed either.

  8. joshua | June 24, 2012 at 1:49 am | Permalink

    worked great – thanks!