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

Open
mariusgrigaitis opened this Issue Aug 24, 2016 · 27 comments

Comments

Projects
None yet
@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

This comment has been minimized.

Show comment
Hide comment
@samoht

samoht Jan 31, 2017

Contributor

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

Contributor

samoht commented Jan 31, 2017

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

@mariusgrigaitis

This comment has been minimized.

Show comment
Hide comment
@mariusgrigaitis

mariusgrigaitis 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.

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

This comment has been minimized.

Show comment
Hide comment
@trinitronx

trinitronx 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.

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

This comment has been minimized.

Show comment
Hide comment
@samoht

samoht Feb 1, 2017

Contributor

@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.

Contributor

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

This comment has been minimized.

Show comment
Hide comment
@JoeNyland

JoeNyland 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 👎

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

This comment has been minimized.

Show comment
Hide comment
@andytson

andytson 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.

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

This comment has been minimized.

Show comment
Hide comment
@evgenysalnikov

evgenysalnikov commented Apr 19, 2017

  • up
@isodude

This comment has been minimized.

Show comment
Hide comment
@isodude

isodude 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.

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

This comment has been minimized.

Show comment
Hide comment
@Mange

Mange Apr 21, 2017

Mange commented Apr 21, 2017

@isodude

This comment has been minimized.

Show comment
Hide comment
@isodude

isodude 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.

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

This comment has been minimized.

Show comment
Hide comment
@andytson

andytson 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

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

This comment has been minimized.

Show comment
Hide comment
@hilt86

hilt86 Jun 2, 2017

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

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

This comment has been minimized.

Show comment
Hide comment
@lox

lox 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.

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

This comment has been minimized.

Show comment
Hide comment
@cecemel

cecemel 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!

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

This comment has been minimized.

Show comment
Hide comment
@jesselang

jesselang 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.

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.

@qliam

This comment has been minimized.

Show comment
Hide comment
@qliam

qliam Nov 28, 2017

If you want you cant mount a volume from ~/.ssh to /root/.ssh (you can replace root with your user)

qliam commented Nov 28, 2017

If you want you cant mount a volume from ~/.ssh to /root/.ssh (you can replace root with your user)

@lox

This comment has been minimized.

Show comment
Hide comment
@lox

lox Nov 28, 2017

If you want you cant mount a volume from ~/.ssh to /root/.ssh (you can replace root with your user)

Except it exposes all your keys to everything running in the container.

lox commented Nov 28, 2017

If you want you cant mount a volume from ~/.ssh to /root/.ssh (you can replace root with your user)

Except it exposes all your keys to everything running in the container.

@danvaida

This comment has been minimized.

Show comment
Hide comment
@danvaida

danvaida Dec 21, 2017

@mariusgrigaitis for the GitHub cloning part, a workaround would be to use a personal access token instead, till this will be solved. Hope this helps :)

danvaida commented Dec 21, 2017

@mariusgrigaitis for the GitHub cloning part, a workaround would be to use a personal access token instead, till this will be solved. Hope this helps :)

@glend

This comment has been minimized.

Show comment
Hide comment
@glend

glend Dec 27, 2017

Except it exposes all your keys to everything running in the container.

Not a big deal in development environments.

glend commented Dec 27, 2017

Except it exposes all your keys to everything running in the container.

Not a big deal in development environments.

@joeyhub

This comment has been minimized.

Show comment
Hide comment
@joeyhub

joeyhub Jan 24, 2018

The example in your original issue works for me on Linux with the exception that in the container I make the agent simply /ssh-agent to avoid anything strange from creating non-existent folders plus to also simplify things.

Your error report lacks some key details. What happens when you try to ls on the key in docker, cat it, echo the variable to make sure it's good, etc. Have you tested that on another hosts, checked mounts, etc? I might be wrong but I assume both docker.sock and the agent file are the same thing aren't they? A special file pointing to a unix socket? If that is indeed the case and it works for docker.sock perhaps Mac has a different security set up for SSH agent sockets. For me on Linux it looks like they are all sockets and there's no immediately obvious reason why one should work and not another beyond permissions on the host. Are you also sure that agent forwarding is working at all on your host? SSH might be working in an outer shell if ssh it taking your private key directly.

There is some good advice here: https://gist.github.com/d11wtq/8699521

In the long run using the default auth sock is a problematic. If you do a normal docker run or docker-compose run it'll be fine to mount it. You have to keep in mind if what you want to do is something you log in, run, wait for it to finish or if it's something you fire and forget. Basically you're going to have a problem with anything unattended or that you want to initiate through an interface other than SSH.

