You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
Cool people don’t use Git with passwords, they use it with a SSH key pair instead. For those people, it should be possible to use Git commands that require a SSH key from within the container.
Assuming most people using a SSH key pair are also using a SSH agent, all we would have to do is to forward the agent’s socket into the container:
$ docker run -v $SSH_AUTH_SOCK:/ssh-auth.sock -e SSH_AUTH_SOCK=/ssh-auth.sock [other docker run options and arguments…]
This works fine at least on GNU/Linux. Unfortunately it doesn’t work on macOS, where a special workaround exists instead:
$ docker run -v /run/host-services/ssh-auth.sock:/run/host-services/ssh-auth.sock -e SSH_AUTH_SOCK=/run/host-services/ssh-auth.sock [other docker run options and arguments…]
A simpler option is to just bind the user’s ~/.ssh directory, but this will only work for simple setups where an agent is not necessary – and many users may not like the idea of exposing their SSH private key to the ODK container, not matter how much they trust the ODK…
The text was updated successfully, but these errors were encountered:
This commit:
* binds the SSH agent socket (as found in $SSH_AUTH_SOCK) from the host
to a predictable location inside the container;
* sets the SSH_AUTH_SOCK variable in the container to point to said
predictable location.
This allows processes running inside the container to communicate with
the host's SSH agent and therefore to use the user's SSH keys without
having to expose the keys directly to the container.
closes#852
Cool people don’t use Git with passwords, they use it with a SSH key pair instead. For those people, it should be possible to use Git commands that require a SSH key from within the container.
Assuming most people using a SSH key pair are also using a SSH agent, all we would have to do is to forward the agent’s socket into the container:
This works fine at least on GNU/Linux. Unfortunately it doesn’t work on macOS, where a special workaround exists instead:
A simpler option is to just bind the user’s
~/.ssh
directory, but this will only work for simple setups where an agent is not necessary – and many users may not like the idea of exposing their SSH private key to the ODK container, not matter how much they trust the ODK…The text was updated successfully, but these errors were encountered: