Vagrant: "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_private_key_. 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.

[Carzeh]

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

[mehdi-ghezal]

Thanks to @dylanschoenmakers and @mtchavez for the solution

[rajat404]

I encountered the same issue on a ubuntu/trusty64 box, while running on an Ubuntu 14.04 Host machine. The above mentioned solutions didn't work for me.
Here is how I was able to solve the problem:

1) Run ssh-add ~/.vagrant.d/insecure_private_key
2) In your Vagrantfile, add: config.ssh.private_key_path = "~/.vagrant.d/insecure_private_key"
3) Do vagrant halt and then vagrant up.

While it's a trivial solution, it worked for me.

Note: To check that changes are applied, Run vagrant ssh-config
The output should be something like:

Host default
  HostName 127.0.0.1
  User vagrant
  Port 2222
  UserKnownHostsFile /dev/null
  StrictHostKeyChecking no
  PasswordAuthentication no
  **IdentityFile /home/\<username>\/\<your-vagrant-directory\>/.vagrant/machines/default/virtualbox/private_key**
  IdentitiesOnly yes
  LogLevel FATAL
  ForwardAgent yes

[ruskotron]

Absolutely the stupidest feature ever.

[adiachenko]

This is a joke.

[riyadparvez]

This seems such a severe bug and they don't have any urgency to fix this bug.

[ruskotron]

Vagrant is yesterdays news it seems https://hashicorp.com/blog/otto.html

[thesteve0]

Any chance of a bug fix coming on this one. I noticed there is not even someone assigned to it - I guess this does not bode well.

[PanadeEdu]

The Blog post mentions the support of vagrant. Otto is no option right now,
since it seems to be less configurable. They should simply fix the current
issues.

People like me invested money in Vagrant seats that now have a buggy state.
It is no excuse to simply focus other projects.
Am 12.10.2015 11:35 schrieb "Matt" [email protected]:

Guessing their focus right now is on Vagrant's successor, Otto
https://ottoproject.io/

—
Reply to this email directly or view it on GitHub
https://github.com/mitchellh/vagrant/issues/5186#issuecomment-147348127.

[ColorFuzzy]

I solve this by following steps(vagrant version 1.7.4):

1. rm ~/.vagrant.d/insecure_private_key (remove old key, this step may be passed)
2. vagrant destroy # destory old machine (may be passed, too)
3. add following lines to Vagrantfile(password is used for set the ssh-key)
   config.ssh.username = "vagrant"
   config.ssh.password = "vagrant"
4. vagrant up to create new machine(this step will generate new ssh-key and send it to the new machine)
5. comment/remove that two lines(we already send our new key to new machine)
6. then you can ssh in without password

[markus-perl]

Using the config.ssh.username and config.ssh.password was already posted several times, but is not recommended in any way because it weakens the security of your box to a placebo level if it is not disabled after setting up your machine. If you work on a network, where other people can connect to your computer, everyone is now able to have a look at your source code by establishing a simple ssh connection with the user vagrant and the password vagrant to your machine.

[ruskotron]

I never wanted the feature where Vagrant does this for me, much less that it does a bad job of it.

My approach to this was to just generate my own keys ... http://www.linuxproblem.org/art_9.html I personally don't see this as a huge inconvenience and it is preferable to some 'free' third party tool deciding to do it for me, without even consulting me!

Precisely for the reason @marcus-perl describes - if security is too complex (as it is in this case) users will weaken the security. But if I'm administering it there is no problem like that, and what's more "I" am responsible for making it work and I don't have to go fluting around on message-boards trying to find out about secret configuration options!

[iluwatar]

Using Vagrant 1.7.4 - adding config.ssh.insert_key = false into the Vagrantfile solved the login problem.

[joelanman]

thanks @mtchavez that got it working for me

[nroose]

Setting config.ssh.private_key_path worked for me.

[psychok7]

for me only setting config.ssh.username = "vagrant" and config.ssh.password = "vagrant" did the trick

[adiachenko]

I've found @mtchavez solution to be the best one when it comes to building vagrant boxed that will be shared with other people. But it is still a hack and, more importantly, a pain to remember each time you update your box. It's not even documented. Go guess. As it stands now, it's more convenient to simply write shell provisioners than building finished boxes to avoid messing with ssh keys after each update.

[sebastianwestberg]

Ran into this problem after updating to 2.5. @mtchavez solution worked well for me.

[sethvargo]

GH-6406

[sethvargo]

@mitchellh is going to do some more testing with GH-6406 and https://github.com/mitchellh/vagrant/commit/1a7937ed50d767f328463978584f07ad546e456f

[robhadfield]

Thanks @jazzfog - your solution on https://github.com/mitchellh/vagrant/issues/5186#issuecomment-127539148 worked for me too.

:+1:

[mitchellh]

This is all fixed up.

[mitchellh]

See #5780

[gibsonje]

This is marked as fixed, but is it only fixed in the latest version? I'm using vagrant 1.7.2 due to having severe, breaking issues with the salt provisioner in 1.7.3, 1.7.4. I'm having this issue when packaging boxes in 1.7.2.

[sethvargo]

Hi @gibsonje

We do not backport fixes onto released versions. This will be in Vagrant 1.8.

[gibsonje]

None of the fixes described in this thread are working for me.
~/.ssh/authorized_keys already has the insecure public key, so most of the fixes described in here involving putting that same key there I don't understand.

I tried creating the host with config.ssh.insert_key = false and packaging, but there was no change.

I'm at wit's end trying to package a box in vagrant 1.7.2.

edit: Yes! After many attempts I've got it working. Protip: Take a snapshot after your VM is fully configured for boxing or you'll have a bad time iterating & re-trying the steps in this thread.

[masitko]

I had the same issue using Puphpet and Vagrnat 1.7.4.

Removing file puphpet/files/dot/ssh/id_rsa fixed it for me.
File was recreated again during vagrant up

[astrashe]

Hi. I was seeing the same problem with Vagrant 1.8.1 using a Centos 7 base box that I built myself. When I looked into what was happening, I discovered that Vagrant was able to remove the insecure key but was failing to add the new key to the authorized_keys file.

I was able to get things to work by changing the StrictModes setting in the box's /etc/sshd_config to no. I'm not exactly sure what's going wrong when StrictModes is left at the default value of yes. I looked at the code, and it looked reasonable. Maybe sshd has changed its behavior in some way.

