6.4. Multiple IdentitiesUntil 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 ssh-add 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:
6.4.1. Switching Identities Manuallyssh and scp let you switch your identity with the -i command-line option and the IdentityFile configuration keyword. For either of these techniques, you provide the name of your desired private key file (SSH1, OpenSSH) or identification file (SSH2). [Section 7.4.2, "User Identity"] Table 6-2 displays a summary of the syntax.
Table 6-2. Syntax Summary
6.4.2. Switching Identities with an AgentIf 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
What happens when you invoke an SSH client?foreach keyfile (*) ssh-add $keyfile end
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 server.example.com
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-add id-backups $ ssh-add id-normal
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 -i id-normal server.example.com
your ssh connection authenticates with the loaded identity, in this case id-normal, regardless of the -i option.$ ssh-add id-normal $ ssh -i id-backups server.example.com
This undocumented behavior drove us insane until we figured out what was happening. Similar behavior occurs with Kerberos authentication in SSH1. If you have Kerberos credentials that allow you to connect, you aren't running an agent, and you specify a key with -i, that key isn't used unless you destroy your Kerberos credentials (or otherwise make them unusable, for instance, hiding them by setting the KRB5CCNAME variable), because Kerberos is tried first.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.
6.4.3. Tailoring Sessions Based on IdentityDespite the gloom and doom in the previous section, multiple identities can be extremely useful. In particular, you can configure your remote accounts to respond differently to different identities. This is a three-step process:
Copyright © 2002 O'Reilly & Associates. All rights reserved.