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 does not work with provisioner on Windows #1735

Closed
mconigliaro opened this issue May 14, 2013 · 58 comments
Closed

SSH agent forwarding does not work with provisioner on Windows #1735

mconigliaro opened this issue May 14, 2013 · 58 comments

Comments

@mconigliaro
Copy link

I'm trying to get vagrant provision to clone git repos on VMs using the SSH keys on my host machine. I have ssh.forward_agent = true in my Vagrantfile (#105), and my base box has the appropriate updates to /etc/sudoers to preserve SSH_AUTH_SOCK (#377, #1303). I can now prove that SSH agent forwarding is at least partially working.

First I ensure that the ssh-agent is running with the appropriate keys loaded:

$ eval `ssh-agent`
$ ssh-add
$ ssh-add -l

Then I vagrant ssh to the box and try to authenticate to GitHub:

$ sudo ssh -T git@github.com -o StrictHostKeyChecking=no
Hi mconigliaro! You've successfully authenticated, but GitHub does not provide shell access.

I've verified that this works as expected on OSX, Linux, and Windows hosts. My assumption is that vagrant provision should work similarly, and it seems to on Linux and OSX, but not on Windows. I already ran into #1404 with PuTTY/Pageant, so I tried again with Cygwin's OpenSSH, but it still fails, and I'm not sure why. The provisioner I'm using for testing looks like this:

Vagrant::Config.run do |config|
  config.vm.provision :shell, :inline => "ssh -Tv git@github.com -o StrictHostKeyChecking=no"
end

If SSH agent forwarding worked with the provisioner, I should get the "You've successfully authenticated" message above.

And here's another interesting thing. When I run VAGRANT_LOG=info vagrant provision, I see that the provisioner is writing /tmp/vagrant-shell and running it with sudo (which fails). But if I vagrant ssh and run sudo /tmp/vagrant-shell manually, it works fine. This hints to me that vagrant provision and vagrant ssh are doing slightly different things SSH-wise, but I don't know what/why.

For what it's worth, here's the log of a successful authentication when I do a vagrant ssh:

$ sudo ssh -Tv git@github.com -o StrictHostKeyChecking=no
OpenSSH_5.3p1 Debian-3ubuntu7, OpenSSL 0.9.8k 25 Mar 2009
debug1: Reading configuration data /root/.ssh/config
debug1: Reading configuration data /etc/ssh/ssh_config
debug1: Applying options for *
debug1: Connecting to github.com [204.232.175.90] port 22.
debug1: Connection established.
debug1: permanently_set_uid: 0/0
debug1: identity file /root/.ssh/identity type -1
debug1: identity file /root/.ssh/id_rsa type -1
debug1: identity file /root/.ssh/id_dsa type -1
debug1: Remote protocol version 2.0, remote software version OpenSSH_5.5p1 Debian-6+squeeze1+github12
debug1: match: OpenSSH_5.5p1 Debian-6+squeeze1+github12 pat OpenSSH*
debug1: Enabling compatibility mode for protocol 2.0
debug1: Local version string SSH-2.0-OpenSSH_5.3p1 Debian-3ubuntu7
debug1: SSH2_MSG_KEXINIT sent
debug1: SSH2_MSG_KEXINIT received
debug1: kex: server->client aes128-ctr hmac-md5 none
debug1: kex: client->server aes128-ctr hmac-md5 none
debug1: SSH2_MSG_KEX_DH_GEX_REQUEST(1024<1024<8192) sent
debug1: expecting SSH2_MSG_KEX_DH_GEX_GROUP
debug1: SSH2_MSG_KEX_DH_GEX_INIT sent
debug1: expecting SSH2_MSG_KEX_DH_GEX_REPLY
debug1: Host 'github.com' is known and matches the RSA host key.
debug1: Found key in /root/.ssh/known_hosts:1
debug1: ssh_rsa_verify: signature correct
debug1: SSH2_MSG_NEWKEYS sent
debug1: expecting SSH2_MSG_NEWKEYS
debug1: SSH2_MSG_NEWKEYS received
debug1: SSH2_MSG_SERVICE_REQUEST sent
debug1: SSH2_MSG_SERVICE_ACCEPT received
debug1: Authentications that can continue: publickey
debug1: Next authentication method: publickey
debug1: Offering public key: /home/Conigliaro Test/.ssh/id_rsa
debug1: Server accepts key: pkalg ssh-rsa blen 279
debug1: Authentication succeeded (publickey).
debug1: channel 0: new [client-session]
debug1: Requesting no-more-sessions@openssh.com
debug1: Entering interactive session.
debug1: Remote: Forced command: gerve mconigliaro 49:ef:54:41:ca:da:7e:17:dc:9e:ac:26:81:af:16:a8
debug1: Remote: Port forwarding disabled.
debug1: Remote: X11 forwarding disabled.
debug1: Remote: Agent forwarding disabled.
debug1: Remote: Pty allocation disabled.
debug1: Remote: Forced command: gerve mconigliaro 49:ef:54:41:ca:da:7e:17:dc:9e:ac:26:81:af:16:a8
debug1: Remote: Port forwarding disabled.
debug1: Remote: X11 forwarding disabled.
debug1: Remote: Agent forwarding disabled.
debug1: Remote: Pty allocation disabled.
debug1: Sending environment.
debug1: Sending env LANG = en_US.utf8
debug1: client_input_channel_req: channel 0 rtype exit-status reply 0
debug1: client_input_channel_req: channel 0 rtype eow@openssh.com reply 0
Hi mconigliaro! You've successfully authenticated, but GitHub does not provide shell access.
debug1: channel 0: free: client-session, nchannels 1
Transferred: sent 2272, received 2984 bytes, in 0.5 seconds
Bytes per second: sent 4871.4, received 6397.9
debug1: Exit status 1

And here's the unsuccessful log from the provisioner:

OpenSSH_5.3p1 Debian-3ubuntu7, OpenSSL 0.9.8k 25 Mar 2009
debug1: Reading configuration data /root/.ssh/config
debug1: Reading configuration data /etc/ssh/ssh_config
debug1: Applying options for *
debug1: Connecting to github.com [204.232.175.90] port 22.
debug1: Connection established.
debug1: permanently_set_uid: 0/0
debug1: identity file /root/.ssh/identity type -1
debug1: identity file /root/.ssh/id_rsa type -1
debug1: identity file /root/.ssh/id_dsa type -1
debug1: Remote protocol version 2.0, remote software version OpenSSH_5.5p1 Debian-6+squeeze1+github12
debug1: match: OpenSSH_5.5p1 Debian-6+squeeze1+github12 pat OpenSSH*
debug1: Enabling compatibility mode for protocol 2.0
debug1: Local version string SSH-2.0-OpenSSH_5.3p1 Debian-3ubuntu7
debug1: SSH2_MSG_KEXINIT sent
debug1: SSH2_MSG_KEXINIT received
debug1: kex: server->client aes128-ctr hmac-md5 none
debug1: kex: client->server aes128-ctr hmac-md5 none
debug1: SSH2_MSG_KEX_DH_GEX_REQUEST(1024<1024<8192) sent
debug1: expecting SSH2_MSG_KEX_DH_GEX_GROUP
debug1: SSH2_MSG_KEX_DH_GEX_INIT sent
debug1: expecting SSH2_MSG_KEX_DH_GEX_REPLY
debug1: Host 'github.com' is known and matches the RSA host key.
debug1: Found key in /root/.ssh/known_hosts:1
debug1: ssh_rsa_verify: signature correct
debug1: SSH2_MSG_NEWKEYS sent
debug1: expecting SSH2_MSG_NEWKEYS
debug1: SSH2_MSG_NEWKEYS received
debug1: SSH2_MSG_SERVICE_REQUEST sent
debug1: SSH2_MSG_SERVICE_ACCEPT received
Error reading response length from authentication socket.
debug1: Authentications that can continue: publickey
debug1: Next authentication method: publickey
debug1: Trying private key: /root/.ssh/identity
debug1: Trying private key: /root/.ssh/id_rsa
debug1: Trying private key: /root/.ssh/id_dsa
debug1: No more authentication methods to try.
Permission denied (publickey).

It looks like things start to go wrong after that "Error reading response length from authentication socket" line.

As far as I know, SSH_AUTH_SOCK is the only environment variable that really matters for this, but I've verified that it's defined and pointing to a file that actually exists. For what it's worth, here's my vagrant ssh environment:

TERM=xterm
LS_COLORS=rs=0:di=01;34:ln=01;36:hl=44;37:pi=40;33:so=01;35:do=01;35:bd=40;33;01:cd=40;33;01:or=40;31;01:su=37;41:sg=30;43:ca=30;41:tw=30;42:ow=34;42:st=37;44:ex=01;32:*.tar=01;31:*.tgz=01;31:*.arj=01;31:*.taz=01;31:*.lzh=01;31:*.lzma=01;31:*.zip=01;31:*.z=01;31:*.Z=01;31:*.dz=01;31:*.gz=01;31:*.bz2=01;31:*.bz=01;31:*.tbz2=01;31:*.tz=01;31:*.deb=01;31:*.rpm=01;31:*.jar=01;31:*.rar=01;31:*.ace=01;31:*.zoo=01;31:*.cpio=01;31:*.7z=01;31:*.rz=01;31:*.jpg=01;35:*.jpeg=01;35:*.gif=01;35:*.bmp=01;35:*.pbm=01;35:*.pgm=01;35:*.ppm=01;35:*.tga=01;35:*.xbm=01;35:*.xpm=01;35:*.tif=01;35:*.tiff=01;35:*.png=01;35:*.svg=01;35:*.svgz=01;35:*.mng=01;35:*.pcx=01;35:*.mov=01;35:*.mpg=01;35:*.mpeg=01;35:*.m2v=01;35:*.mkv=01;35:*.ogm=01;35:*.mp4=01;35:*.m4v=01;35:*.mp4v=01;35:*.vob=01;35:*.qt=01;35:*.nuv=01;35:*.wmv=01;35:*.asf=01;35:*.rm=01;35:*.rmvb=01;35:*.flc=01;35:*.avi=01;35:*.fli=01;35:*.flv=01;35:*.gl=01;35:*.dl=01;35:*.xcf=01;35:*.xwd=01;35:*.yuv=01;35:*.axv=01;35:*.anx=01;35:*.ogv=01;35:*.ogx=01;35:*.aac=00;36:*.au=00;36:*.flac=00;36:*.mid=00;36:*.midi=00;36:*.mka=00;36:*.mp3=00;36:*.mpc=00;36:*.ogg=00;36:*.ra=00;36:*.wav=00;36:*.axa=00;36:*.oga=00;36:*.spx=00;36:*.xspf=00;36:
SSH_AUTH_SOCK=/tmp/ssh-uwjIr13848/agent.13848
MAIL=/var/mail/vagrant
PATH=/usr/local/sbin:/usr/local/bin:/usr/sbin:/usr/bin:/sbin:/bin:/usr/games
LANG=en_US.utf8
HOME=/home/vagrant
SHELL=/bin/bash
LOGNAME=root
USER=root
USERNAME=root
SUDO_COMMAND=/usr/bin/env
SUDO_USER=vagrant
SUDO_UID=1000
SUDO_GID=1000

And here's my vagrant provision environment:

SHELL=/bin/bash
TERM=vt100
USER=root
SUDO_USER=vagrant
SUDO_UID=1000
SSH_AUTH_SOCK=/tmp/ssh-tlsae13632/agent.13632
USERNAME=root
MAIL=/var/mail/vagrant
PATH=/usr/local/sbin:/usr/local/bin:/usr/sbin:/usr/bin:/sbin:/bin:/usr/games
_=/usr/bin/env
PWD=/home/vagrant
LANG=en_US.utf8
HOME=/root
SUDO_COMMAND=/bin/bash -l
SHLVL=2
LOGNAME=root
SUDO_GID=1000
@olliebun
Copy link

I'm having the same issue in my environment.

@olliebun
Copy link

In my case, the problem is not that ssh agent forwarding doesn't work: it's that Vagrant is only forwarding its own key. It's possible to override this with config.ssh.private_key_path in the vagrant file, but then if your box was set up with the default keys you can't get in.

We're going to work on a quick patch to support a list of keys as arguments to config.ssh.private_key_path, so that it's possible to explicitly include the default Vagrant key as well as your own key to be forwarded in the agent.

@mconigliaro
Copy link
Author

@Danielbryan Isn't this the purpose of an SSH agent? SSH agent forwarding already works fine for vagrant ssh (it will forward all your keys). The big question I have is why it doesn't work for vagrant provision.

@olliebun
Copy link

Update: we followed the code paths and it looks like Vagrant doesn't even use SSH during provisioning - all our debug output for command options to SSH only shows during vagrant ssh, not during vagrant provision, and if we run ps while it's provisioning there's no SSH session running.

I'm not sure exactly what's going on - perhaps it has a terminal connection to the VM - but it looks like there's no hope for getting an SSH agent through for the shell provisioner. We're just going to script SSH'ing to the box after the provisioning is done.

@mconigliaro
Copy link
Author

@Danielbryan This is very strange, because as I mentioned previously, SSH agent forwarding works fine with the provisioners on OSX/Linux.

@olliebun
Copy link

I'm on OSX and it doesn't work for me. Very weird.

@mconigliaro
Copy link
Author

@Danielbryan Are you trying with the provisioner I described in the orignal issue? Does this help at all? https://help.github.com/articles/using-ssh-agent-forwarding

@punk-dev-robot
Copy link

Have exactly the same issue on windows. Everything works when i vagrant ssh, all keys are working as vagrant, with sudo and even with sudo su root. But during provisioning the keys from agent are not visible, so i can not clone git repo from our internal github install.

@punk-dev-robot
Copy link

