.:. brainsik / jeremy avnet

SSH Agent Forwarding

This is part of the mini-series OpenSSH for Devs.

SSH agent forwarding let’s you lock down remote hosts while making them easier to access and use in automated ways. One co-worker succinctly describes agent forwarding as “the shit”.

Example

Securely connect to a remote host from a remote host without a password.

laptop:~$ ssh -A host1.example.com
Linux host1 2.6.35-25-server #44-Ubuntu SMP Fri Jan 21 19:09:14 UTC 2011 x86_64 GNU/Linux

host1:~$ scp host2.example.com:some.config .
some.config                                                       100% 1612     1.6KB/s   00:00    
host1:~$ logout
Connection to host1.example.com closed.

Secret Agent

The SSH agent has become so integrated into our local systems many people don’t realize it’s being used. Devs use it daily to avoid having to retype their SSH key¹ password every time they connect to a remote host. The typical workflow is:

1. Login to laptop
2. SSH to a remote host
3. Type SSH key password into popup
4. No more password typing

The agent serves us by holding onto our private key and transparently authenticating to remote hosts when we connect instead of making us type a password.²

What is SSH agent forwarding?

Simply put, agent forwarding allows you to access a remote machine from a remote machine.

Let’s look at the scenario above: connect to host1 and download a file from host2. Without agent forwarding, you’re lucky if you just get to type your password again. If host2 has password authentication disabled or your account has no password set, there’s two options. Option 1: download the file from host2 to your local machine and then upload it to host1. Option 2: upload your SSH private key to host1 and authenticate to host2 using your key password. Compare these to agent forwarding where you run scp and the file is downloaded without question.

If you’ve run into this problem more than a few times, learning about agent forwarding may feel like this:

Where can it take you?

The SSH agent provides a rare pairing of increased security and better user experience.

From a per-host perspective, you can disable password authentication on all your remote machines and rely on SSH keys for superior auth. Leaked passwords are no longer a vector for unauthorized access since you can’t login with them. Forget about generating random passwords for every user on every new server. If sudo access isn’t needed, don’t set a password at all. If sudo access is required you can get away with reusing passwords, keeping your devops team lean³.

From a network perspective, you ideally want your private servers only accessible via a bastion host or other intermediary. With agent forwarding, instead of this setup being a pain to get into, it’s a single command:

$ ssh -At public.example.com ssh private1.internal
Linux private1 2.6.35-25-server #44-Ubuntu SMP Fri Jan 21 19:09:14 UTC 2011 x86_64 GNU/Linux

private1:~$ logout
Connection to private1.internal closed.
Connection to public.example.com closed.

Use it

Agent forwarding can be turned on via the command-line by passing -A or via your SSH config by setting ForwardAgent yes.

I’d be negligent if I didn’t recommend setting this only for hosts you trust. While it’s not possible to steal a private key through an agent, it’s trivial for a malicious root user to login to remote hosts with your public key.

Is there another way you use SSH agent forwarding? You should post a comment or send me a message.