5 ms·

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

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

fphilipe 10y ago
That you should be doing anyways, shouldn't you?
- Godel_unicode 10y ago
  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.
  - Nullabillity 10y ago
    Adding to this: GitHub publishes the public SSH keys of all of their users, for example: https://github.com/teozkr.keys https://github.com/teozkr.keys
  - x1798DE 10y ago
    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.
mook 10y ago
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.

fphilipe 10y ago

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

Godel_unicode 10y ago
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.
- Nullabillity 10y ago
  Adding to this: GitHub publishes the public SSH keys of all of their users, for example: https://github.com/teozkr.keys https://github.com/teozkr.keys
- x1798DE 10y ago
  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.

mook 10y ago

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.