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

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

[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.d\boxes*boxname.box*\0\virtualbox\Vagrantfile

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!

[tramvm]

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.

[ninjawolff]

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 vagrant@127.0.0.1 -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.

[ghost]

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.