Best system for managing ssh keys? [closed]

I've got several client computers (i.e. laptops, desktops, etc.), and I connect to several server machines that I manage, and I log into them all via SSH. I can imagine several schemes of managing ssh keys that would make sense, and I'm curious about what others do.

Option 1: One global public/private keypair.

I would generate one public/private keypair, and put the private key on every client machine, and the public key on every server machine.

Option 2: One keypair per server machine.

I would generate one keypair on each server machine, and put each private key on my client machines.

Option 3: One keypair per client machine.

Each client machine would have a unique private key, and each server machine would have the public keys for every client machine that I'd like to connect from.

Option 4: One keypair per client/server pair

Totally overboard?

Which of these is best? Are there other options? What criteria to you use for evaluating the right configuration?

I use Option 3: One keypair per client machine and it makes the most sense to me. Here are some of the reasons:

• If a client is compromised then that key (and only that key) needs to be removed from servers.
• It's flexible enough to decide what I can access from where, without granting blanket access to all servers from all clients.
• Very convenient. There's only 1 key for ssh-add, no confusion.
• Easy to set up and administer over Option 4

Option 4 is nice, but is just too much work. Option 3 gets you 98% there with much less hassle.

I use a solution that is a bit more complicated but very versatile as I want to maintain some separation in SSH identity keys used for my home network servers, office servers, consulting client network servers and other various systems I have accounts on.

Now that said I work from Linux workstations almost exclusively so I have a USB key that is setup using LUKS encryption and my X11 window manager along with the HAL daemon detect the LUKS encrypted drive and prompt for the decryption passphrase when it is inserted and attempted to be mounted. By storing this on an encrypted drive the way I do I don't ever store my SSH keys on any workstation.

I then have the following configuration in my ~/.ssh/config file:

Host *
    Protocol 2
    IdentityFile %d/.ssh/keys.d/id_rsa.%l
    IdentityFile %d/.ssh/keys.d/id_dsa.%l
    IdentityFile %d/.ssh/keys.d/%u@%l

The %d is translated to be the user's home directory by OpenSSH and in the ~/.ssh directory I have created keys.d as a symlink to the directory path on the encrypted USB drive when it is properly mounted.

The %l expression is translated to be the local client machines hostname and %u will be translated to the local client's username.

What this configuration does is allow SSH to look for a key using 3 different expressions. For instance if my local client's username was jdoe and my local client machine name were examplehost it would look in the following order until it found a key that both existed and was accepted by the remote server.

/home/jdoe/.ssh/keys.d/id_rsa.examplehost
/home/jdoe/.ssh/keys.d/id_dsa.examplehost
/home/jdoe/.ssh/keys.d/jdoe@examplehost

You could even use the %r expression to look for a key specific for the remote server username or %h for the remote server hostname just like %u and %l were used.

Update: Now I actually utilize the GnuPG gpg-agent with ssh-agent compatibility to just read and use the authentication key off my OpenPGP v2 smartcard.

I would eliminate both your option 1s (of which I suspect one was supposed to be option 2 ;-) because private keys are sensitive data, and it makes sense to keep them in as few places as possible. I personally would never copy a private key from one computer to another (or even from one file to another on the same computer), except maybe for making backups. Although unlike most encryption keys, if an SSH key gets lost it's not the end of the world (just create a new one, you don't lose any data).

Option 3 and use something like Puppet to handle the key management.

Option 3.

This also allow you to control which servers a client can access. e.g. if client X needs access to servers A and B, but C or D, you copy it's public key to only those hosts.