Join GitHub today
GitHub is home to over 36 million developers working together to host and review code, manage projects, and build software together.Sign up
"Warning: Authentication failure. Retrying... " after packaging box #5186
I am able to vagrant up and have ssh running fine from a base box that I've provisioned.
vagrant package --base "<name from VBoxManage list vms>" vagrant box add mypackagedbox package.box
modified the Vagrant file
vagrant up now hangs on
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
Seems like an ssh issue
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
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
Something seems to have changed regarding this. I last successfully packaged a virtualbox box using the
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
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.
Interesting. I am also using the
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?
I had the same problem - in the last week my Vagrant machines would all fail to come up with the
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:
Today, working from home, I proceeded to switch out things to see if it made any difference - out went
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 (
Host machine: OS X Mavericks
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
You have 3 options here.
A. Tell vagrant in the middle box to NOT create a new safe/secure pair.
I will say, if this is for prototyping, just use A, just remember
On the first box, add:
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
So I encountered the same problem and spent some time figuring this out.
Here is what I did; I put
After that, package the box. @bozic You will need to
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
Then when building the base box I think you need to add the
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.
Surprisingly, this solved the issue for me :
Workaround for vagrant 1.7.2 :
Test OK :
Thanks to @cdelaitre for the fix!
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.
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
Followed @mtchavez workaround but still not work for me, which is a box of Ubuntu 14.04 64bit, running on Mac OSX 10.
I think this is the reason why vagrant doesn't use the default insecure key in
So, how can I prevent vagrant to generate these lines when re-package boxes?
referenced this issue
Jun 2, 2015
I think I finally realized the main core of the problem.
So if you are going to build your own box and publish it to cloud, then configure your Vagrantfile with
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:
I'll run that before packaging my virtual box next time.
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:
For what its worth I have been wrestling with this issue and noticed the following:
I have 2 VM's.
I had the
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:
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.
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?
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:
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:
(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.
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:
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.
I figured out why this line showed up in the Vagrantfile under C:\Users... (see path above)
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]
I am in the process of changing the default behaviour of Ubuntu vagrant images.
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.
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:
Especially helpful is the directions on building your VHD so that the size of your ubuntu box is not huge. Thanks for help!
Would be nice if Vagrant automatically undid the randomly generated SSH key setup during
Would also be nice if Vagrant didn't configure
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.
(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")
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
(notice you're now "vagrant" with passwordless sudo)
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) .
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
referenced this issue
May 14, 2018
Vagrant doesn't add new line at the end of authorized_keys file. As a result you get a garbage content like this
Make sure you add a new line at the end of the authorized_keys file in your box before packaging.
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.
I was able to solve my problem by removing the private key and reloading:
I think that I created my issue by messing with the