Suppose you have a batch script that runs ssh to launch remote processes. If the script runs ssh many times, it prompts for your passphrase repeatedly, which is inconvenient for automation (not to mention annoying and error-prone). If you run an agent, however, your script can run without a single passphrase prompt. [11.1]

In our running example, we copied a file from the remote to the local host:

    $ scp pat@shell.isp.com:printme.pdf imprime-moi.pdf

In fact, scp can copy a file from the remote host shell.isp.com directly to a third host running SSH on which you have an account named, say, “psmith”:

    $ scp pat@shell.isp.com:printme.pdf psmith@other.host.net:imprime-moi.pdf

Rather than copying the file first to the local host and then back out again to the final destination, this command has shell.isp.com send it directly to other.host.net. However, if you try this, you run into the following problem:

    $ scp pat@shell.isp.com:printme.pdf psmith@other.host.net:imprime-moi.pdf
    Enter passphrase for RSA key 'Your Name <you@local.org>': ************
    You have no controlling tty and no DISPLAY.  Cannot read passphrase.
    lost connection

What happened? When you run scp on your local machine, it contacts shell.isp.com and internally invokes a second scp command to do the copy. Unfortunately, the second scp command also needs the passphrase for your private key. Since there is no terminal session to prompt for the passphrase, the second scp fails, causing the original scp to fail. The SSH agent solves this problem: the second scp command simply queries your local SSH agent, so no passphrase prompting is needed.

The SSH agent also solves another, more subtle, problem in this example. Without the agent, the second scp (on shell.isp.com) needs access to your private-key file, but the file is on your local machine. So, you have to copy your private key file to shell.isp.com. This isn’t ideal; what if shell.isp.com isn’t a secure machine? Also, the solution doesn’t scale: if you have a dozen different accounts, it is a maintenance headache to keep your private key file on all of them. Fortunately, the SSH agent comes to the rescue once again. The remote scp process simply contacts your local SSH agent and authenticates, and the secure copy proceeds successfully, through a process called agent forwarding.

In the preceding example, the remote instance of scp has no direct access to your private key, since the agent is running on the local host, not the remote host. SSH provides agent forwarding [6.3.5] to address this problem.

When agent forwarding is turned on,^[9] the remote SSH server masquerades as a second ssh-agent, as shown in Figure 2-4. It takes authentication requests from your SSH client processes there, passes them back over the SSH connection to the local agent for handling, and relays the results back to the remote clients. In short, remote clients transparently get access to the local ssh-agent. Since any programs executed via ssh on the remote side are children of the server, they all have access to the local agent just as if they were running on the local host.

Figure 2-4. How agent forwarding works

In our double-remote scp example, here is what happens when agent forwarding comes into play (see Figure 2-5):

Figure 2-5. Third-party scp with agent forwarding

Agent forwarding works over multiple connections in a series, allowing you to ssh from one machine to another, and then to another, with the agent connection following along the whole way. These machines may be progressively less secure, but agent forwarding doesn’t send your private key to the remote host: it just relays authentication requests back to the first host for processing. Therefore, you don’t have to copy your private key to other machines.