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 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) 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).
(Some of this information comes from this stackoverflow answer.)
(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.)
|
|