test-kitchen fails when vagrant 1.7 inserted a newly generated key #130
Comments
|
@yves-vogl this looks like a bug in the net-ssh library (from the output) |
|
@yves-vogl works fine for me with Vagrant 1.7 and the newly generated keys |
|
I think that's something related to Vagrant itself hashicorp/vagrant#5219 |
|
Is the private key location change relate this issue ? But the old instance create via Vagrant 1.6.x would login use shared "~/.vagrant.d/insecure_private_key" file. I notice that for the instance created in 1.6.x period, when Vagrant upgraded, a instance specified private key will also be created to old instances. However I also got same issue with some instance created by Vagrant 1.7.x directly.. Now I guess it's a issue with Vagrant 1.7.x version, never met these problem before in 1.6.x version. |
|
We use the following workaround: ---
driver:
name: vagrant
require_chef_omnibus: true
ssh:
insert_key: false |
|
That doesn't seem to work for me. kitchen.yml That results in the following Vagrantfile: And while I can still IE, I can't successfully Any thoughts? It's confusing that I do not see the "generating new key" output in Versions:
|
|
I just had a similar Problem where kitchen inserted a new key and then could not connect (Authentication failure). Setting insert_key in kitchen.yml did not work for me too (kitchen version 1.3.1) and cant work since this ssh config option has only recently been added and there has not been a new kitchen-vagrant release in forever #145. This is evil and I don't like it, but it was the only way I could fix this for now. |
|
Good to know. I ended up writing a recipe that just tacks the public key into the ~/.ssh/authorized_keys of the Vagrant user on local VMs. It's hacky, but it works. |
|
+1 |
|
Hi, |
|
@Joseph-R |
|
@lmeyemezu - Just drop that right into your chef recipe. So here is an example from a sudoers recipe we use. Note that the insecure key and vagrant's access to sudo permissions is only included allowed in the |
|
@Joseph-R |
|
Pretty sure that between the version upgrades of all the related software the root issue has been resolved. If not feel free to re-open or open a wholly new issue. |
|
I'm using latest vagrant, test-kitchen, virtualbox. Nothing helps me to bring machine up: ---
driver:
name: vagrant
ssh:
insert_key: false
customize:
cpus: 1
memory: 1024Produces: Vagrant.configure("2") do |c|
c.berkshelf.enabled = false if Vagrant.has_plugin?("vagrant-berkshelf")
c.vm.box = "bento/centos-6.7"
c.vm.hostname = "default-centos-67"
c.ssh.insert_key = "false"
c.vm.synced_folder ".", "/vagrant", disabled: true
c.vm.provider :virtualbox do |p|
p.customize ["modifyvm", :id, "--cpus", "1"]
p.customize ["modifyvm", :id, "--memory", "1024"]
end
endHere is false as string |
|
Based on the report and lack of versions I can't tell - best to open a new issue and not resurrect a closed one so we can treat it as a separate issue. |
|
Just to give you some spice, I only see this issue on centos. I didn't have this issue with ubuntu platform, as you can see on #236. Here is the specific comment about the platform differences: Cheers and have a happy Friday! |
|
I'm confirming @keinohguchi 's observation that this only happens on centos boxes. I'm working through all the tutorials on https://learn.chef.io/ and don't have problems with vagrant when launching ubuntu boxes from kitchen or vagrant directly. |
|
I've confirmed this issue too with centos boxes using chefdk 16.x |
|
There is also a known issue with latest Vagrant (1.8.5) hashicorp/vagrant#7627 |
|
Global Vagrant file workaround worked for me Sounds like it will be fixed on the Vagrant side in the |
The text was updated successfully, but these errors were encountered: