Protect what matters – even after you're gone. Make a plan for your digital legacy today.
Forum Discussion
Ryan_Parman
4 years agoDedicated Contributor
[Feature Request] Using 1P SSH from inside a local Docker container
My team and I regularly use Docker for lightweight local environments that are pre-configured with things we need to develop that project. (It helps avoid things like "works on my machine".) If I need to work on a Terraform module, I can launch the Docker environment that has all the tools I need pre-installed and ready-to-go, and I can make my changes, run tests, and perform all sorts of general software development tasks. When I'm done, I press Ctrl+D.
We can easily read specific environment variables from the host environment and pass them into the Docker environment (e.g., AWS credentials, Terraform variables), and for Git, we can mount the local SSH directory into the container in read-only mode so that we can fetch and push (-v ~/.ssh:/root/.ssh:ro) to GitHub Enterprise.
Herein lies the problem with migrating the SSH keys into 1Password and not having them on-disk. There's nothing to mount, and 1Password only runs on the host. The low-fi solution is to keep my SSH keys on-disk for Docker, while copying them into 1P for use with that SSH agent, but then what's the point to using 1Password SSH?
A higher-fi solution (since this is desktop-use Docker; not for deployment) would be the ability to mount a unix socket from the host into the Docker container, and have some kind of tiny agent built for Linux (namely Alpine Linux) that can run and facilitate whatever signals need to be sent so that when I run git pull inside the Docker container, this agent sends a signal to 1Password on the host asking for authentication.
1Password Version: 80600043 (beta channel)
Extension Version: N/A
OS Version: macOS 12.3β
39 Replies
- Jack_P_1P
1Password Team
Hi @jpgrusling:
We're continuing to investigate this SSH issue, so we'll be sure to let you know as soon as we know more. Thanks for sharing your logs!
Jack
- Anonymous
- Jack_P_1P
1Password Team
Hi @jpgrusling:
I took a look for your message, and it looks like my colleague Dayton was able to confirm that we received the logs early in November and replied to your message. Let me know if you didn't receive it, and I can take a closer look.
Jack
- Anonymous
floris_1P I did follow up with the logs as requested. I haven't heard back yet so I just want to make sure the logs were forwarded to you.
- Anonymous
Ok so forget that last comment, actually open Docker from terminal using open -a Docker works, rather than opening from Spotlight seach. So indeed this env variable needs to be set before docker starts more info here https://github.com/docker/for-mac/issues/6541
- Anonymous
floris_1P I have tried this solution you proposed but somehow still seems to be using the system ssh-agent rather than the 1password unix socket.
What makes you think that adding the env variable SSH_AUTH_SOCK will change behaviour from the docker "hypervisor" when mounting the /run/host-services/ssh-auth.sock ? Surely this variable is local to that and outside of the magic that happens with the
/run/host-services/ssh-auth.sockmountpoint ? - floris_1P
1Password Team
@jpgrusling The solution in this thread is only intended for Docker for Mac. Support for Docker for Linux is something we're looking to improve on. What would help us get there is if you could provide us with your SSH agent diagnostics, as described here.
- Anonymous
floris_1P I have been able to follow your instructions to get a similar setup working on macOS. However, when I try to repeat this on a Ubuntu machine, I am unsuccessful. It appears to be getting hung up on being able to prompt for system credentials. I can use the SSH agent outside of the container, but inside it fails with the error sign_and_send_pubkey indicating agent refused operation. Please let me know if you have any ideas.
- floris_1P
1Password Team
Great!
- Anonymous
floris_1P Yes, both what you suggested 3 hours ago and your most recent message work. More surprised that it does because I had previously not been able to talk to 1Password when using macOS's default ssh-agent socket. Prior to integrating with 1Password for ssh-agent support, we'd been passing macOS's agent using the same socket. In initial testing, however,
/run/host_services/ssh-auth.sockhad not worked. Glad that it does now, though, as it helps us avoid having to tweak docker-compose.yml files for our development team.