If instead you do something that daemonises containers and then close the session you started them in then your ssh sock will disappear and those containers will no longer be able to connect to SSH using your keys.

Mounting personal keys to a docker container is a particularly extreme risk and almost defeats the entire point. It's like storing your raw meat in the lion cage. Agent forwarding carries its own risks but is a mitigation of the risk introduced by exposing your keys.

In some cases keys wont be on the machine in question. You'll ssh into a docker host using agent forwarding and in this case you really don't want ssh agent to have persistence. Given that it's dependent on your originating connection, then it shouldn't be possible to make it persistent.

These problems aren't simply docker issues but fundamental to the way SSH key security works.

My recommendation is one of the following:

  1. Create separate keys for development, builds, deploy, etc rather than having personal keys used. This wont always be perfect but at least you're not at risk of exposing your own personal keys.
  2. Avoid the need for having to ssh into things altogether at all in docker. There are any number of approaches to this (is authentication for read access even needed in a secure network for example). Mirroring such that the problem only exists in one place is another approach (one container managers fetching everything that needs credentials).

If it's genuinely a problem maybe you can do something nasty like you should be able to have a service to translate a domain sock to a TCP endpoint and vice versa. It's not that hard except you'll be publishing your SSH agent over an unsecure port and you'll also need some processes both hostside and container side to manage that.

joeyhub commented Jan 24, 2018

The example in your original issue works for me on Linux with the exception that in the container I make the agent simply /ssh-agent to avoid anything strange from creating non-existent folders plus to also simplify things.

Your error report lacks some key details. What happens when you try to ls on the key in docker, cat it, echo the variable to make sure it's good, etc. Have you tested that on another hosts, checked mounts, etc? I might be wrong but I assume both docker.sock and the agent file are the same thing aren't they? A special file pointing to a unix socket? If that is indeed the case and it works for docker.sock perhaps Mac has a different security set up for SSH agent sockets. For me on Linux it looks like they are all sockets and there's no immediately obvious reason why one should work and not another beyond permissions on the host. Are you also sure that agent forwarding is working at all on your host? SSH might be working in an outer shell if ssh it taking your private key directly.

There is some good advice here: https://gist.github.com/d11wtq/8699521

In the long run using the default auth sock is a problematic. If you do a normal docker run or docker-compose run it'll be fine to mount it. You have to keep in mind if what you want to do is something you log in, run, wait for it to finish or if it's something you fire and forget. Basically you're going to have a problem with anything unattended or that you want to initiate through an interface other than SSH.

If instead you do something that daemonises containers and then close the session you started them in then your ssh sock will disappear and those containers will no longer be able to connect to SSH using your keys.

Mounting personal keys to a docker container is a particularly extreme risk and almost defeats the entire point. It's like storing your raw meat in the lion cage. Agent forwarding carries its own risks but is a mitigation of the risk introduced by exposing your keys.

In some cases keys wont be on the machine in question. You'll ssh into a docker host using agent forwarding and in this case you really don't want ssh agent to have persistence. Given that it's dependent on your originating connection, then it shouldn't be possible to make it persistent.

These problems aren't simply docker issues but fundamental to the way SSH key security works.

My recommendation is one of the following:

  1. Create separate keys for development, builds, deploy, etc rather than having personal keys used. This wont always be perfect but at least you're not at risk of exposing your own personal keys.
  2. Avoid the need for having to ssh into things altogether at all in docker. There are any number of approaches to this (is authentication for read access even needed in a secure network for example). Mirroring such that the problem only exists in one place is another approach (one container managers fetching everything that needs credentials).

If it's genuinely a problem maybe you can do something nasty like you should be able to have a service to translate a domain sock to a TCP endpoint and vice versa. It's not that hard except you'll be publishing your SSH agent over an unsecure port and you'll also need some processes both hostside and container side to manage that.

@udondan

This comment has been minimized.

Show comment
Hide comment
@udondan

udondan Jan 24, 2018

While those in general are good recommendations, they don't fit every use case. People are using Docker for all sorts of things. Here's a good example why a working ssh socket is required. Silo is a wrapper around Ansible which connects though ssh. Also, this problem is not limited to the ssh socket. It's a general problem with usix sockets, see #483.

I think this issue can be closed, as it already is covered in #483.

udondan commented Jan 24, 2018

While those in general are good recommendations, they don't fit every use case. People are using Docker for all sorts of things. Here's a good example why a working ssh socket is required. Silo is a wrapper around Ansible which connects though ssh. Also, this problem is not limited to the ssh socket. It's a general problem with usix sockets, see #483.

I think this issue can be closed, as it already is covered in #483.

@justinbarrick

This comment has been minimized.

Show comment
Hide comment
@justinbarrick

justinbarrick May 7, 2018

Any updates on this? This is hurting our Docker for Mac users.

justinbarrick commented May 7, 2018

Any updates on this? This is hurting our Docker for Mac users.

@YRM64

This comment has been minimized.

Show comment
Hide comment
@YRM64

YRM64 May 8, 2018

At the time Mariusgrigaitis posted, part of the dilemma stemmed from the fact that folks were trying to mount sockets like we mount files. Stackoverflow (https://stackoverflow.com/questions/47334784/ssh-agent-forwarding-to-docker-alpine-container-from-Mac-Oslo) has a great article on sharing sockets between Mac through the hypervisor. Many developers have been successful with using docker-ssh-agent-forward, however, it was an experimental process, and it was recommended for those who were attempting to do so, contact anil@recoil.org for immediate assistance. There's also a README.md available on Github.

There's yet another option to run ssh-agent in your container, and access it through your MacOs.
The solution: docker-ssh-agent. How successful that has been for developers, tap me back at this posting and let me know of your experiences, whether they have been positive or negative.

YRM64 commented May 8, 2018

At the time Mariusgrigaitis posted, part of the dilemma stemmed from the fact that folks were trying to mount sockets like we mount files. Stackoverflow (https://stackoverflow.com/questions/47334784/ssh-agent-forwarding-to-docker-alpine-container-from-Mac-Oslo) has a great article on sharing sockets between Mac through the hypervisor. Many developers have been successful with using docker-ssh-agent-forward, however, it was an experimental process, and it was recommended for those who were attempting to do so, contact anil@recoil.org for immediate assistance. There's also a README.md available on Github.

There's yet another option to run ssh-agent in your container, and access it through your MacOs.
The solution: docker-ssh-agent. How successful that has been for developers, tap me back at this posting and let me know of your experiences, whether they have been positive or negative.

@tamsky

This comment has been minimized.

Show comment
Hide comment
@tamsky

tamsky Aug 4, 2018

There's yet another option to run ssh-agent in your container, and access it through your MacOs.

Running ssh-agent "in your container" (read: "on a Linux kernel") means
we can no longer use ssh-add -K which retrieves the per-ssh-key passphrase
from the OSX Keychain when decrypt/add-ing keys into the agent.

tamsky commented Aug 4, 2018

There's yet another option to run ssh-agent in your container, and access it through your MacOs.

Running ssh-agent "in your container" (read: "on a Linux kernel") means
we can no longer use ssh-add -K which retrieves the per-ssh-key passphrase
from the OSX Keychain when decrypt/add-ing keys into the agent.

@mariusgrigaitis

This comment has been minimized.

Show comment
Hide comment
@mariusgrigaitis

mariusgrigaitis Aug 30, 2018

I've created another dirty solution to work-around this issue. See https://github.com/mariusgrigaitis/docker-mac-ssh-auth-sock

It's using undocumented features, etc. However it allows original example to work. No need to pass additional arguments, no need to use different names for SSH_AUTH_SOCK, etc. Works the same as in Linux host ;). It also does not run additional ssh, ssh-agents

Let me know what you think.

mariusgrigaitis commented Aug 30, 2018

I've created another dirty solution to work-around this issue. See https://github.com/mariusgrigaitis/docker-mac-ssh-auth-sock

It's using undocumented features, etc. However it allows original example to work. No need to pass additional arguments, no need to use different names for SSH_AUTH_SOCK, etc. Works the same as in Linux host ;). It also does not run additional ssh, ssh-agents

Let me know what you think.

@ameesme

This comment has been minimized.

Show comment
Hide comment
@ameesme

ameesme Sep 20, 2018

@mariusgrigaitis Solution works perfectly in a run-context. Wish we'd have the ability to temporarily mount volumes in a build-context, which isn't possible.

ameesme commented Sep 20, 2018

@mariusgrigaitis Solution works perfectly in a run-context. Wish we'd have the ability to temporarily mount volumes in a build-context, which isn't possible.

@mariusgrigaitis

This comment has been minimized.

Show comment
Hide comment
@mariusgrigaitis

mariusgrigaitis Sep 20, 2018

Yes it's different kind of feature, hopefully will be solved by buildkit

mariusgrigaitis commented Sep 20, 2018

Yes it's different kind of feature, hopefully will be solved by buildkit

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment