$SSH_AUTH_SOCK is not being forwarded to docker

[mariusgrigaitis]

Expected behavior

OSX ssh-agent socket is available (for mount) in containers

$ docker run -it -v ${SSH_AUTH_SOCK}:${SSH_AUTH_SOCK} -e SSH_AUTH_SOCK="${SSH_AUTH_SOCK}" --rm alpine:3.4 /bin/sh -c "apk update && apk add dropbear-ssh && ssh -T git@github.com"
fetch http://dl-cdn.alpinelinux.org/alpine/v3.4/main/x86_64/APKINDEX.tar.gz
fetch http://dl-cdn.alpinelinux.org/alpine/v3.4/community/x86_64/APKINDEX.tar.gz
v3.4.3-7-g2f47d74 [http://dl-cdn.alpinelinux.org/alpine/v3.4/main]
v3.4.2-11-g9b41a63 [http://dl-cdn.alpinelinux.org/alpine/v3.4/community]
OK: 5968 distinct packages available
(1/2) Installing dropbear (2016.74-r0)
(2/2) Installing dropbear-ssh (2016.74-r0)
Executing busybox-1.24.2-r9.trigger
OK: 5 MiB in 13 packages

Host 'github.com' is not in the trusted hosts file.
(ssh-rsa fingerprint md5 16:27:ac:a5:76:28:2d:36:63:1b:56:4d:eb:df:a6:48)
Do you want to continue connecting? (y/n) yes
Hi <githubusername>! You've successfully authenticated, but GitHub does not provide shell access.

Actual behavior

OSX ssh-agent socket is available, but does not work because it's a socket (unable to connect)

$ docker run -it -v ${SSH_AUTH_SOCK}:${SSH_AUTH_SOCK} -e SSH_AUTH_SOCK="${SSH_AUTH_SOCK}" --rm alpine:3.4 /bin/sh -c "apk update && apk add dropbear-ssh && ssh -T git@github.com"
fetch http://dl-cdn.alpinelinux.org/alpine/v3.4/main/x86_64/APKINDEX.tar.gz
fetch http://dl-cdn.alpinelinux.org/alpine/v3.4/community/x86_64/APKINDEX.tar.gz
v3.4.3-7-g2f47d74 [http://dl-cdn.alpinelinux.org/alpine/v3.4/main]
v3.4.2-11-g9b41a63 [http://dl-cdn.alpinelinux.org/alpine/v3.4/community]
OK: 5968 distinct packages available
(1/2) Installing dropbear (2016.74-r0)
(2/2) Installing dropbear-ssh (2016.74-r0)
Executing busybox-1.24.2-r9.trigger
OK: 5 MiB in 13 packages

Host 'github.com' is not in the trusted hosts file.
(ssh-rsa fingerprint md5 16:27:ac:a5:76:28:2d:36:63:1b:56:4d:eb:df:a6:48)
Do you want to continue connecting? (y/n) yes
ssh: Failed to connect to agent

ssh: Connection to git@github.com:22 exited: No auth methods could be used.

Information

https://forums.docker.com/t/can-we-re-use-the-osx-ssh-agent-socket-in-a-container/8152

It would be great if Docker for Mac would forward osx ssh-agent's socket into VM, just like how it does with docker.sock. Generic solution for socket would also help a lot.

[samoht]

Have you checked https://github.com/avsm/docker-ssh-agent-forward ? It seems to do what you want.

[mariusgrigaitis]

Solution that you provided works, but it's not convenient / experimental

• It requires to append additional parameters on every docker run command which complicates stuff like running containers through docker-compose
• It runs separate ssh-agent and shares your local key to that agent. What if your key is encrypted?
• We want to make our scripts / files as much platform-independent as possible and this complicates things

Would be a lot better if docker for mac provided native support for ssh agent forwarding or socket forwarding in general as mentioned in #483

P.S. currently docker.sock is forwarded, it's probably not that hard to achieve same solution for other sockets too.

[trinitronx]

I've run into problems trying to support the ssh-agent SSH_AUTH_SOCK specifically with "Docker for Mac".

The problem appears to be due to osxfuse not supporting socket connections across the OS X Host / Docker Container boundary.

As the documentation states:

Socket files and named pipes only transmit between containers and between OS X processes – no transmission across the hypervisor is supported, yet.

So I can mount in the ssh-agent socket, it appears inside the container fine. However, accessing it via ssh-add -l always results in: "Could not open a connection to your authentication agent."

For example, I can find my SSH_AUTH_SOCK file on the OSX host (e.g.: /private/tmp/com.apple.launchd.abCDEfghiJ/Listeners)
Then, I can run a container using "Docker for Mac" by passing in the volume mount & environment variable arguments like: -v /private/tmp/com.apple.launchd.abCDEfghiJ:/ssh-agent -e SSH_AUTH_SOCK=/ssh-agent/Listeners

Inside the container, the socket appears as a socket owned by root. I'm running as root in the container & have rw access. However, ssh-add cannot communicate over the socket.

[root@62b57964834a ansible]# env | grep -i ssh
SSH_AUTH_SOCK=/ssh-agent/Listeners
[root@62b57964834a ansible]# ls -l $SSH_AUTH_SOCK
srw-rw-rw- 1 root root 0 Feb  1 17:57 /ssh-agent/Listeners
[root@62b57964834a]# whoami
root
[root@62b57964834a]# ssh-add -l
Could not open a connection to your authentication agent.

[samoht]

@mariusgrigaitis @trinitronx I was maybe not very clear, but yes support for ssh agent forwarder is planned on our roadmap and is indeed very related to #483. I was just pointing out a possible workaround which works today while we implement the feature.

[JoeNyland]

Ugh, I've just been caught out by this limitation of Docker for Mac 😞 I'm surprised to see that this has still not been resolved 👎

[andytson]

I'm not surprised at all. It's a complex issue that goes beyond what normal VM environments can support. I'd really like to have this feature, but I'm not going to assume an easy fix solution is possible.

[evgenysalnikov]

• up

[isodude]

The clean way of working around this is to have a docker being responsible for the ssh-agent.

• Start a docker with a volume /agent and entrypoint ssh-agent
• Use docker cp to copy the private key to the container
• ssh-add the key and remove it.
• Use --volume-from instead of mounting the ssh-socket from localhost.

If you do it as a bash function the magic stuff can happen in the shadows.

[Mange]

That forces the user to unlock the key in that Docker container, bypassing all local customization of the agent, password entry, etc. Den fre 21 apr. 2017 09:46Josef Johansson <notifications@github.com> skrev:

…

The clean way of working around this is to have a docker being responsible for the ssh-agent. - Start a docker with a volume /agent and entrypoint ssh-agent - Use docker cp to copy the private key to the container - ssh-add the key and remove it. - Use --volume-from instead of mounting the ssh-socket from localhost. If you do it as a bash function the magic stuff can happen in the shadows. — You are receiving this because you are subscribed to this thread. Reply to this email directly, view it on GitHub <#410 (comment)>, or mute the thread <https://github.com/notifications/unsubscribe-auth/AAAGPxeJ9C0joxfp1OancPQF2Ok4KpcQks5ryF7MgaJpZM4JrttX> .

[isodude]

True, but the alternative is worse?

Anyway there not that much you can customize in the local ssh-agent, and the same customization is possible to add to the docker ssh-agent that way. A plus is that it is consistent across platforms. You can also have different ssh-agents for different purposes.

[andytson]

Presumably a workaround that doesn't lose local customisations would be to:

• Start a docker ssh server container with the necessary volume
• Use --volume-from instead of mounting the ssh-socket from localhost.
• SSH with agent-forwarding to the docker ssh server container

That way you use your local ssh-agent

[hilt86]

copying / mounting a private key won't work if you store your ssh key on a hardware token such as yubikey.

[lox]

Copying / mounting private keys is not a good idea. If you are going to, @andytson's approach is the best of the bunch.

[cecemel]

at @andytson, since your solution seems to have consensus on its viability, would you mind elaborate a little bit on its steps for the less proficient docker users? Thanks!

[jesselang]

@cecemel, I've been using https://github.com/uber-common/docker-ssh-agent-forward which seems to implement @andytson's solution. It provides an sshd container that you can forward the Darwin agent do (ssh -A ...), and exposes the agent as a socket in a docker volume that the target container can then use. A crude diagram:

+--------+        +--------+             +--------+             +-----------+
|        |  SSH   |        | Filesystem  | Volume | Filesystem  | Target    |
| MacOSX | +----> |  sshd  | +---------> |  With  | +---------> | Container |
|        |        |        |             | Socket |             |           |
+--------+        +--------+             +--------+             +-----------+

There's also a solution using pure netcat, but I couldn't get it to work reliably for whatever reason.

[tamsky]

@matttrach asked:

How would you modify a container that you do not control?

I'm not sure what you mean here by "container". Did you perhaps mean 'image"? You should be able to control your containers and you should be able modify and build images from Dockerfile.

Any RUN commands written with the assumption of a mounted ssh-agent would fail, right?

Yes; prior to buildkit supporting RUN-time volume mounts/secrets... "a mounted ssh-agent" was not possible.

Each Dockerfile must add support for it, hence the requirement for the top line comment # syntax=docker/dockerfile:1.0-experimental in each Dockerfile.

[treyd]

I can confirm the 2.1.4.0 edge version works with the config described in this post (note, because it threw me for a loop - these mounted volumes have to be exactly what is described): #410 (comment)

Will this be the final implementation for this feature? If so, does this mean this will only work in this fashion on a Mac, and we would have to use a different method for Linux or Windows?

[jhg03a]

SSH_AUTH_SOCK support has existed without a problem on Linux for some time.

[jvcdk]

I am probably missing something, sorry... but I can get @guillaumerose's example working where he uses alpine:3.4 as base. But I am working on an image based on Debian (Stretch), and here it does not work.

Do I need to install something specific? I tried to search for vpnkit-bridge but without any luck.

[treyd]

@jvcdk on debian you'll need to install openssh-client in the container. i was able to get this to work while running 2.1.5.0 edge:

docker run -it -v /run/host-services/ssh-auth.sock:/run/host-services/ssh-auth.sock -e SSH_AUTH_SOCK="/run/host-services/ssh-auth.sock" --rm debian:stretch /bin/sh -c "apt-get update && apt-get -y install openssh-client && ssh -T git@github.com"

[jvcdk]

Thank you, @treyd, for your quick answer.

I have been testing it a bit this morning and found out that it is because I have a USER statement in my docker file – i.e. I am running as non-root in the container. @andytson mentions it above but I found out there is an additional catch: You cannot use sudo either.

Edit:
Work-around seem to be sudo chmod 666 /run/host-services/ssh-auth.sock

Thank you for your help :)

[ajardin]

Thank you, @treyd, for your quick answer.

I have been testing it a bit this morning and found out that it is because I have a USER statement in my docker file – i.e. I am running as non-root in the container. @andytson mentions it above but I found out there is an additional catch: You cannot use sudo either.

Edit:
Work-around seem to be sudo chmod 666 /run/host-services/ssh-auth.sock

Thank you for your help :)

Yep, I had the same issue a couple of weeks ago. I've fixed it by creating the mount point and changing the permissions within my Dockerfile. If it can help you, here are:

• the related commit.
• the associated docker-compose.yml service.

[vcajes]

Hey guys, can anybody help me out here? I am testing this on docker edge v2.1.6.0.

First, I just create a new agent with a new socket on OSX and give full permissions:

eval "$(ssh-agent -a ~/.ssh/ssh-auth.sock)"
chmod 666 ~/.ssh/ssh-auth.sock

docker run -it -v ~/.ssh/ssh-auth.sock:/run/host-services/ssh-auth.sock -e SSH_AUTH_SOCK="/run/host-services/ssh-auth.sock" --rm alpine:3.4 /bin/sh -c "apk update && apk add dropbear-ssh && ssh -T git@gitlab.com"

However, I am getting the following error: ssh: Failed to connect to agent

Then, if I try to use openssh-client:

docker run -it -v ~/.ssh/ssh-auth.sock:/run/host-services/ssh-auth.sock -e SSH_AUTH_SOCK="/run/host-services/ssh-auth.sock" --rm alpine:3.4 /bin/sh -c "apk update && apk add openssh-client && ssh-add -l && ssh -T git@gitlab.com"

I get the following error: Error connecting to agent: Connection refused

On the host, ls -lhatr ~/.ssh/ssh-auth.sock gives me:
srwxrwxrwx 1 redacted staff 0 Nov 22 11:24 /Users/redacted/.ssh/ssh-auth.sock

Additionally, I tried with debian as well as, but no luck:

docker run -it -v ~/.ssh/ssh-auth.sock:/run/host-services/ssh-auth.sock -e SSH_AUTH_SOCK="/run/host-services/ssh-auth.sock" --rm debian:stretch /bin/sh -c "apt-get update && apt-get -y install openssh-client && ssh-add -l && ssh -T git@gitlab.com"

Error connecting to agent: Connection refused

Is there something am I doing wrong? I would really appreciate some help. Thanks! @andytson

[jvcdk]

@vcajes : The chmod command should be done within the docker container, not on the host.

[vcajes]

@jvcdk I have tested both approaches, with and without the chmod, on the host and/or on the container, still not luck. Getting the same errors as above.

On the host everything works fine: ssh-add -l is showing my keys and echo $SSH_AUTH_SOCK gives the right path to the socket I am trying to mount ~/.ssh/ssh-auth.sock

[treyd]

@vcajes Your volume parameter needs to be exactly as above, i.e. -v /run/host-services/ssh-auth.sock:/run/host-services/ssh-auth.sock

You're not actually pointing at a socket on your host system, you're pointing at some other special machinery in Docker Desktop for Mac that enables specifically the SSH agent forwarding.

[lukasvice]

@vcajes actually you need to use exactly this mount:
-v /run/host-services/ssh-auth.sock:/run/host-services/ssh-auth.sock

[vcajes]

@treyd wow, it was just that. Thanks guys. Working now! :)

[cbrinker]

You can also extend the technique like this to get access to the docker socket from within a docker container:

-e DOCKER_HOST="unix:///run/guest-services/docker.sock"
--volume /run/guest-services/docker.sock:/run/guest-services/docker.sock

[fnkr]

I've made a solution for my employer which can be installed via Homebrew and runs as a service: punktDe/docker-mac-ssh-auth-sock. After install -v $SSH_AUTH_SOCK:/foo works on macOS like it does on Linux.

[jhg03a]

Workarounds hopefully are no longer necessary with edge builds (2.1.4.0+) and will be fixed for good once those get merged back to a stable release.

[mat007]

This will indeed be available in the upcoming (next week) Stable 2.2.0.0 release.

[endemics]

A little caveat:
I had trouble getting the feature that @guillaumerose implemented to work on one machine while it was working on another.
I found out that it was related to the fact that on the machine that wasn't working I was starting a new ssh-agent in the terminal where I was running the docker command (so I could control the keys added to the keychain for that particular session) and was expecting the value of SSH_AUTH_SOCK set in the shell of that terminal to be picked up.
Exporting the keys globaly and not starting a new ssh-agent ssh-agent worked so I suspect the value of SSH_AUTH_SOCK picked up is the one available in the environment of the Docker Desktop command.

[Apollorion]

On 2.2.0.0, Im still getting the result OP got in his example:

docker run -it -v ${SSH_AUTH_SOCK}:${SSH_AUTH_SOCK} -e SSH_AUTH_SOCK="${SSH_AUTH_SOCK}" --rm alpine:3.4 /bin/sh -c "apk update && apk add dropbear-ssh && ssh -T git@github.com"

returns:

Host 'github.com' is not in the trusted hosts file.
(ssh-rsa fingerprint md5 16:27:ac:a5:76:28:2d:36:63:1b:56:4d:eb:df:a6:48)
Do you want to continue connecting? (y/n) y
ssh: Failed to connect to agent

ssh: Connection to git@github.com:22 exited: No auth methods could be used.

Edit, found my problem above. I guess you dont mount ${SSH_AUTH_SOCK} but instead -v /run/host-services/ssh-auth.sock:/run/host-services/ssh-auth.sock. Sorry for the unnecessary notification!

[endemics]

Hi, I can also confirm that the newest stable (2.2.0.0) work as intended when using the "magic" mounting path -v /run/host-services/ssh-auth.sock:/run/host-services/ssh-auth.sock.

Thanks so much @guillaumerose, I guess this issue might finally be closed after 4 years 🎉

[fnkr]

I'm not so sure this issue is fixed. Title and description explicitly mention $SSH_AUTH_SOCK and -v ${SSH_AUTH_SOCK}:${SSH_AUTH_SOCK}. In our team Linux and macOS people both share the same docker-compose.yaml files. Unfortunately, this solution won't work in both cases, or at least I don't know how it could work without one part of the team being required modify or override every docker-compose.yaml. Maybe we could create another hack, like symlinking $SSH_AUTH_SOCK to /run/host-services/ssh-auth.sock in the Docker VM, but we we're hoping this issue would provide a solution that works out of the box and make hacks unnecessary.

[guillaumerose]

What about using a .env file and add SSH_AUTH_SOCK=/run/host-services/ssh-auth.sock ?
Let's close this ticket. Please open a new one for improvements.

To conclude this ticket, in your docker run command, add this flags to get ssh agent forwarded:
-v /run/host-services/ssh-auth.sock:/run/host-services/ssh-auth.sock -e SSH_AUTH_SOCK="/run/host-services/ssh-auth.sock"

[docker-robott]

Closed issues are locked after 30 days of inactivity.
This helps our team focus on active issues.

If you have found a problem that seems similar to this, please open a new issue.

Send feedback to Docker Community Slack channels #docker-for-mac or #docker-for-windows.
/lifecycle locked