Thanks @mconigliaro for detailed description, should definitely help.
I found chef-cookbook that has recipe for setting up SSH_AUTH_SOCK 'on the fly' (if you don't have updated sudoers on your basebox) but that doesn't work either (https://github.com/dergachev/chef_root_ssh_agent).
Still trying to find some workaround for this.

@garygreyling
Copy link

Having the same issue. Trying to provision a precise64 box and have private repos cloned. Can clone when I SSH in, but get 'Host key verification failed' on vagrant up.

@olliebun
Copy link

olliebun commented Jun 5, 2013

@garygreyling As mentioned above, Vagrant doesn't actually use SSH when provisioning. You can verify this by running ps from the host while the provisioning script is running.

I'm not sure what it is doing - terminal maybe?

@mconigliaro
Copy link
Author

@Danielbryan If you're correct that Vagrant doesn't use SSH at all while provisioning, then I wonder how SSH agent forwarding works on Linux/OSX. Maybe @mitchellh has some insight into what's going on here?

@olliebun
Copy link

olliebun commented Jun 6, 2013

Well vagrant ssh does use SSH, and agent forwarding works through there on both Linux and OSX for me. It just doesn't work via the provisioner. I'm not sure how exactly it connects to the machine - maybe it is SSH, but through some in-process library or a VirtualBox API. At any rate, the mechanism is different to what happens when you run vagrant ssh.

@garygreyling
Copy link

OK, so in the mean time, is anyone aware of a workaround? How do we perform actions in the provisioning cycle that require our host agent forwarded to the guest? (like cloning private repos)

@olliebun
Copy link

olliebun commented Jun 7, 2013

We wrote a plugin to clone private git repos in the host on boot, into a shared folder:

https://github.com/Learnosity/vagrant-git

@garygreyling
Copy link

Great, thanks @Danielbryan. I'd like to keep it all in chef, but post provision hooks will have to do for now :) Nice plugin :)

@mitchellh
Copy link
Contributor

This is almost certainly related to #1307. There are other workarounds here as well, so I'm going to close this.

@mconigliaro
Copy link
Author

@mitchellh Maybe I'm missing something, but I'm not sure that #1307 is the same problem. As I mentioned above, my base box already has the appropriate updates to /etc/sudoers to preserve SSH_AUTH_SOCK. This is confirmed by the fact that the env command shows the SSH_AUTH_SOCK variable in both my vagrant ssh environment and my vagrant provision environment. Strangely, it all works fine on Linux/OSX. This has only been a problem for me on Windows.

@mitchellh
Copy link
Contributor

Ah, sorry. This might be an issue then with net-ssh. Basically, for agent forwarding, I just request it from net-ssh.

@mitchellh mitchellh reopened this Jul 19, 2013
@olliebun
Copy link

Confused - is this opened or closed? I'm in the same boat as @mconigliaro - box configuration seems correct, and forwarding works with vagrant ssh, but not through the shell provisioner.

@mconigliaro
Copy link
Author

I suspect this is a case of giving too much information in a bug report, causing people to quickly skim over it without getting a full understanding of the problem. Just to summarize, this is not a case of SSH agent forwarding not working at all. It works with vagrant ssh on every platform I've tried (OSX, Linux, and Windows), which tells me that net-ssh is working just fine. The big question to me is what's different between vagrant ssh and vagrant provision (specifically on Windows), because that's the only time it doesn't work.

@mitchellh
Copy link
Contributor

@mconigliaro @Danielbryan vagrant ssh execs out to the actual OpenSSH ssh client. vagrant provision uses net-ssh requesting the identical configuration, but using net-ssh flags. There are, of course, many differences between the two, but with regards to SSH forwarding, I don't do anything special except request SSH forwarding from net-ssh. I really can't see how this error would ever come from Vagrant (vagrant code) unless I'm misconfiguring net-ssh. The fact that the net-ssh bug was not closed outright due to a configuration error hints to me that it isn't a basic misconfig.

@mconigliaro
Copy link
Author

OK, that makes sense. Thanks @mitchellh.

@maxdec
Copy link

maxdec commented Aug 8, 2013

Seems to work with the last update.

@mconigliaro
Copy link
Author

@maxdec we're still seeing this issue on Vagrant 1.2.7. How did you get yours to work?

@apelliciari
Copy link

i've got this issue too.

on windows forwarding doesn't work in provisioning but works with vagrant ssh.

@macmartine
Copy link

I'm seeing this too. OSX, Vagrant 1.3.1

@mconigliaro
Copy link
Author

Just FYI, this is strictly a Windows issue. If SSH key forwarding isn't working for you on OSX or Linux, you probably just don't have your SSH keys set up correctly.

@BenDavidJamin
Copy link

Does anyone have a work around for getting this SSH key forwarding on windows?

@mconigliaro
Copy link
Author

Since SSH agent forwarding works via vagrant ssh, you can log in to the VM and do this:

sudo chef-solo -c /tmp/vagrant-chef-1/solo.rb -j /tmp/vagrant-chef-1/dna.json

Stupid, but it's the only workaround I know of.

@tdonohue
Copy link

tdonohue commented Oct 3, 2013

To get around this problem, I've been using a workaround/hack in my Vagrantfile which essentially does the following: (1) Checks if you are on Windows, (2) If so, it attempts to copy your SSH key(s) from your Windows host to the Vagrant VM

Here's the basic code to put in your Vagrantfile. Make sure it appears before any provisioning scripts that require the SSH key. In this example, I'm checking specifically for a local ~/.ssh/github_rsa key (which is what GitHub for Windows creates for you):

if Vagrant::Util::Platform.windows?
    # You MUST have a ~/.ssh/github_rsa (GitHub specific) SSH key to copy to VM
    if File.exists?(File.join(Dir.home, ".ssh", "github_rsa"))
        # Read local machine's GitHub SSH Key (~/.ssh/github_rsa)
        github_ssh_key = File.read(File.join(Dir.home, ".ssh", "github_rsa"))
        # Copy it to VM as the /root/.ssh/id_rsa key
        config.vm.provision :shell, :inline => "echo 'Windows-specific: Copying local GitHub SSH Key to VM for provisioning...' && mkdir -p /root/.ssh && echo '#{github_ssh_key}' > /root/.ssh/id_rsa && chmod 600 /root/.ssh/id_rsa"
    else
        # Else, throw a Vagrant Error. Cannot successfully startup on Windows without a GitHub SSH Key!
        raise Vagrant::Errors::VagrantError, "\n\nERROR: GitHub SSH Key not found at ~/.ssh/github_rsa (required on Windows).\nYou can generate this key manually OR by installing GitHub for Windows (http://windows.github.com/)\n\n"
    end
end

You can see this exact code in action at: https://github.com/DSpace/vagrant-dspace/blob/master/Vagrantfile#L94

It functions as a workaround and provisioning all works (since 'root' has a copy of your SSH key). But it's still a bit of a hack.

@mconigliaro
Copy link
Author

@tdonohue This is great. Thanks!

@luck02
Copy link

luck02 commented Nov 12, 2013

I'm getting the same thing on 1.3.5:

I've got this in the affected machine's config:

    web.ssh.forward_agent = true

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

Of course everything works in msysgit local and also when I vagrant ssh into the box.

However, I get 'public key denied' when provsioning... Scripts appears to work fine in linux / osx but not on windows.

Using hack above 'solves' the issue.

@Svelix
Copy link

Svelix commented Jan 10, 2014

This is an issue with net-ssh on windows. I replaced the net-ssh gem shipped with vagrant with a manually build one based on https://github.com/factormystic/net-ssh and then it works when pageant is running.

See this pull-request: net-ssh/net-ssh#66

@apennebaker
Copy link

I'm experiencing this problem in Mac OS X 10.9.1 Mavericks.

I'm able to git clone normally from my host, able to ssh -T successfully in the VM, but git cloning with Vcsrepo fails during vagrant provision.

Update Turns out known_hosts was the problem, so I wrote an exec { ... 'git -T git@github.com -o StrictHostKeyChecking=no; echo Success' ... } step as a requirement for my vcsrepo steps in my Puppet script. Works for me!

@misterdjules
Copy link

I'm having the very same issue right now, trying to clone a private Git repository at provisioning time and using the SSH protocol.

@mitchellh It seems that net-ssh/net-ssh@bd61eea would fix this issue with net-ssh. Could you please confirm?

If you think this commit (released in net-ssh 2.8.0) would fix this issue, when do you think it could be integrated into a Vagrant release?

@peterjmit
Copy link

I can corroborate @apennebaker on known_hosts being problematic

Firstly I had to preserve SSH_AUTH_SOCK in /etc/sudoers as already described.

Secondly If the vagrant box is accessing a host for the first time during provisioning (i.e. it isn't in /root/.ssh/known_hosts) then I see the following message

Failed to execute git clone --no-checkout 'git@'
Host key verification failed.
fatal: The remote end hung up unexpectedly

As soon as I add the site to known_hosts then vagrant provision works correctly.

@mmathias
Copy link

I have the same problem as @apennebaker !!!

Could you tell me exactly what did you do?

exec { 'gitt':
cwd => "/var/www/bla",
command => "git -T git@gitlab.bla.com -o StrictHostKeyChecking=no; echo Success"
}

vcsrepo { "/var/www/bla/${repo}":
    ensure   => latest,
    owner    => $owner,
    group    => $owner,
    provider => git,
    require  => [ Package["git"], Exec['gitt'] ],
    source => "git@gitlab.bla.com:bla/${repo}.git",
    revision => 'master',
}

What am I doing wrong?

@mbroadst
Copy link

This totally worked for me (the known_hosts fix), but with a little bit of a change. Here is the top of my provisioning bootstrap.sh script:

#!/usr/bin/env bash

# enable ssh agent forwarding
touch /etc/sudoers.d/root_ssh_agent
chmod 0440 /etc/sudoers.d/root_ssh_agent
echo "Defaults    env_keep += \"SSH_AUTH_SOCK\"" > /etc/sudoers.d/root_ssh_agent

if [ -z "$SSH_AUTH_SOCK" ]; then
  echo "ssh agent not forwarded, aborting" >&2
  exit 1
fi

# make these known hosts to ssh
ssh -T git@bitbucket.org -o StrictHostKeyChecking=no
ssh -T git@github.org -o StrictHostKeyChecking=no

and then things are happy. good luck!

@TomTasche
Copy link

I'm sorry to comment on such an old issue, but why is this closed? The problem still exists as of version 1.6.3 and there is no good workaround known till now. As suggested by a previous comment, would updating net-ssh fix this problem maybe?

@Volune
Copy link

Volune commented Jul 22, 2014

That may help:

Vagrant 1.6.3, Windows 8.1

I first tried using vagrant in msys (the one provided with git for windows), ssh-agent, ssh-add, ... but provisioning wasn't working.
I then tried running pageant, adding the putty key and opening a windows command prompt to run vagrant: provisioning worked (i was able to clone git repositories)

My Vagrantfile looks like this:

  config.vm.box = "ubuntu/trusty64"

  config.ssh.forward_agent = true

  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

  config.vm.provision "shell", :path => "vm-install.sh"

@BogdanNicolau
Copy link

Can confirm @Volune 's solution works.
Be careful not to have the config.ssh.private_key_path directive, otherwise it won't work. Also, make sure the path to putty is added to the PATH in Windows env. variables. Nothing else is needed.

Any other variant does not work for provisioning, on Windows, tried Git bash, Cygwin, etc.
@tdonohue 's solution issued a series of warnings, starting with: key_parse_private2: missing begin parameter. No matter what I did, couldn't get passed this error.

@bravo-kernel
Copy link

Fellow Windows users:

SSH agent forwarding while provisioning does work on Windows but:

  • the key MUST be loaded in Pageant
  • due to a limitation in net-ssh limitation only supporting Pageant, ty @misterdjules

So... even if your vagrant ssh is working flawlessly => load your key in Pageant as well and things will provision as expected. Far from ideal but hey... it's Windows ;)

@teleivo
Copy link

teleivo commented Dec 23, 2014

thank you so much guys! what a struggle on windows ;)

I just wanted to add some of my experiences

I am on Windows 7 using

  • Vagrant 1.7.1
  • cmder (msysgit)

with following Vagrantfile settings

config.vm.box = "ubuntu/trusty64"
config.ssh.forward_agent = true

and thanks to @bravo-kernel having pageant running with my key added

provisioning via puppet and vcsrepo (git clone from private repo) finally works!!

I do not need to add SSH_AUTH_SOCK in /etc/sudoers.d/root_ssh_agent

I think the issue of sudoer whipping out SSH_AUTH_SOCK for vagrant user has been resolved in newer vagrant versions.

So when ssh into the box as user 'vagrant' (SSH_AUTH_SOCK is defined), switch to sudoer (SSH_AUTH_SOCK is not defined) and come back to 'vagrant' (SSH_AUTH_SOCK is again defined).

I hope there is/will be a way without using pageant! But at least it works :)

@quantumJLBass
Copy link

So just for point of reference, when you only have GitHub for windows loaded, and you are not planning on jumping though a lot of hoops to get web.ssh.forward_agent = true to work correctly, I found that only #1735 (comment) was the right solution. It's referenced many times out on other sites, including stackoverflow.

The issues are, I'm using a box I didn't create, which uses the highly suggest way of using keys to tunnel and more to the point the vagrant.pub key set for the root user that is used on many boxes out there when doing anything like vmConfig.vm.provision :shell, :inline => "echo 'I would like to git clone now to a private repo but will not just out of the box'". Out of the box I would expect web.ssh.forward_agent = true to be all I needed, but this is what did the whole trick.

 config.ssh.forward_agent = true
if Vagrant::Util::Platform.windows?
    # You MUST have a ~/.ssh/github_rsa (GitHub specific) SSH key to copy to VM
    if File.exists?(File.join(Dir.home, ".ssh", "github_rsa"))
        # Read local machine's GitHub SSH Key (~/.ssh/github_rsa)
        github_ssh_key = File.read(File.join(Dir.home, ".ssh", "github_rsa"))
        # Copy it to VM as the /root/.ssh/id_rsa key
        config.vm.provision :shell, :inline => "echo 'Windows-specific: Copying local GitHub SSH Key to VM for provisioning...' && mkdir -p /root/.ssh && echo '#{github_ssh_key}' > /root/.ssh/id_rsa && chmod 600 /root/.ssh/id_rsa"
    end
end

#dev env so woo hoo
config.vm.provision :shell, :inline => "echo 'Defaults    env_keep+=SSH_AUTH_SOCK' >>  /etc/sudoers"

Now I can add something like

config.vm.provision :shell, :inline => "gitploy -q -b product-matrix pm git@github.com:jeremyBass/pleasurers-exts.git"

And bam I have cloned in my private repo and all is right. Note that I could have left out the

config.vm.provision :shell, :inline => "echo 'Defaults    env_keep+=SSH_AUTH_SOCK' >>  /etc/sudoers"

But see I need to vagrant ssh in and then sudo -s so I have to pass the agent on. I hope this help someone out there that needs to clone in some private repo right our of the gate on provisioning. I had to do a lot of testing to get it working just right, but I'm up and running now. Happy coding ya'll.

@tlartaud
Copy link

Hi,

Thanks @ all for your instructions and help. That was a total headache !
Personnaly, im using a personnal gitlab server and had no option to connect without ssh keys.
I am using Varying Vagrant Vagrants, I was stuck on the host key verification asking for rsa fingerprint validation.

I tried with thoses tasks but it didn't work :

# add git.mydomain.com to the list of known_hosts
  config.vm.provision :shell do |shell|
    shell.inline = "ssh-keyscan -H $2 >> $1 && chmod 600 $1"
    shell.args = %q{/root/.ssh/known_hosts "git.mydomain.com"}
  end

  # add git.mydomain.com to the list of known_hosts
  config.vm.provision :shell do |shell|
    shell.inline = "echo -e 'Host $2\n\tStrictHostKeyChecking no\n' >> $1"
    shell.args = %q{/root/.ssh/config git.mydomain.com}
  end

So, instead of trying to add this in the VagrantFile, I've added this in my vvv-init.sh configuration for that site :

# Adding git.mydomain.com to know hosts.
ssh -o StrictHostKeyChecking=no -p PORT_NUMBER git@git.mydomain.com uptime

@tlartaud
Copy link

I may correct myself as my previous suggestion is finally not correctly working ^^

Here is the final solution that works for me :

  • Using Windows + msysgit + VirtualBox + Pageant
  • Created protected key and loaded trough pageant
  • Saved the key to ~/.ssh/id_rsa.ppk
  • Exported the key to openssh format in Putty, conversions menu, and named it id_rsa
  • Created a shortcut to auto load pageant at windows startup
  • Added user environment variable : GIT_SSH C:\Users\username\Tools\PUTTY\plink.exe
  • Added this to path user environment variable : ;C:\Users\username\Tools\PUTTY\putty.exe
  • Locally created a ~/.ssh/config config file with :
Host                    *
  ForwardAgent          yes
  • Rebooted
  • Updated my vagrant file :
  # Forward Agent
  #
  # Enable agent forwarding on vagrant ssh commands. This allows you to use ssh keys
  # on your host machine inside the guest. See the manual for `ssh-add`.

  config.ssh.forward_agent = true

  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

  # add git.mydomain.com to the list of known_hosts
  # where 1234 is my hidden ssh port
  config.vm.provision :shell do |shell|
    shell.inline = "echo \"> SSH: add $2 to the list of known_hosts\" && ssh-keyscan -p $3 -H $2 >> $1 && chmod 600 $1"
    shell.args = %q{/etc/ssh/ssh_known_hosts git.mydomain.com 1234}
  end

  # add github.com to the list of known_hosts
  config.vm.provision :shell do |shell|
    shell.inline = "echo \"> SSH: add $2 to the list of known_hosts\" && ssh-keyscan -p $3 -H $2 >> $1 && chmod 600 $1"
    shell.args = %q{/etc/ssh/ssh_known_hosts github.com 22}
  end

  # add bitbucket.com to the list of known_hosts
  config.vm.provision :shell do |shell|
    shell.inline = "echo \"> SSH: add $2 to the list of known_hosts\" && ssh-keyscan -p $3 -H $2 >> $1 && chmod 600 $1"
    shell.args = %q{/etc/ssh/ssh_known_hosts bitbucket.com 22}
  end

  # bypass rsa fingerprint approbation
  config.vm.provision :shell do |shell|
    shell.inline = "echo -e \"Host $2\n\tStrictHostKeyChecking no\n\" >> $1"
    shell.args = %q{/etc/ssh/config *}
  end
  • Then i've completely destroyed and deleted my box for a vagrant up --provision and it finally worked on the first provisioning ...

fiou ...

@nebffa
Copy link

nebffa commented Feb 18, 2015

FYI if you are running a Windows guest VM (in my case, Windows Server 2012R2 Standard), you can use a modification of tdonohue's script.

Here is the modification:

if File.exists?(File.join(Dir.home, ".ssh", "id_rsa"))
      private_key = File.read(File.join(Dir.home, ".ssh", "id_rsa"))

      # copy the ssh key to the VM
      config.vm.provision "shell" do |s|
        s.args = '"%s"' % [private_key]
        s.path = "copy_ssh_key.ps1"
      end
  else
      # Else, throw a Vagrant Error. Cannot successfully startup on Windows without a GitHub SSH Key!
      raise Vagrant::Errors::VagrantError, "\n\nERROR: SSH Key not found at ~/.ssh/id_rsa\n\n"
  end

where the external Powershell script copy_ssh_key.ps1 is:

$path = "C:/users/vagrant/.ssh/id_rsa"
New-Item -Force -Type "File" -Path "$path"

# args[0] is the host's private key
Add-Content $path $args[0]

then you need to add the ssh-key to ssh-agent - I have done this using Powershell via Chef:

powershell_script "add_key_to_ssh_agent" do
    code <<-EOH
    $path = (Get-Command start-ssh-agent.cmd).path
    Invoke-Item $path
    EOH
end

It is also necessary to manually add host file entries since the ssh_known_hosts cookbook does not work on Windows. This is done by a separate provisioning script:

config.vm.provision "shell" do |s|
    s.path = "add_to_ssh_known_hosts.ps1"
end

where add_to_ssh_known_hosts.ps1 is just below (note that you will have to change the site name, port number and public key to the relevant settings for the site you are trying to connect)

# needs to be done with a hack, since putting entries in the known_hosts file isn't supported on windows guest machines
$first_entry = @"
[stash]:7999,[192.168.2.48]:7999 ssh-rsa AAAAB3NzaC1yc2EAAAADAQABAAABAQDxlfVK1fwAYhm0GP/wqg4ti4GkBl2Kur2FfqphB78mUimhLt1NJez6W9fWd0OyWqV5+eXO/ElXOeaiUvTNrkY2MGC1fGc1FjEglWq/Lz+VJXpe71SngD4LEnInE6VstBntOgPHTrwyKCvrROI7eJgetZYG78u7T6E0T36JqTwl7rTUpQGLGh+MZVkuaHBS97z0QEw1I6jLmK5jzOAln7dSfO1JK/UxCUplC5kaDxEjOSf4udLDIk26Rhd5+VUk2T3N18HcGGRqztXtTCDYvshMvdbQIIg6ypSNmJ0v4M5iypGFUbUfGywPJy2BFza5+xzijR0ok7TbOofEyqJCN8At
"@

$second_entry = @"
[stash]:7999 ssh-rsa AAAAB3NzaC1yc2EAAAADAQABAAABAQDxlfVK1fwAYhm0GP/wqg4ti4GkBl2Kur2FfqphB78mUimhLt1NJez6W9fWd0OyWqV5+eXO/ElXOeaiUvTNrkY2MGC1fGc1FjEglWq/Lz+VJXpe71SngD4LEnInE6VstBntOgPHTrwyKCvrROI7eJgetZYG78u7T6E0T36JqTwl7rTUpQGLGh+MZVkuaHBS97z0QEw1I6jLmK5jzOAln7dSfO1JK/UxCUplC5kaDxEjOSf4udLDIk26Rhd5+VUk2T3N18HcGGRqztXtTCDYvshMvdbQIIg6ypSNmJ0v4M5iypGFUbUfGywPJy2BFza5+xzijR0ok7TbOofEyqJCN8At
"@

$known_hosts_path = "C:/users/vagrant/.ssh/known_hosts"
$first_entry | out-file -encoding "utf8" $known_hosts_path
$second_entry | add-content $known_hosts_path

@bravo-kernel
Copy link

Come on Windows users, there's no need to upload your (github) private keys to your box.

Here's a fully functional Vagrantfile for a box that fully supports Windows for both:

  • self-generated ssh key pair for the authentication (login)
  • ssh-agent forwarded Github private key for checking out private repos etc.

The docs explain the SSH Authentication and Forwarding. It can be done :)

