Vagrant: Vagrant machines do not boot up with error SSH auth method: private key

[ameyaagashe]

Please note that the Vagrant issue tracker is reserved for bug reports and
enhancements. For general usage questions, please use the Vagrant mailing list:
https://groups.google.com/forum/#!forum/vagrant-up. Thank you!

Vagrant version

Run vagrant -v to show the version. If you are not running the latest version
of Vagrant, please upgrade before submitting an issue.
Vagrant 1.8.5

Host operating system

This is the operating system that you run locally.
Windows 10

Guest operating system

This is the operating system you run in the virtual machine.
Not running under Guest , directly under host

Vagrantfile

```Vagrant.configure("2") do |config|
config.ssh.insert_key=false
config.vm.provider "virtualbox" do |vb|
vb.gui = true
vb.memory = "2048"
end
config.vm.define "lb1" do |lb1|
lb1.vm.box="centos/7"
end
config.vm.define "web1" do |web1|
web1.vm.box="centos/7"
end
config.vm.define "web2" do |web2|
web2.vm.box="centos/7"
end
end

Please note, if you are using Homestead or a different Vagrantfile format, we
may be unable to assist with your issue. Try to reproduce the issue using a
vanilla Vagrantfile first.

### Debug output
Command Executed: vagrant up

Bringing machine 'lb1' up with 'virtualbox' provider...
Bringing machine 'web1' up with 'virtualbox' provider...
Bringing machine 'web2' up with 'virtualbox' provider...
==> lb1: Checking if box 'centos/7' is up to date...
==> lb1: Clearing any previously set forwarded ports...
==> lb1: Fixed port collision for 22 => 2222. Now on port 2200.
==> lb1: Clearing any previously set network interfaces...
==> lb1: Preparing network interfaces based on configuration...
lb1: Adapter 1: nat
==> lb1: Forwarding ports...
lb1: 22 (guest) => 2200 (host) (adapter 1)
==> lb1: Running 'pre-boot' VM customizations...
==> lb1: Booting VM...
==> lb1: Waiting for machine to boot. This may take a few minutes...
lb1: SSH address: 127.0.0.1:2200
lb1: SSH username: vagrant
lb1: SSH auth method: private key
Timed out while waiting for the machine to boot. This means that
Vagrant was unable to communicate with the guest machine within
the configured ("config.vm.boot_timeout" value) time period.

If you look above, you should be able to see the error(s) that
Vagrant had when attempting to connect to the machine. These errors
are usually good hints as to what may be wrong.

If you're using a custom box, make sure that networking is properly
working and you're able to connect to the machine. It is a common
problem that networking isn't setup properly in these boxes.
Verify that authentication configurations are also setup properly,
as well.

If the box appears to be booting properly, you may want to increase
the timeout ("config.vm.boot_timeout") value.

### Expected behavior
What should have happened?

All three Virtual machines should have booted up

### Actual behavior
What actually happened?
Only first one starts
### Steps to reproduce
vagrant up

### References
Are there any other GitHub issues (open or closed) that should be linked here?
For example:
https://github.com/mitchellh/vagrant/issues/7176

[gtirloni]

See #7610

[renansfs]

I had the same problem this week. At least it worked for me. I changed the network adapter of the VM from Intel to AMD . It worked.

[ameyaagashe]

@gtirloni Doesn't work, I have already tried chmod 0600 authorized_keys, doesn't work.
@renansfs DOesn't work still.

[naftulikay]

The issue is fixed here: https://github.com/mitchellh/vagrant/commit/a6760dd8e7743e048cb2f38c474e05889356e8ac#diff-13c7ed80ab881de1369e3b06c66745e8

I found it by just playing around in that directory. Hopefully they'll release a fixed version soon :dizzy_face:

[AlphaCactus]

@gtirloni @rfkrocktk #7610 does fix a bug, but it is not the same bug as this issue. I can reproduce this issue on Windows 10x64 with Virtual Box 5.1.2 and Vagrant 1.8.5.

vagrant init centos/7
vagrant up

SSH authorization fails and retries until timeout.
Login from gui and manually set 0600 on authorized_keys

vagrant reload
==> default: Machine booted and ready!
vagrant package --output myboxnext.box
vagrant box add myboxnext.box
cd ../myboxnext
vagrant init myboxnext
vagrant up

result is that it halts at default: SSH auth method: private key as described above, it does not attempt to retry authentication and times out. I can login with the gui and authorized_keys is set to 0600 which also indicates that this is a new package and not the orignal centos/7 package.

[naftulikay]

I'm on a Linux host running a Linux guest. That may have done things differently for me. I was able to get it working by manually applying the patch mentioned in my comment above.

[austinbutler]

Sounds more like https://github.com/mitchellh/vagrant/issues/7648 to me. Try the workaround in https://github.com/mitchellh/vagrant/issues/7648#issuecomment-235282382 for now.

[chrisroberts]

Looks like this is one of either #7610 or #7648, both of which have been addressed so closing this up.

[cnschulz]

I can confirm that enabling CPU virtualisation in the BIOS fixed this for me.

[Nomane]

I confirm too

[keltik85]

I do not confirm any of the fixes to be working.

[edin-m]

Had virtualization enabled in BIOS, but I also had to disable Hyper-V in Windows 10 Programs and Features - might help somebody. Created new vagrant machine and it worked.

[florianmuellerCH]

To me it was the solution to enable CPU virtualisation too! Thanks @cnschulz !
Maybe in combination with the adding of the following lines to the Vagrantfile (according to the other posts):
config.vm.network "forwarded_port", guest: 22, host: 2222, host_ip: "127.0.0.1", id: 'ssh' config.vm.provider "virtualbox" do |vb| vb.customize ["modifyvm", :id, "--cableconnected1", "on"] end

[montao]

Not working. We can't just expect users being able to change their BIOS settings. Not everybody is a superuser. I tried everything and nothing works. My Vagrant installation is useless.

[chrisroberts]

Hi there. Enabling of CPU virtualization in the BIOS has to be performed by the user. This is not something that Vagrant can control, nor the virtualization software that Vagrant utilizes (like VirtualBox). There are many guides online available for different BIOS versions that can tell you how to open your system BIOS and what needs to be updated. Unfortunately, this is not something that can be done by Vagrant, nor by the virtualization software. It must be done by the user, and there is no way that can be avoided. My apologies for the inconvenience.

Cheers!

[MatheusRV]

Try add export VAGRANT_WSL_WINDOWS_ACCESS_USER_HOME_PATH="/mnt/c/temp" in bash and reopen your bash.

Works here on Windows 10 1803 17134.285 WSL vagrant 2.1.5 and vbox 5.2.18 r124319

ReadMore:
https://github.com/hashicorp/vagrant/issues/7648
https://github.com/hashicorp/vagrant/issues/8742
https://github.com/hashicorp/vagrant/issues/9143

[beancurd1]

Mine because I enabled Hyper-V (or enabled by default) on my Win10. VirtualBox v6+ did not prompt anything, just hung. I installed v5.2 and it prompted an error saying VT-x wasn't enabled. I then google it and found this. It worked after removing Hyper-V!!!

https://social.technet.microsoft.com/Forums/windows/en-US/118561b9-7155-46e3-a874-6a38b35c67fd/hyperv-disables-vtx-for-other-hypervisors?forum=w8itprogeneral

[phax]

Vagrant 2.2.4 with Virtual Box 6.0.4 on Windows 10 failed - the vmmem.exe process was in an endless loop and the machine came never up with the named error message. Disabling Hyper V and restarting helped me to get a VM up and running.

[jeremy-mccabe]

Start -> Turn Windows features on or off -> Uncheck Hyper-V -> OK -> Restart
Worked for me.

[fmeum]

I was able to resolve this issue as suggested in https://github.com/ByteInternet/hypernode-vagrant/issues/140#issuecomment-543644023 by changing the standard Vagrant port for SSH on the host from 2222 to a higher port such as 4000.

[hashibot[bot]]

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.