New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

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

Closed
zunayed opened this Issue Jan 14, 2015 · 176 comments

Comments

Projects
None yet
@zunayed

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

@asafvilman

This comment has been minimized.

Show comment
Hide comment
@asafvilman

asafvilman Jan 15, 2015

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

asafvilman commented Jan 15, 2015

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

@zunayed

This comment has been minimized.

Show comment
Hide comment
@zunayed

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

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

This comment has been minimized.

Show comment
Hide comment
@melwinm

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

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?

@patrickheeney

This comment has been minimized.

Show comment
Hide comment
@patrickheeney

patrickheeney Jan 27, 2015

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?

patrickheeney commented Jan 27, 2015

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

This comment has been minimized.

Show comment
Hide comment
@zunayed

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

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

This comment has been minimized.

Show comment
Hide comment
@mtchavez

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

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.

@patrickheeney

This comment has been minimized.

Show comment
Hide comment
@patrickheeney

patrickheeney Feb 3, 2015

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.

patrickheeney commented Feb 3, 2015

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

This comment has been minimized.

Show comment
Hide comment
@mtchavez

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

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?

@ghost

This comment has been minimized.

Show comment
Hide comment
@ghost

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

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

@lordgordon

This comment has been minimized.

Show comment
Hide comment
@lordgordon

lordgordon Feb 12, 2015

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

lordgordon commented Feb 12, 2015

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

This comment has been minimized.

Show comment
Hide comment
@tierpod

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

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

This comment has been minimized.

Show comment
Hide comment
@kikitux

kikitux Mar 5, 2015

Collaborator

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

Collaborator

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

This comment has been minimized.

Show comment
Hide comment
@tierpod

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

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

This comment has been minimized.

Show comment
Hide comment
@bozic

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

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

@dylanschoenmakers

This comment has been minimized.

Show comment
Hide comment
@dylanschoenmakers

dylanschoenmakers Mar 7, 2015

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.

dylanschoenmakers commented Mar 7, 2015

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

This comment has been minimized.

Show comment
Hide comment
@mtchavez

mtchavez Mar 16, 2015

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.

mtchavez commented Mar 16, 2015

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

This comment has been minimized.

Show comment
Hide comment
@yahyapo

yahyapo 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:
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!

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

This comment has been minimized.

Show comment
Hide comment
@ckhk212

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

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

This comment has been minimized.

Show comment
Hide comment
@zunayed

zunayed Mar 25, 2015

Glad most people got this resolved 👍

zunayed commented Mar 25, 2015

Glad most people got this resolved 👍

@matt-holden

This comment has been minimized.

Show comment
Hide comment
@matt-holden

matt-holden May 7, 2015

@mtchavez your solution was a lifesaver!

matt-holden commented May 7, 2015

@mtchavez your solution was a lifesaver!

@ruskotron

This comment has been minimized.

Show comment
Hide comment
@ruskotron

ruskotron May 7, 2015

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

ruskotron commented May 7, 2015

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

This comment has been minimized.

Show comment
Hide comment
@panjie

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

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

This comment has been minimized.

Show comment
Hide comment
@Rustem

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

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.

@aressler38

This comment has been minimized.

Show comment
Hide comment
@aressler38

aressler38 Jun 27, 2015

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.

aressler38 commented Jun 27, 2015

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

This comment has been minimized.

Show comment
Hide comment
@jrgriffiniii

jrgriffiniii commented Jun 30, 2015

Thank you @mtchavez!

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

@Blueblau

This comment has been minimized.

Show comment
Hide comment
@Blueblau

Blueblau Jul 14, 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?

Blueblau commented Jul 14, 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?

@ghost

This comment has been minimized.

Show comment
Hide comment
@ghost

ghost Feb 17, 2017

@aviindub could you please post again your gist?

ghost commented Feb 17, 2017

@aviindub could you please post again your gist?

@ghost

This comment has been minimized.

Show comment
Hide comment
@ghost

ghost Feb 17, 2017

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

ghost commented Feb 17, 2017

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

@Sdjabate

This comment has been minimized.

Show comment
Hide comment
@Sdjabate

Sdjabate Mar 29, 2017

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

Sdjabate commented Mar 29, 2017

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

@jackyq2015

This comment has been minimized.

Show comment
Hide comment
@jackyq2015

jackyq2015 Apr 8, 2017

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

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

jackyq2015 commented Apr 8, 2017

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

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

This comment has been minimized.

