Hacker News Reader

Comment by brandmeyer | Hacker News Reader

If you have servers too old to work with the latest keys, you can easily modify your ~/.ssh/config to automatically use a per-machine private key file:

  Host foo.example.com
    Keyfile ~/.ssh/my_obsolete_private_keyfile

View on HN

Additionally, you can have substitutions in there:

  Host *
    IdentityFile ~/.ssh/%r@%h

This is indeed better, as a compromise means only the private keys on the affected host are affected. That of course works better with a keypair per source/destination combination.

Note that this _does_ cause issues sometimes, as it means your ssh-agent (you _are_ using one of those, right?) will have more keys than a typical auth attempt limit, and software that assumes trying all your keys before prompting for input is a sane thing to do will fail.

That you should be doing anyways, shouldn't you?

You certainly can, it's almost certainly unnecessary though. SSH keys are not like passwords, compromise of a server with your pubkey in no way effects the security of your private key. Many people will post pubkeys online so they're easy to add to new servers.

Adding to this: GitHub publishes the public SSH keys of all of their users, for example: https://github.com/teozkr.keys

I use a different keypair for every service, and for each device connecting to the service because keys are cheap and easy to manage. One advantage is that if one or more private keys is compromised or potentially compromised, you don't need to revoke and reissue all keys. Another, possibly more practical advantage is that I prefer to have a per-service persona that is not tied to other services. Shared public keys makes it easier to link together different accounts as belonging to the same person.

Reply on news.ycombinator.com