How to SSH agent forward into a docker container

docker-ssh-forward.bash

docker run -rm -t -i -v $(dirname $SSH_AUTH_SOCK) -e SSH_AUTH_SOCK=$SSH_AUTH_SOCK ubuntu /bin/bash

This exposes the value of the $SSH_AUTH_SOCK (whichiis the path to a socket file on the host) as a volume into the docker container (at the location /ssh-agent). Inside the container you then set the environment variable $SSH_AUTH_SOCK with the path to the volume inside, /ssh-agent). Since this environment variable is now set, ssh-agent -l can make use of it inside the container. When you run these commands inside the docker container you're root and so you have access.

If you're running this command in a Vagrant created VM, you might have problems with the file in $SSH_AUTH_SOCK being a symlink, so this worked for me:

docker run -i -t -v $(readlink -f $SSH_AUTH_SOCK):/ssh-agent -e SSH_AUTH_SOCK=/ssh-agent ubuntu /bin/bash

Anyone get this to work in boot2docker yet?

+1 @arunthampi That works very well in my Vagrant+Docker setup. I was using a Docker container to run Capistrano commands, so I had a few other things. I needed to add a --env CAP_USER=$CAP_USER and then in my Vagrant VM .bashrc source a file that contained my remote CAP_USER username.

File /home/vagrant/.cap_user contains just remote-user
Then in file: /home/vagrant/.bashrc I have a line like this:

    test -f ~/.cap_user && export CAP_USER=$(cat ~/.cap_user) || true

I set that file up in the VM using the Vagrantfile shell provisioner to copy both files into the VM.

Viola. Capistrano deploying happening inside a Docker container.

@tobowers: Works for me on boot2docker on mac, but I have to do it in two steps, SSH into the host VM, then run @arunthampi's code. Like so:

 $ boot2docker ssh
 $ docker run -i -t -v $(readlink -f $SSH_AUTH_SOCK):/ssh-agent -e SSH_AUTH_SOCK=/ssh-agent ubuntu /bin/bash

Once you're in to the host VM, you can check out forwarding status with ssh-add -L. If you get the publickeys you expect, proceed into the container.

@dts You forgot -A.

$ boot2docker ssh -A
$ ssh-add -l
2048 97:f0:e8:b3:c6:cb:2b:06:93:31:f5:a5:c6:0c:22:07 /Users/alan/.ssh/id_rsa (RSA)
$ docker run -i -t -v $(readlink -f $SSH_AUTH_SOCK):/ssh-agent -e SSH_AUTH_SOCK=/ssh-agent ubuntu /bin/bash
$ apt-get -q=2 update && apt-get -q=2 install ssh > /dev/null 2>&1
$ ssh-add -l
2048 97:f0:e8:b3:c6:cb:2b:06:93:31:f5:a5:c6:0c:22:07 /Users/alan/.ssh/id_rsa (RSA)

@tobowers On boot2docker Just your home dir is available on boot2docker-vm, maybe if you symlink the ssh-agent socket to $HOME/something this can work.

I'm trying this, but with docker-compose. I was typing a comment, but too much for this gist. Any help is appreciated over on http://stackoverflow.com/questions/32897709/ssh-key-forwarding-inside-docker-compose-container

Great thanks.

docker run --volume $SSH_AUTH_SOCK:/ssh-agent --env SSH_AUTH_SOCK=/ssh-agent ubuntu ssh-add -l

Works pretty well!

Has anyone managed to use SSH agent forwarding in combination with running the container as a different user e.g. docker run -u $(id -u):$(id -g) --volume $SSH_AUTH_SOCK:/ssh-agent --env SSH_AUTH_SOCK=/ssh-agent ...?

SSH actually checks that the effective UID is present in the password database and fails with You don't exist, go away! otherwise.

I get the following error when trying this out. I'm using a mac and have tried this on both docker for mac and docker-machine. I had to first install git on the ubuntu image.

docker run --volume $SSH_AUTH_SOCK:/ssh-agent --env SSH_AUTH_SOCK=/ssh-agent ubuntu ssh-add -l                             ✹ ✭
Error connecting to agent: Connection refused

@whistler, sharing the auth socket is currently not working for docker for mac, see:
docker/for-mac#410

It seems there is a work in progress that should be available before the end of November:
docker/for-mac#483

@gautaz thanks for the heads up!

What if I have Windows? How to use SSH_AUTH_SOCK?

I can clone repo with common git for WIndows, but not inside the container

It would very helpfull to get a clarification on how to share ssh keys when the hots is windows (maybe by a key copy..)

