-
Notifications
You must be signed in to change notification settings - Fork 4.4k
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
Comments
I'm having the same issue in my environment. |
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 We're going to work on a quick patch to support a list of keys as arguments to |
@Danielbryan Isn't this the purpose of an SSH agent? SSH agent forwarding already works fine for |
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 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. |
@Danielbryan This is very strange, because as I mentioned previously, SSH agent forwarding works fine with the provisioners on OSX/Linux. |
I'm on OSX and it doesn't work for me. Very weird. |
@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 |
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. |
Thanks @mconigliaro for detailed description, should definitely help. |
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 |
@garygreyling As mentioned above, Vagrant doesn't actually use SSH when provisioning. You can verify this by running I'm not sure what it is doing - terminal maybe? |
@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? |
Well |
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) |
We wrote a plugin to clone private git repos in the host on boot, into a shared folder: |
Great, thanks @Danielbryan. I'd like to keep it all in chef, but post provision hooks will have to do for now :) Nice plugin :) |
This is almost certainly related to #1307. There are other workarounds here as well, so I'm going to close this. |
@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 |
Ah, sorry. This might be an issue then with net-ssh. Basically, for agent forwarding, I just request it from net-ssh. |
Confused - is this opened or closed? I'm in the same boat as @mconigliaro - box configuration seems correct, and forwarding works with |
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 |
@mconigliaro @Danielbryan |
OK, that makes sense. Thanks @mitchellh. |
Seems to work with the last update. |
@maxdec we're still seeing this issue on Vagrant 1.2.7. How did you get yours to work? |
i've got this issue too. on windows forwarding doesn't work in provisioning but works with vagrant ssh. |
I'm seeing this too. OSX, Vagrant 1.3.1 |
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. |
Does anyone have a work around for getting this SSH key forwarding on windows? |
Since SSH agent forwarding works via
Stupid, but it's the only workaround I know of. |
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):
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. |
@tdonohue This is great. Thanks! |
I'm getting the same thing on 1.3.5: I've got this in the affected machine's config:
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. |
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 |
I'm experiencing this problem in Mac OS X 10.9.1 Mavericks. I'm able to Update Turns out known_hosts was the problem, so I wrote an |
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? |
I can corroborate @apennebaker on Firstly I had to preserve Secondly If the vagrant box is accessing a host for the first time during provisioning (i.e. it isn't in
As soon as I add the site to |
I have the same problem as @apennebaker !!! Could you tell me exactly what did you do? exec { 'gitt':
What am I doing wrong? |
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:
and then things are happy. good luck! |
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? |
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. My Vagrantfile looks like this:
|
Can confirm @Volune 's solution works. Any other variant does not work for provisioning, on Windows, tried Git bash, Cygwin, etc. |
Fellow Windows users: SSH agent forwarding while provisioning does work on Windows but:
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 ;) |
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
with following Vagrantfile settings
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 :) |
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 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 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 |
Hi, Thanks @ all for your instructions and help. That was a total headache ! 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 |
I may correct myself as my previous suggestion is finally not correctly working ^^ Here is the final solution that works for me :
fiou ... |
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 $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 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 # 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 |
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:
The docs explain the SSH Authentication and Forwarding. It can be done :) |
So the current state of this seems to be that SSH agent forwarding on Windows during provisioning only works with Pageant, not with |
@sschuberth correct |
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). |
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 |
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. |
I'm trying to get
vagrant provision
to clone git repos on VMs using the SSH keys on my host machine. I havessh.forward_agent = true
in my Vagrantfile (#105), and my base box has the appropriate updates to/etc/sudoers
to preserveSSH_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:
Then I
vagrant ssh
to the box and try to authenticate to GitHub: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: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 Ivagrant ssh
and runsudo /tmp/vagrant-shell
manually, it works fine. This hints to me thatvagrant provision
andvagrant 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
:And here's the unsuccessful log from the provisioner:
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 myvagrant ssh
environment:And here's my
vagrant provision
environment:The text was updated successfully, but these errors were encountered: