== What ssh-agent does with multiple keys loaded Ssh-agent is probably normally used to handle a single identity key, but it can hold more than one if you want. One of the things that the _ssh-agent_ and _ssh_ manpages are a bit silent on is what happens if you have multiple SSH keys loaded into a single _ssh-agent_. Since I've been dealing with this as the result of transitioning from one set of SSH keys to another, I'm going to write down what I've learned so far. (The simple version of why I decided to roll over my SSH keys is that I decided to transition from [[keys that had once been used without encryption ../linux/EncryptedSSHKeyMigration]] to keys that were created encrypted.) Before I started loading multiple keys into _ssh-agent_, what I expected to happen is that the choice of which ssh-agent key to use would be controlled by the key that _ssh_ itself would normally use. If you had, for example, '_IdentityFile .../key1-rsa_', then I expected _ssh_ to ask _ssh-agent_ to do operations only with that key. This is not what happens. Instead what happens by default is that ~~ssh tries all keys loaded into ssh-agent, one after another, in the order that they were loaded into ssh-agent~~. You can partly override this behavior with the _IdentitiesOnly_ configuration directive, which will restrict the keys that _ssh_ tries to only the identities listed either as _IdentityFile_ directives or supplied on the command line with _-i_. However this is an incomplete override because it doesn't prioritize the _-i_ identity the way a normal (agentless) _ssh_ will; _ssh_ will first ask _ssh-agent_ for any _IdentityFile_ keys it has and only then fall back to a non-agent key given with _-i_. This implies that if you have a script and you want it to always use a particular restricted identity even if more general ones are available ([[as I do in one case EncryptedSshKeysAndScreen]]) you need to clear (($SSH_AUTH_SOCK)) in the script. (This can apply any time you have a remote system that accepts multiple identities from you but applies different access permissions or access restrictions to them. Remember that _IdentityFile_ directives add together and _-i_ stacks with with them too, so even if you have a specific identity configured for something, a general '_Host *_' identity or the like will also be tried.) There are a couple of interesting uses I can see for this multiple key behavior. One of them is making a transition between old and new SSH keys easier. First off, you can load both your new and your old key into _ssh-agent_; you'll then use your new key on systems that have been updated to accept only it but have a transparent fallback to systems that only have your old key. More cleverly you can use this to uncover systems that haven't been updated to your new key by loading only your new key into _ssh-agent_ but leaving your old encrypted key configured as your _IdentityFile_. If you try to _ssh_ to somewhere but get prompted to unlock your old key, you've found a host that either prefers your old key to your new key or doesn't have your new key at all. Another use is encrypting secondary keys (for example your Github key) but still loading them into _ssh-agent_ for passwordless use. Since _ssh_ with _ssh-agent_ will try multiple keys, pushing to Github and other such uses will eventually try the right keys. You can force this to happen earlier by setting _IdentitiesOnly_ in _.ssh/config_ for the particular hosts involved; this will definitely be necessary if you have a lot of SSH keys, because SSH servers only accept so many key attempts ([[cf http://serverfault.com/questions/401737/choose-identity-from-ssh-agent-by-file-name]]). (Some of this information comes from [[this stackoverflow answer http://superuser.com/questions/272465/using-multiple-ssh-public-keys/272613#272613]].) (Talking of the interaction of _ssh_ and _ssh-agent_, it's a pity that as far as I know _ssh_ can't be told 'load keys into _ssh-agent_ when you unlock them'. This would make it very convenient to incrementally load keys into _ssh-agent_ as you turn out to need them while not having them sitting around unlocked in a session if you didn't.)