SSH Agent Forwarding not available during provisioning (using lucid32 box, maybe others)

[dholdren]

Problem

During provisioning we cannot leverage ssh agent forwarding for tasks (i.e. cloning a personal github repo) even though agent forwarding is turned on via: config.ssh.forward_agent = true

Reproduce

you can easily reproduce this by: 1) enabling config.ssh.forward_agent in your Vagrantfile 2) ensuring you ran ssh-add ~/.ssh/id_rsa 3) ensure on your (host) OS that ssh -T git@github.com -o StrictHostKeyChecking=no works 4) have a shell provision like: config.vm.provision :shell, :inline => 'ssh -T git@github.com -o StrictHostKeyChecking=no' or chef recipe with: execute "ssh -T git@github.com -o StrictHostKeyChecking=no"

(Even after the fix, this will exit with status 1, but you will see the "authenticated successfully" output when agent forwarding is working)

Fix

Have the /etc/sudoers file keep the "SSH_AUTH_SOCK" environment variable. This should be directly integrated into the lucid32 box. The easiest way is to have a file in /etc/sudoers.d/ with the contents: Defaults env_keep += "SSH_AUTH_SOCK"

Workaround

You can get around this issue by using the following shell provisioning before anything that requires agent forwarding to be working:

config.vm.provision :shell do |shell|
    shell.inline = "touch $1 && chmod 0440 $1 && echo $2 > $1"
    shell.args = %q{/etc/sudoers.d/root_ssh_agent "Defaults    env_keep += \"SSH_AUTH_SOCK\""}
end

[dholdren]

Ha, just found this: http://docs.vagrantup.com/v1/docs/base_boxes.html The guide for creating boxes states you should env_keep SSH_AUTH_SOCK, but the lucid32.box I retrieved from http://files.vagrantup.com/lucid32.box does not have this setting out of the.. um.. box.

[mitchellh]

Note I'm looking at pull #1307 as well as a way to do this.

[nisaacson]

@dholdren Thanks so much for documenting your fix here. I have been struggling with trying to clone private repos during provisioning and your fix works perfectly.

[mitchellh]

Since this is more of a box configuration thing rather than Vagrant, I'm going to close this issue. I'm still looking at #1307 as a possible Vagrant way to solve this.

[dholdren]

where do I file a ticket to get your hosted base boxes to have Defaults env_keep += "SSH_AUTH_SOCK" ?

Again, I'm referring to your own documentation on creating base boxes: http://docs-v1.vagrantup.com/v1/docs/base_boxes.html

Once logged in, run visudo and set the admin group to use no password. Additionally, set the env_keep variable to "SSH_AUTH_SOCK" so the connection to the forward agent is kept when sudo is run. That way provisioners may run commands as other users and authenticate against the forward agent.

Thank you for providing and hosting the boxes (as well as for Vagrant!), I'm just pointing out an inconsistency that tripped me up and others too.

[nmeirik]

I can not get the suggested workaround here to work. I've implemented it before any provisioners making use of SSH, but authentication still fails (SSH'ing into the box first works, BTW). Any possible steps to troubleshoot this?

[thias]

Here's another ''el cheapo'' workaround to be used inside a shell script (which would typically git clone git@github.com:... a private repository) :

# Work around sudo removing this env variable by default
SOCKET=$(ls -1 --sort t /tmp/ssh-*/agent.* | head -1)
export SSH_AUTH_SOCK="${SOCKET}"

This has root take over the most recently created socket. The socket glob might need to be adapted depending on the OS (this one works for RHEL6).

[kevinsimper]

If you have problems doing a composer install even after you have done all these tips, do a ssh connection to github beforehand, it works:

echo -e "Host github.com\n\tStrictHostKeyChecking no\n" >> ~/.ssh/config

[dmill]

This was giving me a lot of trouble, and people made it seem so easy I thought I was going crazy. Thanks for your fix!

[edrex]

Suggestion: split your provision into two scripts, one to run as root and another with :privileged => false (as vagrant). This avoids the need to su vagrant, which is where the SSH_AUTH_SOCK var is being dropped.