@sschuberth
Copy link
Contributor

So the current state of this seems to be that SSH agent forwarding on Windows during provisioning only works with Pageant, not with ssh-agent from Cygwin / MSYS due to net-ssh/net-ssh#192.

@bravo-kernel
Copy link

@sschuberth correct

@rihardsk
Copy link

rihardsk commented Jul 9, 2015

Shouldn't this be reopened and remain open until net-ssh/net-ssh#192 is resolved?

It was quite confusing to see all of the bugs related to ssh-agent forwarding being closed and yet not being able to get ssh-agent forwarding working on a Windows host. Can't see why @mitchellh closed this bug #1735 (comment) just after reopening it #1735 (comment).

@sschuberth
Copy link
Contributor

I agree it's confusing why @mitchellh first reopened and then immediately closed the issue again.

However, there's a solution that works quite well for me (and hasn't been mentioned before): On a Windows host, start by using only Pageant (not ssh-agent). This will ensure agent forwarding works with provisioning. To make agent forwarding also work with vagrant ssh, additionally use ssh-pagent. This will make OpenSSH as spawned by vagrant ssh use the identities from Pageant so that you do not have to deal with ssh-agent at all.

@sethvargo
Copy link
Contributor

I think Mitchell just clicked the wrong button 😄

If you are continuing to have issues with this, please open a new issue. This issue is almost 2 years old and a lot has changed in Vagrant since. I think this may be a bug in the net-ssh library (which comes from Ruby). The next major release of Vagrant (1.8) will upgrade the Ruby version, so hopefully that will make this issue go away.

@hashicorp hashicorp locked and limited conversation to collaborators Jul 9, 2015
Sign up for free to subscribe to this conversation on GitHub. Already have an account? Sign in.
Labels
None yet
Projects
None yet
Development

No branches or pull requests