Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

$SSH_AUTH_SOCK is not being forwarded to docker #410

Closed
mariusgrigaitis opened this issue Aug 24, 2016 · 80 comments
Closed

$SSH_AUTH_SOCK is not being forwarded to docker #410

mariusgrigaitis opened this issue Aug 24, 2016 · 80 comments

Comments

@mariusgrigaitis
Copy link

@mariusgrigaitis mariusgrigaitis commented Aug 24, 2016

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
Copy link
Contributor

@samoht samoht commented Jan 31, 2017

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

@mariusgrigaitis
Copy link
Author

@mariusgrigaitis mariusgrigaitis commented Feb 1, 2017

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
Copy link

@trinitronx trinitronx commented Feb 1, 2017

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
Copy link
Contributor

@samoht samoht commented Feb 1, 2017

@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
Copy link

@JoeNyland JoeNyland commented Feb 5, 2017

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
Copy link

@andytson andytson commented Feb 5, 2017

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
Copy link

@evgenysalnikov evgenysalnikov commented Apr 19, 2017

  • up

@isodude
Copy link

@isodude isodude commented Apr 21, 2017

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
Copy link

@Mange Mange commented Apr 21, 2017

@isodude
Copy link

@isodude isodude commented Apr 21, 2017

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
Copy link

@andytson andytson commented Apr 21, 2017

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
Copy link

@hilt86 hilt86 commented Jun 2, 2017

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

@lox
Copy link

@lox lox commented Jun 2, 2017

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

@cecemel
Copy link

@cecemel cecemel commented Nov 22, 2017

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
Copy link

@jesselang jesselang commented Nov 22, 2017

@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
Copy link

@tamsky tamsky commented Nov 1, 2019

@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
Copy link

@treyd treyd commented Nov 4, 2019

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
Copy link

@jhg03a jhg03a commented Nov 7, 2019

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

@jvcdk
Copy link

@jvcdk jvcdk commented Nov 12, 2019

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
Copy link

@treyd treyd commented Nov 12, 2019

@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
Copy link

@jvcdk jvcdk commented Nov 13, 2019

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
Copy link

@ajardin ajardin commented Nov 13, 2019

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:

@vcajes
Copy link

@vcajes vcajes commented Nov 22, 2019

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
Copy link

@jvcdk jvcdk commented Nov 22, 2019

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

@vcajes
Copy link

@vcajes vcajes commented Nov 22, 2019

@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
Copy link

@treyd treyd commented Nov 22, 2019

@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
Copy link

@LukasVice LukasVice commented Nov 22, 2019

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

@vcajes
Copy link

@vcajes vcajes commented Nov 22, 2019

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

@cbrinker
Copy link

@cbrinker cbrinker commented Nov 22, 2019

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
Copy link

@fnkr fnkr commented Jan 8, 2020

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
Copy link

@jhg03a jhg03a commented Jan 9, 2020

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
Copy link
Member

@mat007 mat007 commented Jan 10, 2020

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

@endemics
Copy link

@endemics endemics commented Jan 21, 2020

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
Copy link

@Apollorion Apollorion commented Jan 21, 2020

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.

Screen Shot 2020-01-21 at 5 27 27 PM

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
Copy link

@endemics endemics commented Jan 21, 2020

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
Copy link

@fnkr fnkr commented Jan 22, 2020

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
Copy link
Contributor

@guillaumerose guillaumerose commented Jan 22, 2020

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 docker locked as resolved and limited conversation to collaborators Jan 22, 2020
@docker-desktop-robot
Copy link
Collaborator

@docker-desktop-robot docker-desktop-robot commented Jun 19, 2020

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

Sign up for free to subscribe to this conversation on GitHub. Already have an account? Sign in.
Projects
None yet
Linked pull requests

Successfully merging a pull request may close this issue.

None yet