I ran into a situation today where I needed to support agent forwarding with sudo. Specifically, I wanted to check out a git repository using agent forwarding, sudo’ing to a (non-root) user.
I started working on a patch to add support for this in ansible <https://github.com/lorin/ansible/tree/sudo-agent-forward>. It’s functional, although not quite ready for submission.
Michael, are you interested in this type of functionality?
Lorin
Sure thing, send in a pull request when you get ready.
–Michael
+1
I'm using this workaround for ssh-agent forwarding:
/etc/sudoers file by adding:
Defaults env_keep+=SSH_AUTH_SOCK
note this one works for root only.
Rodney:
My plan for the sudo support is to use the “env” program to inject the SSH_AUTH_SOCK environment variable into the sudo’d process, so that editing /etc/sudoers isn’t necessary.
For sudo’ing to non-root users, I’m going to use access control lists to grant the sudo_user access to the auth socket, like this:
setfacl -m u:sudo_user:rw $SSH_AUTH_SOCK
setfacl -m u:sudo_user:x $(dirname $SSH_AUTH_SOCK)
Lorin
Just thinking out loud here, not all filesystems we log in to may support ACLs, it will need to plan accordingly if so configured, or at least raise errors.
Good point. I will probably make the ACL-based approach opt-in by an additional configuration option. Without ACLs, it probably will only support agent-forwarding when sudo’ing to root.
Lorin
For you info I worked on a pull request that adds agent forwarding to the paramiko transport :
https://groups.google.com/forum/#!topic/ansible-project/-wD8nVlFWQQ
the 2 subjects are related (and I used some of your code for the sudo/sudo_user part !)
I ran into the same problem.
Isn’t your solution in the upstream?
This functionality has not been merged into ansible.
You can checkout a comment I left on a ticket where I explained how to get this working:
https://github.com/ansible/ansible/issues/4378#issuecomment-25758372
no it has not been accepted upstream.
you can still find the proposed PR here - https://github.com/jeromew/ansible/commit/7b14e45bf7432edf64decd26db7494f9b4c3e0ec
the patch works but the solution need some hacks that cannot be accepted by everyone ; so Michael preferred to not accept it knowing that paramiko support is doomed on the long term. I agree with his decision even though I had to change my deploy approach.
for a detailed overview of the forwarding problematic:
https://github.com/ansible/ansible/pull/4100
you have in fact 3 patches in the link above :
1 - support agent forwarding for paramiko (so the ansible_ssh_user can use the keys)
2- export the SSH_AUTH_SOCK when sudo’ing without requiring a modification of sudoers (sudo_user = root can use the keys)
3- change the ACLs on SSH_AUTH_SOCK (sudo_user != root can use the keys)
(1) is not necessary if your control machine does not need paramiko
(2) is not necessary if you accept to modify sudoers
(3) is the only way I found to give access to the keys to sudo_user != root
other ways around that people have mentioned for (3) :
a) do (1) and authorize the control machine to ssh directly login = user
b) create temporary read-only keys on the git repo that you dispatch to the users
c) do (1), git with ansible_ssh_user and then move the files to another user
d) pre-package all apps on the control machine and do not invoke github on the remotes
I would be interested in hearing how github dependent people are handling their deployments.
Jerome
I would be interested in hearing how github dependent people are handling
their deployments.
I'd like to see the git module enhanced to take an optional
username/password, or a deploy key, and also be smart enough to add
github.com to known hosts if a special flag is added, I think that would
reduce most confusion with git, especially SSH.
We've got a feature idea ticket open, but are probably chasing a few other
things first.
If someone wants to upgrade it, I will build a statue of you in our formal
gardens in your choice of rock or affordable metals (sorry Platinum is
probably not a good option) (once we have a formal gardens, of course).