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. [Section 11.1.2.2] 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. [Section 8.2.4]
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.1 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). [Section 7.4.2] Table 6-2 displays a summary of the syntax.
Table 6.2. Syntax Summary
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. [Section 11.1.2.2] 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. [Section 8.2.4]
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.1 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). [Section 7.4.2] 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
|
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
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]). 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:
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]). 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
foreach keyfile (*)
ssh-add $keyfile
end
What happens when you invoke an SSH client?
$ ssh server.example.com
# An example directory
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:
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:
your ssh connection authenticates with the loaded identity, in this case id-normal, regardless of the -i option.
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 Identity
$ 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
[13]
your ssh connection authenticates with the loaded identity, in this case id-normal, regardless of the -i option.
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 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:
1. Generate a new SSH identity, as we have discussed in this chapter.
2. Set up a detailed client configuration that does what you want, using your new identity. This is the subject of Chapter 7.
3. 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 Chapter 8.
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.
[13]
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.
2. Set up a detailed client configuration that does what you want, using your new identity. This is the subject of Chapter 7.
3. 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 Chapter 8.
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.
[13]
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.
Book: SSH, The Secure Shell: The Definitive Guide
Section: Chapter 6. Key Management and Agents
6.5 Summary
In this chapter, we've seen how to create and use SSH identities, represented by key pairs, either individually (SSH-1) or in collections (SSH-2). Keys are created by ssh-keygen and are accessed by clients as needed. SSH-2 provides an additional layer of configuration, the identification file, which lets you use a set of identities as a single identity. You may have as many identities as you like.
SSH agents are useful timesavers to avoid retyping passphrases. Their operation has numerous subtleties, but once you get the hang of it, running an agent should become second nature.
6.5 Summary
In this chapter, we've seen how to create and use SSH identities, represented by key pairs, either individually (SSH-1) or in collections (SSH-2). Keys are created by ssh-keygen and are accessed by clients as needed. SSH-2 provides an additional layer of configuration, the identification file, which lets you use a set of identities as a single identity. You may have as many identities as you like.
SSH agents are useful timesavers to avoid retyping passphrases. Their operation has numerous subtleties, but once you get the hang of it, running an agent should become second nature.
No comments:
Post a Comment