One fairly obvious point to raise is that it seems likely to me that these errors are being caused by different things on different people's systems. I think my problem here was something new, as it it didn't hit until recent updates in Centos 7.

Would it make sense to change the key substitution process to make it more robust? Perhaps a new key could be added before the insecure key was deleted. Once Vagrant was able to verify that it could connect with the new key, it could delete the old one. If that failed for some reason, Vagrant could continue to connect with the insecure key and print a warning.

[ghost]

I've been playing with this today. Maybe it's already established what is wrong, but it's spread across threads and comments, so here's a summary for other folks.
The issue starts when you first launch a downloaded box, not when you're customizing that image.

Bad workflow:

cd ~/sampleDirectory
vagrant init centos/7
vagrant up
# make modifications
vagrant package --base centos_default_${uniquifier} --output my.new.box

Result is that my.new.box is baked containing the authorized_key that was generated when vagrant up ran. The private key for that authorized_key lives in ~/sampleDirectory/.vagrant/machines/default/virtualbox/private_key. This is just a randomly-generated key and at no point will it travel along with that box.

Workaround workflow:

cd ~/sampleDirectory
vagrant init centos/7
# now add "config.ssh.insert_key = false" to ./Vagrantfile
vagrant up
# make modifications
vagrant package --base centos_default_${uniquifier} --output my.new.box

This time the insecure installed key is still the key used. When the box is baked it will contain the default insecure key and future launches will work correctly.

The important part is to always start with the insecure public key in authorized_keys if you want to create a share-able box.

IMO, the solution should just be another arg on package.

vagrant package --base centos_default_${uniquifier} --output my.new.box --public

And the public flag just means regardless of the current key, set the baked box to use the insecure key so everyone can use it.

Also, just because this may help others, centos/7 can be a pain to get working. Here's the procedure for a re-usable image...

vagrant plugin install vagrant-vbguest
mkdir centos7
cd centos7
vagrant init centos/7
# add 'config.ssh.insert_key = false' to Vagrantfile
vagrant up # the guest additions will likely fail because of a newer kernel-devel in the repo
vagrant ssh
sudo yum -y update
exit
vagrant reload # the guest additions will succeed
vagrant ssh
# make changes that you want to persist
rm .bash_history && history -c && exit
vagrant package --base centos_default_${uniquifier} --out ~/my.new.box

Now you can 'vagrant box add --name centos/7-updated ~/my.new.box' and should not have any issues with connecting and auto-configuring the node (chef-solo in my case).

Tested with VirtualBox 5.0.12, Vagrant 1.8.1, OS X Yosemite (10.10.5).

[tomleo]

My Workaround

1. vagrant up
2. On vagrant box: Add id_rsa.pub to ~/.ssh/authorized_keys
3. Add config.ssh.private_key_path = "home/<you>/.ssh/id_rsa" to Vagrantfile
4. ssh-keygen -f "/home/tom/.ssh/known_hosts" -R 192.168.33.10

Now you should be able to passwordless login with: ssh [email protected] and vagrant up will stop throwing a warning.

[rajinders]

I ran into this issue as well. My host computer where i built the base image is running Windows 7 64bit. I am on the latest vagrant and virtualbox. I built a Windows 2012 R2 VM. I packaged it. I was not aware of this issue. I made the box available via atlas. On my home PC that is running windows 10 64bit I was getting authentication failures. I saw the fixes suggested here so I started over.
However on my host computer building the base VM and box I changed the vagrant file:

"config.ssh.insert_key = false"

I configure the VM.
I packaged the box again.
Once again I am getting authentication failures.
I can fix the issue by setting

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

However this is not a great solution.

I have seen a lot of solutions posted but most of them are for Linux VM's.
Has anyone been able to fix this issue when the OS for the box is Windows.
I can use Winscp to copy a new private key into the new Box but I don't think I want my users using the box to have to go through this.

Let me know if I you have any suggestions for me.

[theorician]

@frsalamo This doesn't help. None of the solutions help. Go and try this.
Without adding the config.ssh.insert_key = false business, go and made some modifications to your box, then do:

vagrant ssh -c 'wget -k https://raw.githubusercontent.com/mitchellh/vagrant/master/keys/vagrant.pub -O ~/.ssh/authorized_keys; chmod -R 700 ~/.ssh'
wget -k https://raw.githubusercontent.com/mitchellh/vagrant/master/keys/vagrant -O ./.vagrant/machines/default/virtualbox/private_key
chmod 700 ./.vagrant/machines/default/virtualbox/private_key
vagrant package --output output.box

Then try in another vagrantfile which points to this output.box to vagrant up. You'll get:

==> default: Box 'file:///home/user/output.box' could not be found. Attempting to find and install...
    default: Box Provider: virtualbox
    default: Box Version: >= 0
==> default: Box file was not detected as metadata. Adding it directly...
==> default: Adding box 'file:///home/user/output.box' (v0) for provider: virtualbox
    default: Unpacking necessary files from: file:///home/user/output.box
==> default: Successfully added box 'file:///home/user/output.box' (v0) for 'virtualbox'!
==> default: Importing base box 'file:///home/user/output.box'...
==> default: Matching MAC address for NAT networking...
==> default: Setting the name of the VM: test_default_1455567892827_354
==> default: Clearing any previously set network interfaces...
==> default: Preparing network interfaces based on configuration...
    default: Adapter 1: nat
==> default: Forwarding ports...
    default: 22 (guest) => 2222 (host) (adapter 1)
==> default: Booting VM...
==> default: Waiting for machine to boot. This may take a few minutes...
    default: SSH address: 127.0.0.1:2222
    default: SSH username: vagrant
    default: SSH auth method: private key
    default: 
    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 it's present...
    default: Key inserted! Disconnecting and reconnecting using new SSH key...
    default: Warning: Authentication failure. Retrying...

It actually can connect - because you replaced the ssh keys with the insecure ones again, after all - and replaces the keys, and then promptly goes and f*s itself.

Why can't you use config.ssh.insert_key = false? For example when you've converged as part of a
Kitchen workflow. kitchen.yml does not allow you to set false booleans, because it treats them as strings, which are truthy.

... yay.

[speedlight]

The process of @frsalamo works for me, the option of @theorician works too. I think is the way to go, but even when @mitchellh made GH-5310 looks like is stil not working out-of-the-box. Im with 1.8.1.

[ArialBlack]

config.ssh.username = 'vagrant'
config.ssh.password = 'vagran
worked for me

[CharlieKuharski]

I had a same issue after I had created and added my new box.
What worked for me:

1. vagrant box remove newbox
2. vagrant box remove OLDbox
3. Vagrantfile =>

config.vm.box = "newbox"
config.ssh.username = "vagrant"
config.ssh.password = "vagrant"

1. vagrant up

Now, I'm back in business.

[TRPB]

This is just a "me too" but I'm really not sure what triggers this. I created a base box 6 months ago, I've updated it several times. Today I updated pretty much all the software, it was working ok.. I recompiled some kernel modules, packaged it again and now I get this error.

Oddly it was working, then it stopped without me touching the .pub file or any keys on the guest or host...

[astrashe]

A couple of points:

1. Swapping out the key is a moderately complex process, and if it fails for almost any reason, you'll see this error. So lots of us have been talking about different problems here.
2. I think that OpenSSH has been hardened a bit, and that some recent changes cause Vagrant's key replacement system to fail, when all other things are the same. This isn't because Vagrant is doing something different or wrong, it's because the Guest OS's version of OpenSSH has been updated. You can get around it by turning off StrictModes in the guest OS's sshd_config file.

[gibsonje]

I keep getting emails with replies to this. My 2 cents: No fix I try for this is consistently working. I've since given up on creating base images using Vagrant. Waiting for some regressions to be fixed in newer vagrant versions so I can move on.

[TRPB]

I tried that along with pretty much every other solution here, StrictModes is set to off, same error.

The only one that works is config.ssh.insert_key = false which is obviously just a hack. The problem is that when the key is inserted, it's inserted wrongly.

I can actually somewhat see what's wrong. After

Key inserted! Disconnecting and reconnecting using new SSH key...
Warning: Authentication failure. Retrying...

Log into the box normally (or via virtualbox gui shell) ls /home/vagrant/.ssh shows authorized_keys as zero bytes.

`

[markus-perl]

Using vagrant as username and password is just a workaround and not a solution for me due to security reasons. Vagrant generates a new ssh key for a new machine but then continues to use the old key. I already investigated the issue and provided a working patch https://github.com/markus-perl/vagrant/commit/61466c8e65b476b2d580a0eca06c7512026118c0 to the vagrant team. Without applying the patch the problem still exist for me even in the latest version.

[astrashe]

TomBZombie: Don't give up, you're almost there! Check the logs to see why the key insertion is failing. Double check your file perms and ownership. If you're on a Mac or a Linux host, try using the command line scp program to copy a key file in manually, and see what that tells you about what's going on.

[TRPB]

Aha, in my case, the problem was actually something else, in my software upgrade spree and tweaks to the box I had actually used up all the space on the virtual disk so the key couldn't be written. This was entirely my fault, but Vagrant reporting Key inserted! Disconnecting and reconnecting using new SSH key... could really do with a better message if the key isn't copied successfully!

[CelsoSantos]

I have this issues on OS X 10.11.4, running Vagrant 1.8.1 and VirtualBox 5.0.16..

This is a box I've created and packaged myself, once I give it to any other of my fellow developers, every single one of us hits this brick wall..

[knappador]

@CharlieKuharski saved my night. After removing the box our config lead resulted in me getting a pre-baked image for lxc and life became not sucky.

[bvi1998]

@jazzfog your solution worked for me! Hours and hours of work, and your solution has me back up and running.
My issue was that even though I had deleted the config.ssh.private_key_path from the vagrantfile, it kept reading the old value. I knew this from the vagrant ssh-config file. I removed all references to a private key path and added
config.ssh.username = "vagrant"
config.ssh.password = "vagrant"
This all occurred after updating Vagrant to version 1.8.1 and Virtual Box to Version 5.0.16 r105871

Thanks!

[sthum]

@mtchavez saved my day.
Worked for me using ubuntu/trusty64

As far as I can see the prepared boxes like ubuntu/trusty64 already have the insecure key in them. Just take care to use config.ssh.insert_key = false before initially booting the VM.

If you accidentally booted the VM with config.ssh.insert_key = true (which is default) the key gets replaced and you will have troubles porting the VM. Then you simply need to do:

1) add config.ssh.insert_key = false to Vagrantfile
2) vagrant halt && vagrant up && vagrant ssh
3) inside the VM:

wget --no-check-certificate 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

Just take care to always use config.ssh.insert_key = false when developing a new box as otherwise the Key gets replaced at the next VM boot, like it happened to me :D

[kevinheins]

@mtchavez fixed up my issue, thanks a bunch!

[TRPB]

For some reason I'm having the same problem again, the authorized_keys file is zero bytes and this isn't because the guest's disk is full. If after Warning: authentication failure. Retrying... I manually run ssh-copy-id it works fine. I've tried various configurations for sshd_config and checked the permissions of the .ssh directory (700) and the authorized_keys file I've checked both ownership and group of the file, I'm really not sure what else to try.

[astrashe]

@TomBZombie If you haven't tried it yet, edit /etc/ssh/sshd_config on the guest and set StrictModes to no.

[TRPB]

I've tried that, I've also tried commenting and uncommenting RSAAuthentication yes and PubkeyAuthentication yes which was mentioned elsewhere. It doesn't seem to help. authorized_keys is zero bytes after vagrant up.

[TRPB]

Aha! After lots of trial and error I figured it out. I was trying to make my .box file as small as possible by removing everything that wasn't required for my dev box, it turns out that vagrant doesn't use ssh-copy-id but a custom command that is dependent on sed. I reinstalled sed and and it works. It would be really helpful if Vagrant reported errors directly back from bash.. if i'd seen "sed: command not found" it would have saved me a couple of hours tracking it down.

[keithel]

I've also been bitten by this issue.
@frsalamo 's solution works for me, but I have a slight modification of it so it can be fully automated in a script. See Modified workflow below.

I have Vagrant 1.8.1 installed on Ubuntu 14.04 (trusty), and trying to repackage the 'ubuntu/trusty64' box with a larger disk image. Same issues everyone else was having:

==> default: Waiting for machine to boot. This may take a few minutes...
    default: SSH address: 127.0.0.1:2222
    default: SSH username: vagrant
    default: SSH auth method: private key
    default: Warning: Authentication failure. Retrying...

Modified workaround workflow:

cd ~/sampleDirectory
vagrant init centos/7

# now add "config.ssh.insert_key = false" to ./Vagrantfile
vagrantfile_backup=$(mktemp Vagrantfile.XXXXXXX.tmp)
awk '{ print $0 }; /config.vm.box / { print "  config.ssh.insert_key = false"}' Vagrantfile > $vagrantfile_backup
cat $vagrantfile_backup > Vagrantfile
rm $vagrantfile_backup

vagrant up
# make modifications
vagrant package --base centos_default_${uniquifier} --output my.new.box

[irinadrozdova]

Steps that helped me:

• add to vagrant file

config.ssh.username = "vagrant"
config.ssh.password = "vagrant"

• vagrant reload
  type password: vagrant
• comment out lines that you added as:

#  config.ssh.username = "vagrant"
#  config.ssh.password = "vagrant"

• vagrant reload
  now auth is private key
• vagrant ssh - works for me.

[AseemKumar]

The above methods did not work for me for some reason. This worked for me.

I put in these in the vagrant file and booted the machine. Then halted it, and removed the lines. Even though insert ssh key parameter was set to false, Vagrant still inserted a new key and on the 2nd boot, after commenting these lines, it works with private key auth.

host_config.ssh.username = "vagrant"
host_config.ssh.password = "vagrant"
host_config.ssh.insert_key = "false"

Output on 1st boot:

SSH address: 127.0.0.1:2222
SSH username: vagrant
SSH auth method: password

Inserting generated public key within guest...
Removing insecure key from the guest if it's present...
Key inserted! Disconnecting and reconnecting using new SSH key...

Output on 2nd boot:

Waiting for machine to boot. This may take a few minutes...

SSH address: 127.0.0.1:2222
SSH username: vagrant
SSH auth method: private key
Machine booted and ready!

[Mortek]

After hours and hours of going through every post on the internet i finally found the cause of my issue. @aressler38 gave the correct answer for me. By adding the following info to my vagrantfile I get past the "Warning: Authentication failure. Retrying...".

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

[aburgd]

I had my Vagrantfile for the Ubuntu/Trusty64 box set up with config.ssh.insert_key = true and didn't specify private_key_path, and it works just fine now.

[brianpeiris]

With Vagrant 1.8.0 (and 1.8.1), you can avoid this issue using vagrant package --base <id>. Where --base is the important bit. <id> is the name or UUID of the VirtualBox machine. This will disable insert_key for you. However, you still need to wget the vagrant.pub key as mtchavez instructed above. This key will automatically be replaced when the users of the distributed box perform vagrant up.

[BodhiHu]

@Mortek, worked for me : )

Vagrant 1.7.4

[mloskot]

I'm using Vagrant 1.8.1 and my newly packaged Linux boxes suffered from the same bug.

@mtchavez 's workaround in https://github.com/mitchellh/vagrant/issues/5186#issuecomment-81409295 has worked for me.

[mmeylan]

Had the same problem when packaging a new box with vagrant 1.8.3 and @mtchavez's answer worked for me !

[esciara]

Had the same problem with vagrant 1.8.3 on mac.

vagrant box remove my-box then vagrant box add --name my-box path/to/my/box/my-box-file.box resolved the problem for me. (box created with packer 0.10.1 and templates from https://github.com/boxcutter/ubuntu using packer build -only=virtualbox-iso -var-file=ubuntu1604.json ubuntu.json)

@mitchellh should this ticket not be reopened?

[richardoswald]

insecure_private_key was not detected using Vagrant 1.8.5 with a centos-7.2 box with Test Kitchen running on OS X 10.11.5. Uninstalled and installed 1.8.1 to get it working again.

[rbjorklin]

This just happened to me when upgrading from 1.8.4 to 1.8.5.

[yupvr]

The same issue when upgrading from 1.8.4 to 1.8.5

[signed8bit]

Same here. I had to revert to 1.8.4 to get things working again.

[Tandolf]

Installed 1.8.5 vagrant yesterday, had troubles all day long with this issue with my companies boxes. Downgraded today to 1.8.4 and now boxes work. Is this a confirmed bug?

[xwf]

This is a known bug in 1.8.5: #7610

[rbjorklin]

If anyone need to use 1.8.5 I was able to work around this with config.ssh.insert_key = false.

[1415926535]

Just FYI:
Win10 -> box: puphpet/centos65-x64

I ran into this error when I downloaded code (inc. the vagrantfile) from a PacktPub tute. I then tried a puphpet vagfile I created myself and it created a new machine and worked without error. This my first time ever using vagrant or virtualbox but this seems pattern seemed to be inline with what someone above was saying about distributed (or "already used") vagrantfile(s) and keys.

No idea if this helps anyone but figured I would take the time to share jic.

[Tset-Noitamotua]

config.ssh.insert_key = false did not work for me :(

What does the workaround look like until release 1.8.6 (September 2016)?

Especially I would like to know what needs to be changed in this boot2docker-vagrant example to make it work as expected.

[xwf]

You can patch release 1.8.5 as described in #7610 or downgrade to 1.8.4

[Tset-Noitamotua]

Sorry for stupid question ... does patch(ing) mean that I would have to build vagrant from source?

[markjreed]

Running into this problem now. In my case the patched .ssh/authorized_keys file has the right contents but the wrong mode: -rw-rw-r-- 1 vagrant vagrant 389 Jul 29 14:08 authorized_keys. So I manually logged in using the password and fixed the permissions with chmod 0600 .ssh/authorized_keys, and that fixed the problem.

[marciocamello]

If you change root password, add to Vagrantfile

config.ssh.username = "your_user"
config.ssh.password = "your_password"
config.ssh.insert_key = false

Works for me, using backup from other box for example.

[gairaldi]

if you check secure log, check for Authentication refused: bad ownership or modes for file /home/vagrant/.ssh/authorized_keys as Markjreed saids , that fixed the problem

[visibilityspots]

vagrant --version Vagrant 1.8.5
having the same issue, seems like the auto ssh key insert function of vagrant is misconfiguring the /home/vagrant/.ssh/authorized_keys file to -rw-rw-r-- instead of -rw------- ..

Aug 3 14:23:30 puppet sshd[1304]: Authentication refused: bad ownership or modes for file /home/vagrant/.ssh/authorized_keys

[f1yers]

I've run into this issue too using the bento centos 67 and 72 images. Like others have commented, the issue is with bad file permissions on authorized_keys.

[Tset-Noitamotua]

To save users with same or similar issue from having to read 'issue novels' like this one and try dozens of suggested workarounds it´s worth to protect the issue after closing to prevent addition of further comments and maybe edit the initial comment to point to top most solution like comment(s). e.g. I as a total noob to vagrant and linux had a really hard day to digg through all that some days ago.

Respect the noobs, too! ;-))))

[paulbhart]

I got the source for building the bento centos 67 box and used packer to build a box for vmware. In their source they set the permissions for the /home/vagrant/.ssh/authorized_keys to 600 as it should be and I added a line in the last thing executed to verify that it stayed with that permissions (which it did)

Thus I have to assume (as mentioned by @visibilityspots ) that vagrant is changing permissions of the file when it is do the auto ssh key insert function of vagrant.

Looks like folks using virtualbox have an easier fix using the package function, but that isn't available for those of us who aren't allowed (by work policies) to use virtualbox.

I am going to next playaround with the config.ssh.insert_key = false option, but seems like a bug needs to be opened with vagrant on this topic?

[willwh]

I updated to Vagrant 1.8.5 this morning from 1.8.4, did a vagrant destroy && vagrant up for testing a box I'm provisioning with ansible, and I ran in to this.

I just added a new task to my ansible playbook to take care of this:

- name: fix .ssh/authorized_keys perms
  file: path=/home/vagrant/.ssh/authorized_keys owner=vagrant group=vagrant mode=0600

[heichblatt]

Hi all,

I'm still getting this error.
Arch Linux, vagrant 1.8.5. Box is centos/7.

Please reopen.

[joe-walker]

I can confirm that this problem still exists as of today with Vagrant 1.8.5 and box centos/6 on Windows 10, and that the "config.ssh.insert_key = false" setting does not resolve the issue.

[Jauler]

Ubuntu 16.04, Vagrant 1.8.1, virtualbox 5.0.24.

This issue still exists for me too.

[justinkwanlee]

as @joe-walker mentioned, this is happening with the exact same setup

Windows 10
Vagrant 1.8.5
Virtualbox 5.1.6r110634(QT5.5.1)
puppetlabs/centos-6.6-64-puppet

[heichblatt]

Since so many people still get this error, could we please get this issue opened again?

[xRomZak]

Same happened for me

Windows 8.1
Vagrant 1.8.5
VirtualBox 5.1.6
ubuntu/trusty64

[mikhailponomaryov]

Just checked it once again. The issue still persists. Arch Linux, Vagrant 1.8.5, Centos 7.

[flound1129]

Ran into this issue today, Centos 6.7, Vagrant 1.8.5, Yosemite host.

[ja22zz]

Same issue for me.

centos/7 box,
Vagrant 1.8.5,
Ubuntu 16.04 host

[bilgeoz]

Same issue for me, and my solution is that;

• open related Vagrantfile
• type :

config.ssh.username = "vagrant" config.ssh.password = "vagrant"

• try vagrant reload.

it worked for me.

[andymsmith]

@bilgeoz solution above worked for me on Vagrant 1.8.5, El Capitan and VBox 5.0.26

[Endlessline]

@bilgeoz solution worked for me. I'd also setup the private_key_path but that only seemed to work after the machine had booted and I used 'vagrant ssh'. I have a fairly simple Vagrant file but some (probably most) provisioning tasks and folder syncs were not working because of vagrant not being able to connect. Using the default username / pw in the Vagrant file seems to work.

Vagrant 1.8.1
Windows 10
trusty64 box
Virtualbox 5.x

[fmoutawe]

Same issue with :

• Vagrant 1.8.6
• Debian 8 (Jessie) stable
• VirtualBox 5.1

Solded with :
config.ssh.username = "vagrant"
config.ssh.password = "vagrant"

Thanks @bilgeoz

[mcfletch]

Same issue:

• Vagrant 1.8.5
• Ubuntu 16.10 host
• centos7 client

Seems like there's a regression in 1.8.5?

[kisszoltan]

We had similar issue with the following setup, and managed to work out a solution:

• Vagrant 1.8.6
• VirtualBox 5.1.8
• Window 7
• RHEL 7.2

As staring off with Red Hat Enterprise Linux 7 we had to create our own custom Vagrant box. We installed RHEL in a VirtualBox machine, and issued a vagrant package on it with --base parameter.

For this image we had to use a previously generated ssh key, wherefore the authorized_keys files has already been updated before packaging. As a result the created box contained a custom key, which caused the first startup to look like this:

==> default: Booting VM...
==> default: Waiting for machine to boot. This may take a few minutes...
    default: SSH address: 127.0.0.1:2222
    default: SSH username: vagrant
    default: SSH auth method: private key
    default: Warning: Authentication failure. Retrying...
    default: Warning: Authentication failure. Retrying...
    default: Warning: Authentication failure. Retrying...
    default: Warning: Authentication failure. Retrying...
    default: Warning: Authentication failure. Retrying...
    default: Warning: Authentication failure. Retrying...

So clearly the problem was that...

when packaging a box from a VirtualBox instance (aka through --base option) then Vagrant's (mitchellh's) insecure key have to be used.

To use our own ssh key, we had to issue a vagrant up on the image prepared from a VirtualBox instance with Vagrant's ssh key, and then update ~/.ssh/authorized_keys file in the guest machine and .\.vagrant\machines\default\virtualbox\private_key file on the host respectively and then re-package our vagrant instance with vagrant package --output new.box.

So the whole process briefly:

1. create a VirtualBox instance called vbox
2. use Vagrant's ssh key
3. vagrant package --base vbox
4. vagrant box add testbox package.box
5. vagrant init testbox
6. vagrant up
7. update ~/.ssh/authorized_keys on guest machine
8. update .\.vagrant\machines\default\virtualbox\private_key on host machine
9. vagrant --output package.box
10. vagrant box remove testbox
11. vagrant box add testbox package.box
12. vagrant up

(The whole process would include some additional vagrant destroy and del/rm package.box so this is just a theoretical process.)

[mschuchard]

Same issue under same circumstances for me with:

• Vagrant 1.8.7
• Virtualbox 5.1.6
• Host: Ubuntu 16.10
• Guest (base): CentOS 7.3

[jkrug]

Hi guys,
had the same problem under Mac OS X, vagrant 1.8.5 and 1.8.7.

Simple to solve:

• vagrant up the box
• log in with normal ssh (ssh [email protected]) (password: vagrant)
• inside the box run "sudo chmod 400 /home/vagrant/.ssh/authorized_keys"

You're done!

[antonio-malcolm]

@heichblatt DONE.

https://github.com/mitchellh/vagrant/issues/8112

Void Linux
Vagrant 1.9.1
Virtualbox 5.1.10

This issue started for me this week. It probably hit sooner, but I update my boxes only every few months, so I've just noticed the issue, today.

[antonio-malcolm]

OK, so I performed a complete reinstall of vagrant, and, now, when I use package, I get the following message (which is reaussuring, and probably how it _should_ work):

    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 it's present...
    default: Key inserted! Disconnecting and reconnecting using new SSH key...

Anyone else have any luck with a reinstall?

[antonio-malcolm]

OK, I've also found that restoring the insecure key before running vagrant package will result in vagrant generating a new key upon running vagrant up on the new package (see my previous comment).

$ rm /home/vagrant/.ssh/authorized_keys

$ wget --no-check-certificate \
 https://raw.github.com/mitchellh/vagrant/master/keys/vagrant.pub \
 -O /home/vagrant/.ssh/authorized_keys

[bvi1998]

I had this problem after updating boxcutter/centos72 to the 2.0.19 box.
I added this to my vagrantfile and now I'm ok:
config.vm.box_version = "2.0.18"

[mr-moon]

Still an issue for us on 1.8.6

[umesh1989]

I had this issue while running vagrant up from apache metron I was using 1.8.5 vagrant, however using 1.9 resolved this

[aviindub]

i had the same issue trying to use a base box i had packaged off of ubuntu/xenial64, after having given it a bigger hard disk. i was initially using vagrant 1.8.2 but still had the same issue after upgrading to 1.9 and redoing the entire process from scratch.

the issue turned out to be that the base ubuntu/xenial64 box uses "ubuntu" as the ssh user instead of "vagrant", but somehow this information gets lost in the packaging process. the fix was to add the line config.ssh.username = "ubuntu" to the vagrantfile when trying to use my newly packaged box as the base in a new Vagrantfile. here is a gist detailing my adventure: https://gist.github.com/aviindub/7bb908cdee41b776a191661c2dc0bc47

(edit: fixed broken link)

[ghost]

@aviindub could you please post again your gist?

[ghost]

OK so, to sum up @aviindub 's solution for ubuntu/xenial64 what worked for me was adding config.ssh.username = "ubuntu" to the vagrantfile before the first vagrant up (this is when setting up our custom box) AND also to the vagrantfile that uses our created vm. Hopes this helps someone

[Sdjabate]

i am having this ssh login issue. What is the final resolution approach to this?

[jackyq2015]

Adding the config.ssh.username = "ubuntu" is a good workaround. But it does not really fix the private key issue. I have gotten those issues for different reason those days:

1. VB bugs, the NAT interface is not plugged when boot the vm
2. the config.ssh.insert_key setting for vagrant file.
3. Use a box generated with existing key but later the shared key on the host changed.

[tim-massey]

For what its worth I have been wrestling with this issue and noticed the following:

I have 2 VM's.
After packaging the boxes and a destroy up cycle.
The ~/.ssh/authorized_keys are different on each box.
One ends with vagrant the other ends with vagrant insecure public key
The box effected is seemingly random.
wget the correct key over the old one fixes the error.

I had the config.ssh.insert_key = false before packaging. I have recently upgraded Vagrant and Virtualbox to latest

[zesk06]

upgrading to vagrant 1.9.5 fixed this issue for me.

config.vm.box = "centos/7" on Mac OS X

[skinneejoe]

Below is an explanation of why this problem occurs, why solutions in this thread work for some and not others, how Vagrant has failed us, and a side note on how Ubuntu has failed in creating their base boxes.

If you are having trouble understanding the solutions in this thread please read my experiences below, I think it will help you.

How Vagrant authenticates to boxes

Vagrant can use multiple ssh authentication methods to connect to your box. The recommended default is to use authentication keys. Also typical username/password auth is an option as well.

First Vagrant Up

The first time you run Vagrant up, Vagrant starts your box and it tries to authenticate to it. Usually it will try to use authentication keys. Sometimes though, if your box provider did things wonky like Ubuntu, it will try password auth. You'll know which one it's trying because it will report it in the terminal like so:

SSH auth method: private key

OR

SSH auth method: password

SIDE NOTE: I've been unable to figure out how to change this chosen auth method for the ubuntu/xenial64 box. On other boxes it seems to default to private key, and if you specify a config.vm.password in the VagrantFile it swithces to password. But I can't see how to change the ubuntu box to default to private key. It seems like maybe it changes after a new random public key has been inserted. Read on for more details...

How does Vagrant know what private key to pass to the public key in your box on the first Up command? Well those who create boxes for public use are supposed to put the Vagrant public key in the ~/.ssh/authorized_keys file and then assign the .ssh directory 0700 permissions and the authorized_keys file 0600 permissions. This is documented on this page under the section "vagrant" User: https://www.vagrantup.com/docs/boxes/base.html

The public key to use for this can be found here: https://github.com/mitchellh/vagrant/tree/master/keys it's the vagrant.pub file.

So when Vagrant Up's for the first time it looks for this pub key in the ~/.ssh/authorized_keys file. And using the private key stored in the .vagrant/machines/default/virtualbox/private_key file, it is able to authenticate to your vm.

SIDE NOTE: The private key path may differ if you're using a provider other than VirtualBox.

Removing the insecure key

This public key is considered insecure because it's known by everyone. It's posted on the web link I referenced earlier so anyone can get a hold of it. So here's where things start to fall apart for most people. After Vagrant connects to your vm for the first time using the default, or insecure, public key, it generates a new, random, private/public key pair and it inserts that new public key in place of the insecure public key. It then uses this new private/public key pair moving forward.

How this wrecks your packaging a box

If the insecure public key is replaced on the first vagrant up, then you setup your box and package it, the newly packaged box gets the randomly generated public key. Then when you try to do the the first Vagrant up with this new box it looks for the insecure public key that's no longer there. Badaboom - authentication error is born.

How do I fix it?

Fixing this issue depends on a few variables. Below I'll try to address them.

Are you using a well created PUBLIC box like hashicorp/precise64?

SIDE NOTE: How do you tell if you're using a well created box? Well it's kind of difficult to know without reading the entire 'How to create a base box' section on Vagrant's website and then scouring the base box you're using to see if it follows convention. But there are some clues. Does the base box vagrant up with the default ssh username of vagrant or something else? If it's not using vagrant then the creators either created it wrong or it wasn't meant for public use. Is the default SSH auth method password? If so, it's poorly made for public use.

I haven't had much experience with a lot of boxes, but I have found that hashicorp/precise64 is well made, while ubuntu/xenial64 is put together by someone who obviously did not read the Vagrant docs well. More on that later.

If you're using a well created box it's pretty easy to solve. If you have not yet vagrant up'd your box for the first time, add this line to your Vagrantfile:

 config.ssh.insert_key = false

This tells Vagrant to NOT insert a new random public key in place of the insecure public key. Then when you package it the insecure public key goes with it.

But what if you already up'd your box without this line in your file? Well, you can destroy your box and start again, but that might not be ideal if you have have a lot of config in it already. So you can do this instead:

 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

(thanks to mtchavez for this)

What does this do? First line downloads the insecure public key from the official Vagrant github and writes it to the vm as the authorized_keys file. The next two lines set the appropriate permissions as outlined here: https://www.vagrantup.com/docs/boxes/base.html

---

IMPORTANT! Small Update

As noted at the end of this post in one of my updates, you also need to make sure you've deleted any other private keys that may get packaged with your box. See update at the end of the post.

---

The last line may vary for you depending on how well your box was setup. If the vagrant user and group exists then it should work for you. If not you have to do a little extra work as outlined below...

## Are you using a crappily made base box like ubuntu/xenial64?
The ubuntu/xenial64 box scoffs at all the conventions Vagrant has laid out in thier docs. The creator of this box will not be held back by a silly thing like standards! There is NO vagrant user. Instead the default user is ubuntu. What is the password for this user? Who knows! And the default SSH auth method is password. Of course Vagrant tries to use the username/password of vagrant/vagrant, but this fails. So then Vagrant looks for the insecure public key. Thankfully ubuntu included it so Vagrant can connect.

The weird thing is if you include the 'config.ssh.insert_key = false' line it will connect, and avoid overwriting the insecure key, but you won't be able to SSH in because you'll be prompted for a password. I think this is because the default SSH auth method is password, and I'm not sure how to change it. Way to go ubuntu.

So here is one way to get around it.

1. Vagrant Up the ubuntu box without the 'config.ssh.insert_key = false' line

2. Reset the ubuntu user's password to 'vagrant':

   sudo passwd ubuntu
   (will prompt for password)

3. Config your box how you want it

4. Package your box

5. Then in your new boxes Vagrantfile include:

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

The downside to this is you'll continually be prompted for a password when ever you try to ssh in to the vm.

If you want to clean up ubuntu's failure to execute a proper Vagrant box you're going to have to dig deep. I haven't yet figured it out and I've probably already spent too much time on this. But it likely involves creating a vagrant user and reworking permissions and the SSH setup a bit.

## How Vagrant is failing us
Two ways: 1) Vagrant should be smart enough to prompt about the key when producing a package. 2) The documentation should provide some examples, and definitely there should be more information about this on the pack CLI page.

How Ubuntu is failing us

They royally hosed thier base box ubuntu/xenial64. Not only do they not have the Vagrant defaults in place, they skip 'UseDNS no' setting recommended by Vagrant and they hosed up the default auth method. It really makes packaging this box a pain. Sad.

I doubt I'll be updating this comment with any future findings due to lack of time, but I hope this provides the community with at least some starting points for diagnosing these issues. More important I hope it shines a light at Vagrant and Ubuntu so they can get thier stuff together.

UPDATE! Got Ubuntu box working!

I won't spell out all the details of how I got it working, but here's the gist of it:

1. Followed directions on this page very carefully under the Default User Settings section: https://www.vagrantup.com/docs/boxes/base.html
   
   
   
   • I created a vagrant user, with password of vagrant, and added it to all the same groups the ubuntu user was in.
   
   
   • Also I realized that the insecure public key is per user so I had to be sure I had added it under the vagrant users account. Basically ssh in as that user and run the wget commands above in this post.
   
   
   • Make sure you do the Password-Less Sudo setup in the article above too
   
   

2. I found out that there is a Vagrantfile packaged with the boxes in this location on your host machine:

   C:\Users*username.vagrant.dboxes*boxname.box\0\virtualboxVagrantfile

3. I also noticed there was a file in this directory called vagrant_private_key. This seemed to be overriding the random private key generated when inserting the new public key. I removed it but got an error. Then I noticed in the Vangratfile in this same directory, there was a line like this:

   config.ssh.private_key_path = File.expand_path("../vagrant_private_key", __FILE__)

Wha!?!? how did.. what the? Not sure how it got there, but I commented it out. I made sure any other private keys were deleted (.vagrant/machines/default/virtualbox/private_key) and made sure the insecure key was in place for the vagrant user.

Voila! It worked! Moral of the story is, Vagrant could really stand to improve their docs. I knew nothing about the existence of this second Vagrantfile. Sheesh. But hey problem solved.

Interestingly, this extra packaged Vagrantfile - which I think is created when users use the '--vagrantfile' flag on the package command - also had recorded in it the password for the ubuntu user. But I still think it's better to add a new vagrant user as that is the correct standard for working with Vagrant.

Last Update

I figured out why this line showed up in the Vagrantfile under C:\Users... (see path above)

config.ssh.private_key_path = File.expand_path("../vagrant_private_key", __FILE__)

Sure I had set the insecure public key in the ~/.ssh/authorized_keys file, but I didn't remove the randomly generated private key from .vagrant/machines/default/virtualbox/private_key before packaging. So I deleted this private_key file, included the 'config.ssh.insert_key = false' line in my Vangrantfile, then I up'd it to make sure it was working, then I packaged it.

The resulting package worked perfectly. I'm gonna go get something to eat. [mic drop]

[bashu]

@skinneejoe or you can use bento/ubuntu-16.04 box instead, it just works!

[skinneejoe]

@bashu True, although some users might already have a heavy investment in setting up a particular box. Also, it's just generally a good idea to understand the tech you're working with. But it's nice to know there's a decently made ubuntu box out there!

[cataclyst23]

This solved the issue for me:
_eval $(ssh-agent); ssh-add_
then try "vagrant up" again!

[vmtram]

Just use default vagrant password: vagrant to access.
Detail here https://youtu.be/AvcpLuANSuM

[oliverkierepka]

I my case i had to vagrant destroy and than vagrant up again to get it to work finally.
If there was an update to the box use are using try to run vagrant box update before you do vagrant up

[chrisglass]

Hi all!

I am in the process of changing the default behaviour of Ubuntu vagrant images.
I think I have a behaviour that is consistent with what you guys expect, but I'd like some feedback.

Would you please confirm that "ubuntu/artful64" behaves as you expect it to? It follows all the instructions in https://www.vagrantup.com/docs/boxes/base.html except setting the root password.

A quick run of "vagrant init ubuntu/artful64; vagrant up; vagrant ssh" seems to do what I expect should happen, but I'd like your feedback before I backport it to other releases.

Thanks!

Specifically:

• image has a vagrant:vagrant user as well as the usual ubuntu user.
• ubuntu user doesn't have password or keys set.
• vagrant user has the insecure ssh pubkey in ~/.ssh/authorized_keys.
• vagrant user has passwordless sudo.
• "vagrant ssh" just works, logging you in as "vagrant" user
• root user is still locked

[skinneejoe]

Hey Chris, that's great to hear! I have not had a chance to try ubuntu/artful64 but I will give it a shot soon. I have built my own private ubuntu xenial boxes for HyperV and I found these articles really helpful:

https://docs.microsoft.com/en-us/windows-server/virtualization/hyper-v/Best-Practices-for-running-Linux-on-Hyper-V

https://docs.microsoft.com/en-us/windows-server/virtualization/hyper-v/supported-ubuntu-virtual-machines-on-hyper-v

Especially helpful is the directions on building your VHD so that the size of your ubuntu box is not huge. Thanks for help!

[mcandre]

Sure I had set the insecure public key in the ~/.ssh/authorized_keys file, but I didn't remove the randomly generated private key from .vagrant/machines/default/virtualbox/private_key before packaging. So I deleted this private_key file, included the 'config.ssh.insert_key = false' line in my Vangrantfile, then I up'd it to make sure it was working, then I packaged it.

Would be nice if Vagrant automatically undid the randomly generated SSH key setup during vagrant package...

Would also be nice if Vagrant didn't configure insert_key as false by default in machine.rb, then disregard this to default to true anyway in ssh_connect.rb.

[axd1967]

The example given at https://www.vagrantup.com/docs/boxes/base.html should mention this issue; I just followed the steps, and was then hit on the nose by this issue... but it looks like the fine print around user and ssh is intended to deal with the issue?

Here is how I did it for ubuntu/xenial.

vagrant init
vagrant up
vagrant ssh-config # note the IdentityFile path; copy that file next to Vagranfile as e.g "privkey"
add following lines to Vagrantfile ("myvm." is usually "config." in most Vagrantfiles):
- myvm.ssh.username = 'ubuntu'
- myvm.ssh.private_key_path = "privkey"
- myvm.vm.box = "my_custom" (before this change it read "ubuntu/xenial")

vagrant package --base <VM name given to VirtualBox provider>
vagrant destroy -f
vagrant box add my_custom
vagrant up

(i've also taken the habit to give different names to all these beasts such as the hostname, the VirtualBox name, the Vagrant name and the Ruby variable that is usually named "config")

[richardwhitehead]

@axd1967 that worked great, thank you.

[chrisglass]

The latest official ubuntu vagrant boxes should be fixed, and use the vagrant user with the known insecure ssh key installed by default:

vagrant init ubuntu/xenial64
vagrant box update (fixed in v20180112.0.0)
vagrant up
vagrant ssh

(notice you're now "vagrant" with passwordless sudo)

[bashu]

@chrisglass can confirm

[Sherlockk]

I just updated my xenial64 last night and had the same issue mentioned here. Tried most of the solutions suggested without success. What did it for me was to also upgrade VirtualBox to the latest version. That's when vagrant recognized the insecure key at boot time and generated new keys and all worked from there(I did not have to put the "config.ssh.insert_key = false" setting in the vagrant file) .

[grtjn]

This is side-ways related, but this thread helped me solve it. I was copying over from an old machine to a new one, and was getting the Warning: Authentication failure too. I only had to copy over the .vagrant.d/boxes/ folder to preserve the private keys stored in there to make everything work. Not a suitable solution for when packaging, but worth keeping in mind in case anyone ever has the need to move over existing VMs to a new machine..

[fatimazahramoussaid]

I had the same problem
I fixed it using
config.ssh.username = "myUser"
config.ssh.password = "myPass"
myUser and myPass used to log in the virtualbox

[nicetuxedo]

Vagrant doesn't add new line at the end of authorized_keys file. As a result you get a garbage content like this
ssh_rsa AAAA_INSECURE_KEY vagrant insecure keyssh_rsa AAAA_SECURE_KEY vagrant

Make sure you add a new line at the end of the authorized_keys file in your box before packaging.

[ckwolff]

Wanted to elaborate on what my solutions was, as apparently there can be several causes.

I had all of the items correct, but it seems some of these settings are saved on your local vagrant.d folder because I had tried to package my box several times... it's like it was using OLD items in that folder.

My base box had the identityfile using vagrant_private_key while my packaged box was using insecure.

I went into my packaged box and noticed that the vagrant.pub key I copied to authorized_keys had reverted back to what it was before I changed it. It seems to look in vagrant.d to see if a vagrant_private_key exists, if it doesn't, overwrite it with an insecure key, no matter if your config.ssh.insert_key was set to false.

I went into the vagrant.d folder, found my box folder and deleted the whole thing, forcing the vagrant package to package up the new key instead.

[k-funk]

I was able to solve my problem by removing the private key and reloading:

vagrant up
ssh [email protected] -p 2222
rm <path_to_Vagrantfile>/.vagrant/machines/default/virtualbox/private_key
exit
vagrant halt
vagrant up

I think that I created my issue by messing with the .ssh inside the vm while copying some keys over.

[hashibot[bot]]

I'm going to lock this issue because it has been closed for _30 days_ ⏳. This helps our maintainers find and focus on the active issues.

If you have found a problem that seems similar to this, please open a new issue and complete the issue template so we can capture all the details necessary to investigate further.