Can/should I use a different ssh keypair for each remote host?

May 6, 2010 3:22 PM

How can I use a different ssh keypair for different remote hosts? (Or, alternatively: is this overkill?)

I notice that most of the tutorials out there on how to authenticate via ssh keys rather than username/password credentials seem to assume I'm working from a single keypair.

But I've been trying to set up different keyspairs for each host and I mostly seem to have gotten myself confused and with a setup that doesn't work. I've got id_rsa and id_rsa.pub files, and another a pair of such files for github, and another for another host as well, but when I actually go to ssh, it doesn't seem to be aware of which keypair goes with which host.

Are most of the tutorials that way because generally, most people just use one keypair and this is overkill? Or is my idea a perfectly reasonable one with a set of commands/configurations that can make this all go smoothly?

posted by weston to Technology (7 answers total)

I've got id_rsa and id_rsa.pub files, and another a pair of such files for github, and another for another host as well, but when I actually go to ssh, it doesn't seem to be aware of which keypair goes with which host.

This is a pretty vague description of your problem. What commands are you actually trying, what result are you getting, and how is it different from what you expect?

Maybe it would help if you explained what you're trying to achieve by using multiple keys. SSH supports it just fine, but I haven't yet seen a situation where it was necessary.
posted by teraflop at 3:31 PM on May 6, 2010

Best answer: It's overkill if you're the only one with access to the private key. The whole point of the arrangement is that it's infeasible to get from your public key to your private key.* It not only doesn't matter how many sysadmins might be peeking in your authorized_keys file, it still wouldn't matter if you posted it to the web with a "kick me" sign on it.

You can do it if you want, but I'd say it only makes sense if you need to keep the private key on a box to which someone else has admin access. And in that case you wouldn't want to keep other private keys there.

* Well, that's the theory. The theory could be rendered invalid by a mathematical breakthrough or the discovery of an unsuspected bug in RSA or its implementation. I was using a keypair for about a year that was one of a result space of only 32768 possibilities due to a Debian bug. But that was very different from generating the private key given the public key. You've got to choose which things you're going to worry about, and I spend no more time worrying about someone cracking my ssh private key than I do about someone breaking into my house and installing a keylogger.
posted by Zed at 3:43 PM on May 6, 2010 [1 favorite]

Generally, you can just put all your identification files on the command line as a set of -i flags, and let ssh figure out if any of the keys you've offered will work.

ssh -i ~/.ssh/id_rsa -i ~/.ssh/other_id_rsa -i ~/key_not_in_ssh_DSA user@myhost

When you give a command like this, if you turn on debugging, you can see that the client and server will just try all the keys until one works, or you reach the maximum authentications limit for the server in question.
posted by nomisxid at 3:45 PM on May 6, 2010 [1 favorite]

Best answer: For the first host (host1.example1.com):

$ ssh-keygen -t dsa -f /home/weston/.ssh/key1

For the second host (host2.example2.com):

$ ssh-keygen -t dsa -f /home/weston/.ssh/key2

Do whatever it is you do so that the ssh server has the public key in the authorized_keys file.

Then edit your /home/weston/.ssh/config file so that you have lines like:

Host host1.example1.com
IdentityFile /home/weston/.ssh/key1
User username_on_host1

Host host2.example2.com
IdentityFile /home/weston/.ssh/key2
User username_on_host2

Then, unless your ssh command is overridden by command-line options, it will use the specified private key and the specified username when connecting to the given host.

Note that the "Host" line can take wildcards, so that "Host *.example1.com" will use the same private key and username for host1.example1.com, www.example1.com, etc.

You can get the man page on the ssh config file by "man ssh_config" if you're on a unix system.
posted by chengjih at 4:07 PM on May 6, 2010 [1 favorite]

Yep, what chengjih said. List them in config and name the key files with the host they're used with so they're easy to keep track of. Without the config lines, ssh will try each private key in the identity file(s) it knows of in succession until one works. Don't sweat having multiple keys.
posted by cowbellemoo at 4:32 PM on May 6, 2010

Yup, chengjih has it. Precisely how I manage different keys for GitHub and my own servers and LAN computers.
posted by i_am_a_Jedi at 8:28 PM on May 6, 2010

You haven't explained why you want to do this, which leads me to think you don't understand what is going on.
You could do what chengjih writes, but I can't think of a reason why you would do this: if the machine with your private key is compromised, it is almost certain that all of your private keys are compromised.
posted by devnull at 2:20 AM on May 7, 2010