"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

[mehdi-ghezal]

Thanks to @dylanschoenmakers and @mtchavez for the solution

[rajat404]

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

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

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

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

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

[ruskotron]

Absolutely the stupidest feature ever.

[adiachenko]

This is a joke.

[riyadparvez]

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

[ruskotron]

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

[thesteve0]

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

[PanadeEdu]

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

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

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

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

[ColorFuzzy]

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

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

[markus-perl]

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

[ruskotron]

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

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

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

[iluwatar]

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

[joelanman]

thanks @mtchavez that got it working for me

[nroose]

Setting config.ssh.private_key_path worked for me.

[psychok7]

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

[adiachenko]

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

[sebastianwestberg]

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

[sethvargo]

GH-6406

[sethvargo]

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

[robhadfield]

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

:+1:

[mitchellh]

This is all fixed up.

[mitchellh]

See #5780

[gibsonje]

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

[sethvargo]

Hi @gibsonje

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

[gibsonje]

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

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

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

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

[masitko]

I had the same issue using Puphpet and Vagrnat 1.7.4.

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

[astrashe]

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

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

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

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

[ghost]

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

Bad workflow:

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

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

Workaround workflow:

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

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

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

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

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

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

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

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

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

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

[tomleo]

My Workaround

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

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

[rajinders]

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

"config.ssh.insert_key = false"

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

config.ssh.username = 'vagrant'

config.ssh.password = 'vagrant'

However this is not a great solution.

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

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

[theorician]

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

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

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

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

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

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

... yay.

[speedlight]

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

[ArialBlack]

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

[CharlieKuharski]

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

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

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

1. vagrant up

Now, I'm back in business.

[TRPB]

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

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

[astrashe]

A couple of points:

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

[gibsonje]

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

[TRPB]

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

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

I can actually somewhat see what's wrong. After

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

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

`

[markus-perl]

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

[astrashe]

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

[TRPB]

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

[CelsoSantos]

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

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

[knappador]

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

[bvi1998]

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

Thanks!

[sthum]

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

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

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

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

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

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

[kevinheins]

@mtchavez fixed up my issue, thanks a bunch!

[TRPB]

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

[astrashe]

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

[TRPB]

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

[TRPB]

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