"Warning: Authentication failure. Retrying... " after packaging box

[zunayed]

I am able to vagrant up and have ssh running fine from a base box that I've provisioned. I then package up the said box and keep getting errors with ssh. I've packaged numerious boxes before with this same process just yesterday. Not sure what the issue is now.

vagrant package --base "<name from VBoxManage list vms>" 
vagrant box add mypackagedbox package.box

modified the Vagrant file config.vm.box = "mypackagedbox"

vagrant up now hangs on Warning: Authentication failure. Retrying..

I have tried with vagrant 1.7.1 & 1.7.2. Virtualbox version is 4.3.12r93733

vagrant file - http://pastie.org/9832360

[asafvilman]

same thing here, found this http://comments.gmane.org/gmane.comp.tools.vagrant/4453 but couldnt make it happen...can anyone help?

[zunayed]

Seems like an ssh issue vagrant ssh-config on the base provisioned box(hashicorp/precise32) looks like it loads the identity file from .vagrant directory of the project

  vagrant ssh-config
  Host default
    HostName 127.0.0.1
    User vagrant
    Port 2222
    UserKnownHostsFile /dev/null
    StrictHostKeyChecking no
    PasswordAuthentication no
    IdentityFile /Users/zmorsalin/projects/vagrant_templates/project/.vagrant/machines/default/virtualbox/private_key
    IdentitiesOnly yes
    LogLevel FATAL"

But the packaged box that is failing loads it from/Users/zmorsalin/.vagrant.d/insecure_private_key

Host default
  HostName 127.0.0.1
  User vagrant
  Port 2222
  UserKnownHostsFile /dev/null
  StrictHostKeyChecking no
  PasswordAuthentication no
  IdentityFile /Users/zmorsalin/.vagrant.d/insecure_private_key
  IdentitiesOnly yes
  LogLevel FATAL

I've also tried looking in /etc/udev/rules.d but the only thing I saw was a empty folder called 70-persistent-net.rules. I removed it prior to packaging and the bug persist.

[melwinm]

Maybe there is no valid shh key loaded. Have you tried to set the key manually with config.ssh.private_key_path?

[patrickheeney]

Same thing here. The original box has an identity file in the .vagrant folder, and the package box uses insecure_private_key which causes the Warning: Authentication failure. Retrying...

Did anyone figure out how to get this working?

[zunayed]

@melwinm Tried setting the key manually and it still didn't work. I set config.ssh.insert_key = false and finally got the packaged box passed the Warning: Authentication failure. Retrying...

[mtchavez]

Something seems to have changed regarding this. I last successfully packaged a virtualbox box using the vagrant package command on Dec 15th, 2014. Trying again recently with Vagrant version 1.7.2 and virtualbox version 4.3.20 r96996 this issue started coming up for me. Obviously I am able to work around this by by setting the private key path and provisioning the authorized_keys correctly on the box.

Curious if it is a regression in one of the newer releases or if we are all missing something here. @zunayed said he saw this for 1.7.1 as well but that worked correctly for me last December. I also have never touched any of the ssh key stuff previously for packaging boxes without issue.

[patrickheeney]

I had to abandoned my base box because I could not get it working even after setting the ssh insert_key. I was using this box https://atlas.hashicorp.com/ubuntu/boxes/trusty64 . Not sure how this is related but after switching to the hashicorp box and setting the ssh insert_key, it was ok.

[mtchavez]

Interesting. I am also using the ubuntu/trusty64 box instead of a Hashicorp box. Wonder if those boxes are doing something different? There isn't an Ubuntu Trusty 64 box from them yet so I cant switch boxes.

Sort of interesting, I did try making another box from my last successful one in December. So without changing anything and simply packaging that box the issue showed up when I tried to use it. Anyone have any ideas why the Hashicorp boxes work versus the Ubuntu boxes?

[ghost]

I had the same problem - in the last week my Vagrant machines would all fail to come up with the Authentication failure. Retrying... message. Yet if you SSH'd into them manually all was fine. This happened both with boxes I'd built and were working fine and with Hashicorp boxes (precise64). I tried all combinations of setting config.ssh.insert_key and config.ssh.private_key_path with no results.

I couldn't think of anything I'd done in the intervening time to change the config except install the production release of Yosemite. So that was my first thought and I worked on other stuff. However I have two somewhat identical machines I work on - one at home (iMac 5k) where the failure was occurring and one at work (MacBook Pro). Both are treated almost exactly the same in terms of installed software:

• Mac OSX Yosemite 10.10.2
• Vagrant and plugins 1.7.2
• VMware Fusion 7.1.0

Both run Vagrantfile configurations in several GitHub projects checked out the same on both machines and so identical. So when I next used the work machine I expected the vagrant up command to fail. Yet you guessed it: they were all fine! I carried on and got some work done.

Today, working from home, I proceeded to switch out things to see if it made any difference - out went rvm, out went environment variables VAGRANT_VMWARE_CLONE_DIRECTORY and VAGRANT_DEFAULT_PROVIDER. Deleted the .vagrant directory to force a rebuild. Nothing worked.

So then I did the Windows thing: Re-installed Vagrant from scratch. Everything worked again. I still don't know why and although I kept copies of the 'bad' directories (/opt/vagrant and ~/.vagrant.d) I've lost too much time to this to do any more debugging. Try it!

[lordgordon]

Hi there, same issue happened to me. After a new repackage of a working box, based on CentOS, ssh authentication stopped working, as described in previous comments. I set up a new private key as workaround, so I no longer need to rely on the insecure key setup. Yet, very frustrating. I lost a full day of work.

Host machine: OS X Mavericks Vagrant: 1.7.2 Guest machine: Linux CentOS 6.5

[tierpod]

Host machines: Ubuntu 12.04, 14.04. Vagrant 1.7.2, Virtualbox 4.3.10 and 4.1.12 Guest machines: Centos 6.5 x32, Centos 6.5 x64, Centos 7

Same problem.

[kikitux]

Adding here my impressions for people that find this issue from google/internet:

This is my point of view here.

The source box use the insecure key by default the actual version of vagrant will remove it, to make it secure the new box, use a generated pair key.. that is not being used anymore vagrant can't connect to the new box.

You have 3 options here.

A. Tell vagrant in the middle box to NOT create a new safe/secure pair. B. Run an Script before packaging to delete 70-persistent-net.rules and put back the insecure pair key C. Copy the new now secure pair to /vagrant and include it in the package box plus Vagrantifle conf to use it

I will say, if this is for prototyping, just use A, just remember delete 70-persistent-net.rules

On the first box, add: config.ssh.insert_key = false

[tierpod]

I have 2 Vagrantfiles:

• Vagrantfile before packaging (for creating my custom centos7.box, vm.box = "chef/centos-7")
• Vagrantfile using my custom centos7.box (vm.box = "centos7.box")

I solved my problem: option config.ssh.insert_key = false in both Vagrantfiles.

[bozic]

The insert_key false is not working for Ubuntu boxes (https://atlas.hashicorp.com/ubuntu). I'm trying with trusty32 and after packaging original box with config.ssh.insert_key = false I still get this warning (I'm packaging and Vagrantfile, so same option is included in new box).

[dylanschoenmakers]

So I encountered the same problem and spent some time figuring this out.

Here is what I did; I put config.ssh.insert_key = false in the Vagrantfile I am using to make the package box. Then vagrant up and ssh manually with a password into the box after it spits the error. Go edit the file ~vagrant/.ssh/authorized_keys and put the default insecure key in there that you will find on https://github.com/mitchellh/vagrant/blob/master/keys/vagrant.pub.

After that, package the box. @bozic You will need to vagrant box remove xxxx and vagrant box add xxxx xxxxx.box again, that helped in my case (it kept using the old box before that, even when I had overwritten the .box image).

Finally you should be able to use the box again.

[mtchavez]

I had found a solution to this and haven't had time to update this issue. I did something similar to what @dylanschoenmakers described.

The main thing which fixed it for me was adding the vagrant.pub to the authorized_keys with

wget https://raw.githubusercontent.com/mitchellh/vagrant/master/keys/vagrant.pub -O .ssh/authorized_keys
chmod 700 .ssh
chmod 600 .ssh/authorized_keys
chown -R vagrant:vagrant .ssh

Then when building the base box I think you need to add the config.ssh.insert_key = false to your Vagrantfile. If you built a new version of the box you can simply do a vagrant box update otherwise you can do what @dylanschoenmakers already mentioned to remove and re-add the box to get the newest box.

This all makes sense, but I am not clear on if this is something that needs to be documented or if there was indeed a change in Vagrant that used to do this transparently for previous versions which is broken now.

[yahyapo]

Surprisingly, this solved the issue for me :

Workaround for vagrant 1.7.2 : In file Vagrant/embedded/gems/gems/vagrant-1.7.2/plugins/communicators/ssh/communicator.rb line 171 : add .env after @machine : @machine.env.data_dir.join("private_key").open("w+") do |f|

Test OK : $ vagrant package --output ac-centos66.box --base ac-centos66 ==> ac-centos66: Attempting graceful shutdown of VM... ac-centos66: ac-centos66: Vagrant insecure key detected. Vagrant will automatically replace ac-centos66: this with a newly generated keypair for better security. ac-centos66: ac-centos66: Inserting generated public key within guest... ac-centos66: Removing insecure key from the guest if its present... ac-centos66: Key inserted! Disconnecting and reconnecting using new SSH key... ...

Thanks to @cdelaitre for the fix!

[ckhk212]

I followed @mtchavez direction above with the exception of adding --no-check-certificate when wget the key.

wget --no-check-certificate https://raw.githubusercontent.com/mitchellh/vagrant/master/keys/vagrant.pub -O .ssh/authorized_keys

But now my VM is back up and running.

[zunayed]

Glad most people got this resolved :+1:

[matt-holden]

@mtchavez your solution was a lifesaver!

[ruskotron]

I did the @mtchavez workaround above - reprovisioning the public key for both vagrant and root users.

Exited, vagrant halt, and a new keypair was generated. All works well now!

$ vagrant halt ==> blah: Attempting graceful shutdown of VM... blah: blah: Vagrant insecure key detected. Vagrant will automatically replace blah: this with a newly generated keypair for better security. blah: blah: Inserting generated public key within guest... blah: Removing insecure key from the guest if its present... blah: Key inserted! Disconnecting and reconnecting using new SSH key...

[panjie]

Followed @mtchavez workaround but still not work for me, which is a box of Ubuntu 14.04 64bit, running on Mac OSX 10. After some digging, I found the Vagrantfile coming with the re-packaged box (~/.vagrant.d/boxes/xxx/0/virtualbox/Vagrantfile) has the following lines in it:

Vagrant.configure("2") do |config|
  config.ssh.private_key_path = File.expand_path("../vagrant_private_key", __FILE__)
end

I think this is the reason why vagrant doesn't use the default insecure key in vagrant up, and why @mtchavez workaround not works. After deleting these lines, the new vm initialized by the box will vagrant up normally(which means vagrant will find out the insecure key is used and replace it with a generated key-pair).

So, how can I prevent vagrant to generate these lines when re-package boxes?

[Rustem]

I think I finally realized the main core of the problem. When you create your base-box with config.ssh.insert_ssh_key = true (default behaviour) it sets it random private/public key pair. Private key is set on your host machine at .vagrant/machines/default/{provider}/private_key and public key is set on VM at ~/.ssh/.authorized_keys. So when you package the box and publish it, everybody who will add this box, will have such problems with ssh connection since latest randomly generated key at ~/.ssh/.authroized_keys has no private key match.

So if you are going to build your own box and publish it to cloud, then configure your Vagrantfile with config.ssh.insert_key=false, then do required setup on VM and finally package & publish it.

[aressler38]

Thanks @mtchavez and @ckhk212; that worked for me too. I set my vb.gui to true so I could login through virtualbox. Meanwhile, vagrant was also trying to login. Vagrant immediately logged in after I added the key through the virtualbox gui:

wget --no-check-certificate https://raw.githubusercontent.com/mitchellh/vagrant/master/keys/vagrant.pub -O .ssh/authorized_keys

I'll run that before packaging my virtual box next time.

[jrgriffiniii]

Thank you @mtchavez!

[kluplau]

I have the same issue, and the fix provided by @mtchavez does't work.

When I run vagrant ssh-config it shows that I have two IdentityFile settings. I suspect this to be my issue. Where can I edit this?

[aressler38]

I'm not sure why you have two IdentityFile settings, but maybe try setting the default username/password in the Vagrantfile for ssh.

config.ssh.username = 'vagrant' config.ssh.password = 'vagrant'

If that doesn't work then try turning on the gui so you can logon to the box: http://docs.vagrantup.com/v2/virtualbox/configuration.html After that, you should be able to check ~/.ssh/authorized_keys.

http://docs.vagrantup.com/v2/vagrantfile/ssh_settings.html

[BitBrit]

I'm not sure @mtchavez and @dylanschoenmakers steps make complete sense. To build my box I used vagrant package on a brand new VM. Vagrant attempted to stopped my VM but detected that the insecure key was used so it replaced it. It then lost the ability to log in to the VM so it force stopped the VM and continued to package it into a .box file.

From here I started a VM using this box file and Vagrant again couldn't gain access:

default: Warning: Authentication failure. Retrying...

I then went into the VM, re-added the insecure key to authorized keys file and then added

config.ssh.insert_key = false

to my Vagrantfile. I repackaged the box and this time the insecure key wasn't replaced. However, when I started another VM from the new box file I got the following:

default: Vagrant insecure key detected. Vagrant will automatically replace
default: this with a newly generated keypair for better security.
default:
default: Inserting generated public key within guest...
default: Removing insecure key from the guest if its present...
default: Key inserted! Disconnecting and reconnecting using new SSH key...
default: Warning: Authentication failure. Retrying...
default: Warning: Authentication failure. Retrying...

Why does Vagrant insert a key that then removes its own access?! Why does it not know where the private key is for the pair it had just created? Is this a different error to the one described above?

This is the ssh config: $ vagrant ssh-config Host default HostName 127.0.0.1 User vagrant Port 2222 UserKnownHostsFile /dev/null StrictHostKeyChecking no PasswordAuthentication no IdentityFile /Users/grhill/.vagrant.d/insecure_private_key IdentitiesOnly yes LogLevel FATAL

I couldn't find the the private side of the public key Vagrant had just inserted into the VM. It's not in "vagrant/machines/default/virtualbox".

[LindesRoets]

This is still an issue with Vagrant 1.7.3 and Virtualbox 5.0.

Adding back the insecure key and adding "config.ssh.insert_key=false" to the Vagrant file solved it as mentioned earlier.

[ckhk212]

Hey @LindesRoets, try to use VirtualBox 4.3.. and the menthod @mtchavez mentioned should work! Good luck

[LindesRoets]

@ckhk212 , I did get it to work on VirtualBox 5.0 and Vagrant 1.7.3 as noted in my earlier post. Thanks.

[robme]

Everything was working fine for me on Vagrant 1.7.2. I upgraded to Vagrant 1.7.4 and now I get this problem. I'm using Puphpet to generate my Vagrantfile. I wonder if something was changed that makes what Puphpet does and what Vagrant does incompatible.

[benjah1]

I have the same problem as @robme. It works fine on 1.7.2 and fails on 1.7.4

[litzinger]

Same issue as @robme and @benjah1. I reverted to 1.7.2 and my vagrant up now works for me.

[robme]

I can get it working with 1.7.4 by deleting everything in puphpet/files/dot/ssh except for _insecure_privatekey. However, if I do vagrant_destroy and then vagrant up then it happens again, until I delete those files again.

[DennisBecker]

Me and two colleagues have the same issue, upgrading from 1.7.2 to 1.7.4 kills everything, you cannot boot a box, or even destroy the old one and create a new one with vagrant up runs into this issue.

After vagrant changes the ssh keys it cannot authenticate anymore.

[adamburvill]

Same problem for me with latest Vagrant and a puhphet ubuntu box. Ended up added config.ssh.insert_key=false to my Vagrantfile and it seems to be working OK (tho I had to destroy my machine and start again).

[doctapp]

Same problem using vagrant 1.7.4 and VirtualBox 5.0

[alexz707]

Same problem here, vagrant 1.7.4 Vbox 5.0 + puphpet on OSX

[matti]

sama here, OSX vagrant 1.7.4, vbox 5.0. it seems like it does not use the newly generated key after disconnect and reconnect?

[Kelthan]

I find an other solution to this problem.

1) Add the vagrant insecure public key to ~vagrant/.ssh/authorized_keys 2) Stop the virtual machine with Virtualbox GUI 3) Delete the private key file ".vagrant\machines\default\virtualbox\private_key" before packaging your box. Like that, Vagrant will not add the following option in the default Vagrantfile and will instead use the default vagrant private key:

Vagrant.configure("2") do |config|
  config.ssh.private_key_path = File.expand_path("../vagrant_private_key", __FILE__)
end

4) Package your box

[jazzfog]

I have the same problem as topic starter.

Windows 10 Vagrant 1.7.4 VirtualBox 5.0.1 Original image: puphpet/ubuntu1404-x64 (virtualbox, 2.0)

In my case I fixed it adding to Vagrantfile login and password:

config.ssh.username = 'vagrant' config.ssh.password = 'vagrant'

[agemmell]

Adding my 2 cents. Exact same problem here. Setting up a brand new Macbook pro so I installed the latest VirtualBox (5.0) and Vagrant (1.7.4). I removed those and installed Vagrant 1.7.2 and VirtualBox 4.3.18 (which is a working combination on a different computer) and that worked.

[PanadeEdu]

Same Problem currently on Windows 10 with VMWare Workstation 11 and newest Vagrant VMWare Plugin and Vagrant 1.7.4. Workaround aswell with password, but this cant be the ultimate solution.

[htesligte]

I fixed this issue with removing this line from my vagrantfile: config.ssh.private_key_path = [ '~/.vagrant.d/insecure_private_key', '~/.ssh/id_rsa' ]

For me, the issue was also all of a sudden. Everything worked without issue for months and just today I wasn't able to boot into the machines anymore. Even changing the line to: config.ssh.private_key_path = [ '~/.vagrant.d/insecure_private_key' ] didn't make a difference. I just commented every line from my Vagrantfile except the name and then added the lines back one by one.

Vagrant version: 1.7.4 VirtualBox version: 5.0.0

[Gerst20051]

Adding config.ssh.insert_key = false to the Vagrantfile and removing the new vm private key .vagrant/machines/default/virtualbox/private_key vagrant automatically updates vagrant ssh-config with the correct private key ~/.vagrant.d/insecure_private_key. The last thing I had to do was ssh into the vm and update the authorized keys file on the vm. curl https://raw.githubusercontent.com/mitchellh/vagrant/master/keys/vagrant.pub > ~/.ssh/authorized_keys

[miljan-aleksic]

@jazzfog, your solution worked for me, thanks :)

[fretwellian]

Having the same issue Vagrant 1.7.4, but VirtualBox 4.3.20. Copied @Carzeh, destroyed and added config.ssh.insert_key=false

[doctapp]

The fix from @jazzfog worked for my existing boxes (though vagrant ssh still needs the password).

[Gerst20051]

@miljan-aleksic @fretwellian @doctapp i wrote the real solution right above. if you have any questions let me know...