test-kitchen fails when vagrant 1.7 inserted a newly generated key

[test-kitchen]

test-kitchen fails when vagrant 1.7 inserted a newly generated key

[cheeseplus]

There is also a known issue with latest Vagrant (1.8.5) hashicorp/vagrant#7627

[joerg]

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.
I had to create a global Vagrantfile in ~/.vagrant.d/Vagrantfile

Vagrant.configure("2") do |config|
  config.ssh.insert_key = false
end

This is evil and I don't like it, but it was the only way I could fix this for now.

We use the following workaround:

---
driver:
  name: vagrant
  require_chef_omnibus: true
  ssh:
    insert_key: false

[keithnoguchi]

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:

#236 (comment)

Cheers and have a happy Friday!

[jsirex]

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: 1024

Produces:

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
end

Here is false as string "false"
Probably this should be reported as separate bug, shouldn't it?

[sethvargo]

@yves-vogl this looks like a bug in the net-ssh library (from the output)

[tknerr]

@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

[linfan]

Is the private key location change relate this issue ?
In Vagrant 1.7.x a new private key will be create for each instance. E.g.

$ vagrant ssh-config
Host centos7
  ...
  IdentityFile /Users/flin/workspace/CentOS/.vagrant/machines/centos7/virtualbox/private_key
  ...

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.

[Joseph-R]

@yves-vogl

That doesn't seem to work for me.

kitchen.yml

---
driver:
  name: vagrant
  ssh:
    insert_key: false  # Do not insert random key with Vagrant 1.7.1+.  
    private_key_path: '~/.vagrant.d/insecure_private_key' # Use insecure key

(snip)

  - name: dev
    driver:
      vm_hostname: false
      network:
      - ["private_network", {ip: "33.33.33.113"}]
      synced_folders:
      - ["~/repo/O2O", "/home/adsummos/analytics", "create: true, type: :nfs"]
      - ["~/repo/portal", "/home/adsummos/portal", "create: true, type: :nfs"]
      customize:
        memory: 4096
    run_list:
      - recipe[JO2O]
    excludes: ["centos-5.10"]
    attributes:
      set_fqdn: 'dev.local'
      remote_user: <%= ENV['USER'] %>
      iptables:
        install_rules: false

That results in the following Vagrantfile:

$ cat ./.kitchen/kitchen-vagrant/dev-centos-65/Vagrantfile
Vagrant.configure("2") do |c|
  c.vm.box = "centos_6.5"
  c.vm.box_url = "https://s3.amazonaws.com/o2o-public/centos_6.5_x86_64_provisionerless.box"
  c.vm.network(:private_network, {:ip=>"33.33.33.113"})
  c.vm.synced_folder ".", "/vagrant", disabled: true
  c.vm.synced_folder "/Users/jreid/repo/O2O", "/home/adsummos/analytics", create: true, type: :nfs
  c.vm.synced_folder "/Users/jreid/repo/portal", "/home/adsummos/portal", create: true, type: :nfs
  c.vm.provider :virtualbox do |p|
    p.customize ["modifyvm", :id, "--memory", "4096"]
  end
end

And while I can still kitchen login $box from the cookbook directory or vagrant ssh $box from the VM's directory, the key pair installed does not match the insecure key stored at ~/.vagrant.d/insecure_private_key.

IE, I can't successfully ssh -i ~/.vagrant.d/insecure_private_key vagrant@ either the IP or DNS.

Any thoughts? It's confusing that I do not see the "generating new key" output in kitchen create, but that the correct ssh configs do not seem to populate down from the .yml file to the generated Vagrantfiles either.

Versions:

• kitchen-vagrant (0.15.0)
• Test Kitchen version 1.3.1
• Chef Development Kit Version: 0.4.0

[Joseph-R]

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.

ruby_block "Add insecure_key into vagrant user's authorized_keys" do
  block do
    fe = Chef::Util::FileEdit.new('/home/vagrant/.ssh/authorized_keys')
    vagrant_insecure_pub_key = <<-STR 
      ## Put the pub key corresponding to your private key here.
    STR
    fe.insert_line_if_no_match(/vagrant\ insecure\ public\ key/, vagrant_insecure_pub_key)
    fe.write_file
  end
end

It's hacky, but it works.

[xacaxulu]

+1

[lmeyemezu]

Hi,
has anyone found a workaround for that ?
I tried a lot of soultions but none seems to works.
from kitchen create, i get
default: Warning: Connection timeout. Retrying...
default: Warning: Connection timeout. Retrying...
STDERR: Timed out while waiting for the machine to boot. This means that
Vagrant was unable to communicate with the guest machine within
the configured ("config.vm.boot_timeout" value) time period.
from vagrant, i get
default: Adapter 1: nat
==> default: Forwarding ports...
default: 22 => 2200 (adapter 1)
==> default: Booting VM...
==> default: Waiting for machine to boot. This may take a few minutes...
default: SSH address: 127.0.0.1:2200
default: SSH username: vagrant
default: SSH auth method: password
default: Warning: Connection timeout. Retrying...
default: Warning: Connection timeout. Retrying...
default: Warning: Remote connection disconnect. Retrying...
default:
default: Inserting generated public key within guest...
default: Removing insecure key from the guest if it's present...
default: Key inserted! Disconnecting and reconnecting using new SSH key...
==> default: Machine booted and ready!

[lmeyemezu]

@Joseph-R
hi,
how do i use your use ruby_block ?
Regards

[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 development environment (for us).

[lmeyemezu]

@Joseph-R
thanks a lot !!!

[cheeseplus]

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.

[cheeseplus]

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.

[brianbaquiran]

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.

[stephenlauck]

I've confirmed this issue too with centos boxes using chefdk 16.x

[shortdudey123]

Global Vagrant file workaround worked for me
#130 (comment)

Sounds like it will be fixed on the Vagrant side in the 1.8.6 released (already fixed on Vagrant master)