This was mentioned before, but if this post gains traction it's worth talking about again:
It is almost totally unnecessary to maintain multiple key pairs for multiple purposes if they're going to be stored on the same machine (eg separate key for github). If one of these services is compromised, an adversary will only get your public key, which is useless. This is very different than the security practices of symmetric passwords.
- Use a key specific to a given client system from which you connect. E.g.: separate keys for your work and personal machines. If one or the other is compromised, delete entries for the compromised key in your authorized_key files.
- Use shared keys, where necessary, for group infrastructure in a work setting. Examples might be an AWS login or other systems for which a single key is permitted (really, such cases should be rare).
- Use separate keys to make use of forced commands. These keys are single purpose, and are used to run a single command on a remote host (or set of hosts). They aren't general-purpose login keys.
It is good practice e.g. if you are a contractor and work with multiple organizations.
When your project is done you simply wipe the related SSH key. This way you can be sure that they cannot ask you to do some more work without proper legal framework (no more access, sorry) and you can prove that if there are compromises they were not done using your credentials.
> If one of these services is compromised, an adversary will only get your public key, which is useless.
True, but what if you connect to that system while it's compromised and under attacker's control? What if you want to separate your identities? What if you want to limit your responsibility and be able to just permanently delete the key after you finish working with some system thereby completely revoking your access to it? What if you want to store passwords to some keys in your system keyring but enter the pass every time for others?
Yeah, yeah, those are not exactly common but maintaining more than one key costs you nothing and adds a little flexibility.
>True, but what if you connect to that system while it's compromised and under attacker's control?
I don't follow you on this one. Could you expand a little bit?
>What if you want to separate your identities?
Sure, you can do this to preserve some privacy if you think the services might collude. But my point is that multiple keys don't make you more secure. (It's not like symmetric encryption where you should be using different passwords for everything.)
>What if you want to limit your responsibility and be able to just permanently delete the key after you finish working with some system thereby completely revoking your access to it?
This is a fair point, although having continued access is only a problem if an adversary gains control of the machine containing your private key (and in that case it's usually game over anyway). It's the job of the sysadmin of the other server to revoke authorized_keys as needed.
>What if you want to store passwords to some keys in your system keyring but enter the pass every time for others?
Again, a fair point, but this is only a risk if a bad guy has control of your machine. In general I'm referring to the misconception many people have that using multiple keys protects them if an external service is compromised. While this is true for passwords, for asymmetric crypto, revealing a public key is not really a problem.
It is almost totally unnecessary to maintain multiple key pairs for multiple purposes if they're going to be stored on the same machine (eg separate key for github). If one of these services is compromised, an adversary will only get your public key, which is useless. This is very different than the security practices of symmetric passwords.