Show comment
Hide comment
@tim-massey

tim-massey May 12, 2017

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

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

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

tim-massey commented May 12, 2017

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

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

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

@zesk06

This comment has been minimized.

Show comment
Hide comment
@zesk06

zesk06 May 20, 2017

upgrading to vagrant 1.9.5 fixed this issue for me.

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

zesk06 commented May 20, 2017

upgrading to vagrant 1.9.5 fixed this issue for me.

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

@skinneejoe

This comment has been minimized.

Show comment
Hide comment
@skinneejoe

skinneejoe Jun 30, 2017

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

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

skinneejoe commented Jun 30, 2017

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

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

This comment has been minimized.

Show comment
Hide comment
@bashu

bashu Jul 24, 2017

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

bashu commented Jul 24, 2017

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

@skinneejoe

This comment has been minimized.

Show comment
Hide comment
@skinneejoe

skinneejoe Jul 26, 2017

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

skinneejoe commented Jul 26, 2017

@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 comment has been minimized.

Show comment
Hide comment
@cataclyst23

cataclyst23 Aug 15, 2017

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

cataclyst23 commented Aug 15, 2017

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

@vmtram

This comment has been minimized.

Show comment
Hide comment
@vmtram

vmtram Sep 23, 2017

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

vmtram commented Sep 23, 2017

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

AnwarYagoub added a commit to AnwarYagoub/Packer-Test that referenced this issue Oct 19, 2017

@mrmoree

This comment has been minimized.

Show comment
Hide comment
@mrmoree

mrmoree Oct 24, 2017

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

mrmoree commented Oct 24, 2017

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

This comment has been minimized.

Show comment
Hide comment
@chrisglass

chrisglass Nov 21, 2017

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

chrisglass commented Nov 21, 2017

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

This comment has been minimized.

Show comment
Hide comment
@skinneejoe

skinneejoe Nov 21, 2017

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!

skinneejoe commented Nov 21, 2017

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

This comment has been minimized.

Show comment
Hide comment
@mcandre

mcandre Dec 30, 2017

Contributor

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.

Contributor

mcandre commented Dec 30, 2017

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

This comment has been minimized.

Show comment
Hide comment
@axd1967

axd1967 Jan 3, 2018

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

axd1967 commented Jan 3, 2018

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

This comment has been minimized.

Show comment
Hide comment
@richardwhitehead

richardwhitehead Jan 11, 2018

@axd1967 that worked great, thank you.

richardwhitehead commented Jan 11, 2018

@axd1967 that worked great, thank you.

@chrisglass

This comment has been minimized.

Show comment
Hide comment
@chrisglass

chrisglass Jan 13, 2018

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)

chrisglass commented Jan 13, 2018

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 added a commit to bashu/vagrant-dev-box that referenced this issue Jan 14, 2018

@bashu

This comment has been minimized.

Show comment
Hide comment
@bashu

bashu commented Jan 14, 2018

@chrisglass can confirm

@Sherlockk

This comment has been minimized.

Show comment
Hide comment
@Sherlockk

Sherlockk Jan 24, 2018

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

Sherlockk commented Jan 24, 2018

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 comment has been minimized.

Show comment
Hide comment
@grtjn

grtjn Apr 16, 2018

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

grtjn commented Apr 16, 2018

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

This comment has been minimized.

Show comment
Hide comment
@fatimazahramoussaid

fatimazahramoussaid May 1, 2018

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

fatimazahramoussaid commented May 1, 2018

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

This comment has been minimized.

Show comment
Hide comment
@nicetuxedo

nicetuxedo Jun 12, 2018

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.

nicetuxedo commented Jun 12, 2018

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.

hark130 added a commit to hark130/linux_study that referenced this issue Sep 25, 2018

master: Vagrantfile modification
I received an error when attempting to "vagrant reload" after the "vagrant up" completed.
Warning: Authentication failure. Retrying...
    
This error was caused by a problem with the ssh keys.  I modified the Vagrantfile to circumvent my issue based on what I found on:  hashicorp/vagrant#5186
    
Everything seems to be fine (so far) with this small tweak.  I documented more information in the Vagrantfile comments above the statement I added.
    
This may not work for you.  For that matter, you may not be having this problem.  If this Vagrantfile works for you, more power to you.  I just wanted to help out someone else who might be having difficulty getting this vagrant script to work given bugs in Vagrant itself.

Changes to be committed:
    modified:   Vagrantfile
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment