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

zunayed opened this Issue Jan 14, 2015 · 153 comments


None yet
zunayed commented Jan 14, 2015

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


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

zunayed commented Jan 15, 2015

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
    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
  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 commented Jan 20, 2015

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


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 commented Jan 28, 2015

@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 commented Feb 3, 2015

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.


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 commented Feb 3, 2015

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?

townsen commented Feb 4, 2015

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!


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 commented Feb 25, 2015

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 commented Mar 5, 2015

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 commented Mar 5, 2015

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 commented Mar 6, 2015

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


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.


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 commented Mar 17, 2015

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: Vagrant insecure key detected. Vagrant will automatically replace
ac-centos66: this with a newly generated keypair for better security.
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 commented Mar 21, 2015

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 commented Mar 25, 2015

Glad most people got this resolved 👍


@mtchavez your solution was a lifesaver!


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: Vagrant insecure key detected. Vagrant will automatically replace
blah: this with a newly generated keypair for better security.
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 commented May 21, 2015

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__)

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 commented Jun 15, 2015

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.


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.


Thank you @mtchavez!

@sethvargo sethvargo added this to the 1.8 milestone Jul 10, 2015

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?


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:
After that, you should be able to check ~/.ssh/authorized_keys.


BitBrit commented Jul 16, 2015

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

@verenion verenion referenced this issue in puphpet/puphpet Jul 21, 2015

invalid byte sequence in US-ASCII #1792


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 commented Jul 22, 2015

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


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

robme commented Jul 22, 2015

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 commented Jul 22, 2015

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


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

robme commented Jul 24, 2015

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.


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 commented Jul 27, 2015

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 commented Jul 27, 2015

Same problem using vagrant 1.7.4 and VirtualBox 5.0


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

matti commented Jul 28, 2015

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 commented Aug 1, 2015

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__)
  1. Package your box
jazzfog commented Aug 4, 2015

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 commented Aug 4, 2015

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.


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.


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

@kevinfodness kevinfodness referenced this issue in puphpet/puphpet Aug 6, 2015

Errors: Connection timeout #1826


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

@jrgriffiniii jrgriffiniii referenced this issue in jrgriffiniii/vagrant-islandora Aug 8, 2015

Authentication appears to fail for CentOS 6.x Base Boxes #1


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


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

doctapp commented Aug 17, 2015

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


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


Thanks to @dylanschoenmakers and @mtchavez for the solution


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

Absolutely the stupidest feature ever.

@bblaette bblaette referenced this issue in puphpet/puphpet Sep 5, 2015

Vagrant ssh keep asking for password #1253


This is a joke.


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


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


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.


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

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" notifications@github.com:

Guessing their focus right now is on Vagrant's successor, Otto

Reply to this email directly or view it on GitHub
#5186 (comment).


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

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.


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!


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


thanks @mtchavez that got it working for me

@markus-perl markus-perl pushed a commit to markus-perl/vagrant that referenced this issue Oct 17, 2015
Markus Perl #5186: Warning: Authentication failure. Retrying... after packaging box 61466c8
nroose commented Oct 23, 2015

Setting config.ssh.private_key_path worked for me.


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


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.

@whatnickcodes whatnickcodes referenced this issue in scotch-io/scotch-box Nov 3, 2015

Update Guest Additions Version #106


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

@sethvargo sethvargo closed this Nov 19, 2015

@mitchellh is going to do some more testing with GH-6406 and 1a7937e

@sethvargo sethvargo reopened this Nov 19, 2015
@mitchellh mitchellh was assigned by sethvargo Nov 19, 2015

Thanks @jazzfog - your solution on #5186 (comment) worked for me too.



This is all fixed up.

masitko commented Dec 10, 2015

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

@lboom lboom referenced this issue in kra/futel-installation Jan 3, 2016

packaging of intermediate devbox images is busted #35

astrashe commented Jan 8, 2016

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 commented Jan 15, 2016

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
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 commented Feb 4, 2016

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

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


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.


@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:
    default: SSH username: vagrant
    default: SSH auth method: private key
    default: Vagrant insecure key detected. Vagrant will automatically replace
    default: this with a newly generated keypair for better security.
    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.


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.


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

CharlieKuharski commented Mar 4, 2016 edited

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.


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 commented Mar 7, 2016

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 commented Mar 7, 2016

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.


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.



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 markus-perl@61466c8 to the vagrant team. Without applying the patch the problem still exist for me even in the latest version.

astrashe commented Mar 7, 2016

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.


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!


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


@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 commented Apr 18, 2016

@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


sthum commented Apr 20, 2016

@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


@mtchavez fixed up my issue, thanks a bunch!


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 commented Apr 23, 2016 edited

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


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.


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 commented May 6, 2016

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:
    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
@keithel keithel pushed a commit to keithel/unorganized-scripts that referenced this issue May 6, 2016
Keith Kyzivat Have it leave the original ssh key in the box
* Fix the script to work around a Vagrant bug-ish - when vagrant sets
  sets up a box with 'vagrant up', it replaces the 'insecure' ssh key
  with a more secure one.  For purposes of repackaging a box to
  distribute publicly, we don't want it to do that, so we add the
  Vagrant config: config.ssh.insert_key = false

Vagrant issue detailed here: mitchellh/vagrant#5186

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.

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:
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:
SSH username: vagrant
SSH auth method: private key
Machine booted and ready!
Mortek commented May 20, 2016

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 commented May 26, 2016

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.


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.


@Mortek, worked for me : )

Vagrant 1.7.4

mloskot commented Jun 19, 2016

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

@mtchavez 's workaround in #5186 (comment) has worked for me.

Starscream27 commented Jun 28, 2016 edited

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

esciara commented Jul 8, 2016

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 commented Jul 20, 2016 edited

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.


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

yupvr commented Jul 20, 2016

The same issue when upgrading from 1.8.4 to 1.8.5


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

Tandolf commented Jul 21, 2016

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 commented Jul 21, 2016

This is a known bug in 1.8.5: #7610


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


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.


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 commented Jul 29, 2016

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


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


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.


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.


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


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 commented Aug 4, 2016

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.


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! ;-))))


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 commented Aug 17, 2016 edited

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
@hairmare hairmare added a commit to gravity-platform/vagrant-centos-7-php that referenced this issue Sep 2, 2016
@hairmare hairmare Add ssh config for vagrant user
Works on my machine and seems to be how mitchellh/vagrant#5186 solved the problem as well.

Hi all,

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

Please reopen.


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 commented Sep 16, 2016

Ubuntu 16.04, Vagrant 1.8.1, virtualbox 5.0.24.

This issue still exists for me too.

justinkwanlee commented Sep 17, 2016 edited

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)


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

xRomZak commented Sep 22, 2016

Same happened for me

Windows 8.1
Vagrant 1.8.5
VirtualBox 5.1.6


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


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

ja22zz commented Sep 26, 2016

Same issue for me.

centos/7 box,
Vagrant 1.8.5,
Ubuntu 16.04 host

bilgeoz commented Sep 26, 2016

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.


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


@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

ivelfan commented Nov 3, 2016 edited

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 commented Nov 4, 2016

Same issue:

  • Vagrant 1.8.5
  • Ubuntu 16.10 host
  • centos7 client

Seems like there's a regression in 1.8.5?


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


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 commented Nov 23, 2016 edited

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 vagrant@box.url.or.ip) (password: vagrant)
  • inside the box run "sudo chmod 400 /home/vagrant/.ssh/authorized_keys"

You're done!


@heichblatt DONE.


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.


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: 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 commented Dec 12, 2016 edited

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 commented Dec 13, 2016

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 commented Dec 15, 2016

Still an issue for us on 1.8.6

@smartbit smartbit referenced this issue in AnwarYagoub/RHCSA-RHCE-Lab-Environment Dec 29, 2016

Discussion #23


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 commented Jan 19, 2017 edited

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

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment