-
Notifications
You must be signed in to change notification settings - Fork 27
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
On OS X user always has to enter passphrase for protected SSH key #2
Comments
ssh-add does not help ? |
We're doing an ssh-add and that's where the passphrase is requested. Since the Silo container is not persistent the authentication-agent won't know about the previously added key when the container is started again. Therefore you need to enter the passphrase every time ansible/ansible-playbook is invoked. |
Using the docker-ssh-agent-forward work around has been working pretty well for me esp. since I'm using gpg-agent with ssh-support mode. Once I've setup the forward, I use this
|
@woneill Using your function since a while and pinata works reliably for me and my team. May I use your function as is to include in the next Silo release? Or if you like, send a PR so you're credited appropriately for the contribution. |
Awesome! Feel free to use the function as-is since I likely found it elsewhere and wouldn't want to claim credit inappropriately. I'm interested in seeing how you suggest new users setup |
Thanks @woneill, documentation for this is pending but I just added the function. BTW, I am using a fork from Uber as the original is not working for me: https://github.com/uber-common/docker-ssh-agent-forward |
#2: Implements pinata forwarded keys for MacOS
2.2.0 just got released with your function. Thanks again. 😸 |
Silo forwards the SSH socket into the container. Docker for Mac does currently not support mounting sockets into a container. Therefore the users ssh key (which gets mounted) is used. If this key is protected by a passphrase the user will always have to unlock the key on every silo call.
The original problem is described here:
There is an experimental workaround we might want to look into, as it seems the problem is not going to be addressed anytime soon on Docker side: https://github.com/uber-common/docker-ssh-agent-forward
The text was updated successfully, but these errors were encountered: