Until now, we've assumed you have a single SSH identity that
uniquely identifies you to an SSH server. You do have a default
identity -- our earlier
examples
operated on it -- but you may create as many other identities as
you like.
Why use several identities? After all, with a single SSH identity,
you can connect to remote machines with a single passphrase.
That's very simple and convenient. In fact, most people can
survive perfectly well with just one identity. Multiple identities
have important uses, however:
In order to use multiple identities, you need to know how to switch
between them. There are two ways: manually, and automatically with an
agent.
6.4.2. Switching Identities with an Agent
If you use an SSH agent, identity-switching is handled automatically.
Simply load all the desired identities into the agent using
ssh-add. Thereafter, when you attempt a
connection, your SSH client requests and receives a list of all your
identities from the agent. The client then tries each identity in
turn until one authenticates successfully, or they all fail. Even if
you have 10 different identities for 10 different SSH servers, a
single agent (containing these keys) provides appropriate key
information to your SSH clients for seamless authentication with all
10 servers.
All this happens transparently with no effort on your part. Well,
almost no effort. There are two potential problems that can strike if
you have two SSH identities that can connect to the same SSH server.
The first problem occurs because the
agent stores identities in the order in
which it receives them from
ssh-add. As
we've said, the SSH client tries identities "in
turn," i.e., in the order it gets them from the agent.
Therefore, it is your responsibility to add identities to the agent
in a careful, useful order. Otherwise, if two or more identities
apply in a situation, an SSH client might authenticate with the wrong
one.
For example, suppose you have two SSH1 identities stored in the files
id-normal and
id-backups.
You use
id-normal for normal terminal sessions
to
server.example.com and
id-backups for invoking a remote backup program
on
server.example.com (e.g.,
using a forced command [
Section 8.2.4, "Forced Commands "]). Each day when
you log in, you load both keys into an agent, using a clever script
that locates and loads all key files in a given directory:
#!/bin/csh
cd ~/.ssh/my-keys # An example directory
foreach keyfile (*)
ssh-add $keyfile
end
What happens when you invoke an SSH client?
$ ssh server.example.com
In this case, the remote backup program gets run, authenticating with
the key in file
id-backups. You see, the
wildcard in your script returns a list of key files in alphabetical
order, so
id-backups is added before
id-normal, as if you'd typed:
$ ssh-add id-backups
$ ssh-add id-normal
Therefore, your SSH clients will always use the key
id-backups when connecting to
server.example.com because the agent
provides it first in response to a client request. This might not be
what you intended.
The second problem only makes this behavior worse: identities in an
agent take precedence over identities used manually. If an identity
in the agent can successfully authenticate, there's no way to
override the agent manually with the
-i command-line
option or the
IdentityFile keyword. So in the
earlier example, there is literally no way to use the identity
id-normal. The obvious attempt:
$ ssh -i id-normal server.example.com
still authenticates with
id-backup s because it
is loaded first into the agent. Even nonloaded identities can't
override the agent's selection. For example, if you load only
one identity into the agent and try authenticating with the other:
$ ssh-add id-normal
$ ssh -i id-backups server.example.com
your
ssh connection authenticates with the loaded
identity, in this case
id-normal, regardless of
the
-i option.
[88]
As a general rule, if you have two SSH identities valid on an SSH
server, don't load either identity into an agent. Otherwise,
one of those identities will be unable to access that server.
