In the context of deploying Appy apps and exts on test or production servers (among other similar DevOps tasks), SSH agent forwarding is something I use extensively.

Suppose you have:

1. a developer machine;
2. a distant server (test, production) onto which you must deploy your app;
3. a SSH-based git code repository from which the distant server (2) must git-pull code updates.

When deploying the app from (1) to (2), appy.deploy uses private-key-based SSH authentication, with a key typically stored in ~/.ssh.

SSH agent forwarding is then used in order to carry the private key from (1) to (3), when (2) needs to authenticate itself to (3) in order to git-pull a code update.

Enabling agent forwarding on the developer machine (1)

In order to enable this authentication chain, from (1) to (3), an SSH agent must be running on the first machine (1).

On some Linux distros, the agent is automatically launched.

With Arch, you need to launch it yourself.

One technique is to add the following lines in ~/.bashrc. In the example, the private key to use is supposed to lie in /root/.ssh/id_rsa.

eval $(ssh-agent -s)
ssh-add /root/.ssh/id_rsa

Everytime you open a new shell, you will get a message like this one.

Agent pid 17634
Identity added: /root/.ssh/id_rsa (/root/.ssh/id_rsa)

Enabling agent forwarding on the distant server (2)

The sshd daemon that runs on the distant server has a configuration file that lies in /etc/ssh/sshd_config. It should have this option:

AllowAgentForwarding yes

Note that if this option is absent from the file, this is not a problem, because yes is the default value.

Troubleshooting

In order to have some debug info about your private key being recognized and carried on the chain, you may use the -v option for ssh from (1) to (2).

Similarly, from (2) to (3), the git pull command may be prefixed with this variable definition:

GIT_SSH_COMMAND="ssh -v -o UserKnownHostsFile=/dev/null -o StrictHostKeyChecking=no" git -C <path_to_repo> pull

When you connect, via SSH, to the distant server (2) and agent forwarding works, the socket through which the private key is carried is mentioned in an environement variable named SSH_AUTH_SOCK.

Typing the command:

env | grep SOCK

should show you an environment variable like this one.

SSH_AUTH_SOCK=/tmp/ssh-K3j3bMhU6B/agent.90183

If it is not the case, it means that agent forwarding does not work.

Logging in as root on (2)

The easiest setting is to log as root to (2). Being root, you may launch git-pull commands as root from (2) to (3), and the private key will be carried without problem.

Logging in as non-root on (2)

If you log as non-root to (2), you must use the same login to run git-pull commands on (3). Indeed, the authentication socket as mentioned in variable SSH_AUTH_SOCK is only accessible, on (2), to the user logged from (1) and root.

So, if you try to log from (1) to (2) with user gaetan, and then, on (2), switch to user appy and perform git-pull commands, the authentication socket will not work, although the environment variable is defined and visible by the appy user.