Multiple Identities

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 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:

Additional security
If you use different SSH keys for different remote accounts, and one of your keys is cracked, only some of your remote accounts will be vulnerable.
Secure batch processes
Using an SSH key with an empty passphrase, you can create secure, automated processes between interacting computers, such as unattended backups. ["Using a plaintext key"] However, you definitely don't want your regular logins to use an unencrypted private key, so you should create a second key for this purpose.
Different account settings
You can configure your remote account to respond differently based on which key is used for connecting. For example, you can make your Unix login session run different startup files depending on which key is used.
Triggering remote programs
Your remote account can be set up to run specific programs when an alternative key is used, via forced commands. ["Forced Commands "]

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.

Switching Identities Manually

ssh 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). ["User Identity"] Table 6-2 displays a summary of the syntax.

Table 6-2. Syntax Summary

Version	ssh	scp	IdentityFile Keyword
SSH1, OpenSSH	ssh1 -i key_file ...	scp1 -i key_file ...	`IdentityFile` key_file
SSH2	ssh2 -i id_file ...	scp2 -i id_file ...	`IdentityFile` id_file

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 ["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]

[88]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.

Tailoring Sessions Based on Identity

Despite 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:

Generate a new SSH identity, as we have discussed in this chapter.
Set up a detailed client configuration that does what you want, using your new identity. This is the subject of "Advanced Client Use".
Set up your account on the SSH server machine to respond to your new identity in a desired manner. This is covered in detail in "Per-Account Server Configuration".

We strongly encourage you to experiment with this technique. You can do some really powerful and interesting things with SSH this way. If you're just running simple terminal sessions with SSH, you are missing half the fun.