Skip to content
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

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

dholdren opened this issue Jan 8, 2013 · 10 comments


Copy link

dholdren commented Jan 8, 2013


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


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 -o StrictHostKeyChecking=no works
  4. have a shell provision like:
    config.vm.provision :shell, :inline => 'ssh -T -o StrictHostKeyChecking=no'
    or chef recipe with:
    execute "ssh -T -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)


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"


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\""}
Copy link

dholdren commented Jan 8, 2013

Ha, just found this:
The guide for creating boxes states you should env_keep SSH_AUTH_SOCK, but the I retrieved from does not have this setting out of the.. um.. box.

Copy link

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

Copy link

@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.

Copy link

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.

Copy link

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:

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.

Copy link

nmeirik commented Sep 28, 2013

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?

Copy link

thias commented Nov 20, 2013

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

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

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).

Copy link

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\n\tStrictHostKeyChecking no\n" >> ~/.ssh/config

Copy link

dmill commented Oct 3, 2014

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!

Copy link

edrex commented Jan 8, 2015

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.

Sign up for free to subscribe to this conversation on GitHub. Already have an account? Sign in.
None yet
None yet

No branches or pull requests

8 participants