@Sylvain, give a chance to WSL (Windows Subsystem for Linux).

@kynan if you aren't using a remote user database for your system (eg LDAP/AD) you can map in /etc/passwd read-only so SSH can find your user.

Maybe, there is similar way to integrate gpg into docker container?

@ghost asks

Maybe, there is similar way to integrate gpg into docker container?

Browsing around, I saw this: https://github.com/transifex/docker-gpg-agent-forward

How if docker-compose and docker-daemon not in a same machine such as boot2docker?
I want to put this bunch of parameters in the docker-compose.yaml instead of typing them every time.

For anyone who comes across this: This will not work for anyone using Docker for Mac due to os limitations around file socket access. See: docker/for-mac#410

This works for me for the first shell logon, but fails for successive attempts. My use case is a remote container that has a longer lifespan, usually of a couple weeks. Is there a solution that is robust against the changing of the SSH_AUTH_SOCK target?

docker run -dit \
	--network host \
	--gpus all \
	--restart unless-stopped \
	--privileged \
	-e "DISPLAY=$DISPLAY" \
	-e "QT_X11_NO_MITSHM=1" \
        -e "$SSH_AUTH_SOCK:/ssh-agent" \
        -e "SSH_AUTH_SOCK=/ssh-agent" \
	-v "$XSOCK:$XSOCK" \
	-v "$HOME/data:/root/data:rw" \
	-v "$HOME/.gitconfig:/root/.gitconfig" \
	--name $NAME $NAME:latest bash

The official guidance works for me, when nothing else has. It's not very well explained, but the bind mount paths are magic values to allow SSH agent forwarding.

-e "$SSH_AUTH_SOCK:/ssh-agent" \

maybe -v here instead of -e ?

Hi everyone. I have the same problem. Has anyone found the solution?
This works for me for the first shell login, but fails for successive attempts

sudo docker run --restart always --network host --name github-runner -v $SSH_AUTH_SOCK:/ssh-agent -e SSH_AUTH_SOCK=/ssh-agent -e REPO_URL="$REPO_NAME" -e ACCESS_TOKEN="$ACCESS_TOKEN" myoung34/github-runner:latest

If you're on a mac, the current incantation should be:

docker run -it --rm -v /run/host-services/ssh-auth.sock:/run/host-services/ssh-auth.sock -e SSH_AUTH_SOCK="/run/host-services/ssh-auth.sock" debian bash

For anyone struggling to get ssh-agent forwarding to work for non-root container users, here's the workaround I came up with, running my entry point script as root, but using socat + su-exec to expose the socket to the non-root user and then run commands as that user:

1. Add socat and su-exec to the container in your Dockerfile (you might not need the later if you're not using alpine)

USER root
RUN apk add socat su-exec
# for my use case I need www-data to have access to SSH, so 
RUN \
    mkdir -p /home/www-data/.ssh && \
    chown www-data:www-data /home/www-data/.ssh/

2. In your entrypoint:

#!/bin/sh
# Map docker's "magic" socket to one owned by www-data
socat UNIX-LISTEN:/home/www-data/.ssh/socket,fork,user=www-data,group=www-data,mode=777 \
    UNIX-CONNECT:/run/host-services/ssh-auth.sock \
    &
# set SSH_AUTH_SOCK to the new value
export SSH_AUTH_SOCK=/home/www-data/.ssh/socket
# exec commands as www-data via su-exec
su-exec www-data ssh-add -l
# SSH agent works for the www-data user, in reality you probably have something like su-exec www-data "$@" here

3. Run your container as @conf states:

docker run -it --rm -v /run/host-services/ssh-auth.sock:/run/host-services/ssh-auth.sock -e SSH_AUTH_SOCK="/run/host-services/ssh-auth.sock" name cmd

shrug this: -v "$SSH_AUTH_SOCK:$SSH_AUTH_SOCK" -e SSH_AUTH_SOCK=$SSH_AUTH_SOCK worked for me. The original gist did not.

@unphased Probably due to the symlink situation, as @arunthampi noticed here.

The line the worked for me was docker run -i -t -v $(readlink -f $SSH_AUTH_SOCK):/ssh-agent -e SSH_AUTH_SOCK=/ssh-agent ubuntu /bin/bash

@unphased
volume $SSH_AUTH_SOCK:/ssh-agent
and ENV SSH_AUTH_SOCK=/ssh-agent worked for me for years.
But after I've upgraded packages to the latest (ubuntu 22), the agent just stopped working! I mean - ssh-add -l was saying that it does not have access to the agent.
Thank you, your snippet works! Spent the whole day on this issue ))