Vagrant up hangs at "ssh auth method: private key"

Question

I've been having some issues getting vagrant version 1.8.1 to run with virtualbox 5.0.10, box precise64. My operating system is Windows 7.

Essentially, when I run

vagrant up

...this happens

So far, I've attempted the following:

opening another command line and running a myriad of different codes, including:

vagrant ssh
vagrant ssh-config
ssh 127.0.0.1 

I've also attempted the fix shown on this video (to no avail)

https://www.youtube.com/watch?v=vDQpfb0eFTc

As well as manually specifying the ssh key, and changing the ssh key.

My attempts to ssh into the box manually are met with a "connection refused" error.

When I open the VM GUI through virtualbox, it stops at the login page, rather than the boot menu others have reported.

My vagrantfile is unmodified, however I've attempted all of the above with additions:

config.ssh.username = "vagrant"
config.ssh.password = "vagrant"

.. which didn't work

I also attempted adding this (with and without the above Vagrantfile additions)

config.ssh.private_key_path = "C:/Users/Luka/.vagrant.d/insecure_private_key"

Which also gave me nothing.

Answer 1

I know this is an old topic, but I ran into the same issue and for me the solution was to enable the Hardware virtualization in BIOS (VT-x), which is required on Windows OS to run any kind of virtual machine.

I hope this will help someone who stumbles into this.

Answer 2

Happened to me with "ubuntu/focal64". I tried different solutions, but nothing worked.
Switch box to "ubuntu/xenial64" - everything loads successfully.

My setup:
win10 home 10.0.19041 Build 19041
vagrant 2.2.9
virtualbox 6.2

Answer 3

I spent multiple hours trying to troubleshoot this issue, and tried every solution listed above and more, and I wasn't getting anywhere.

The error I was getting when running vagrant up:

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

I decided to pursue this event I was seeing in the VirtualBox log for my running VM:

00:00:01.752390 HM: HMR3Init: Attempting fall back to NEM: VT-x is not available

When I saw that, I decided to check using the "Intel Processor Identification Utility" (from Intel's website) to verify if VT-x was enabled or not. To my surprise, it showed that "Intel Virtualization Technology" was disabled:

I was pretty sure VT-x was enabled in my BIOS, but I checked again to make sure. Indeed, VT-x was enabled in my BIOS.

Pretty stumped by what I was seeing, I kept looking on the internet as to why VT-x was enabled in BIOS, but showing as disabled by the OS. A lot of articles kept pointing at "Hyper-V" being the culprit. So I uninstalled "Hyper-V" using the Windows Features utility [as well as my Docker Desktop" because it relies on Hyper-V to function], but the Intel CPU identification utility kept showing VT-x as disabled.

Next thing I tried was to remove all the items that are identified as "interfering" with Hyper-V in the Windows 10 "Windows Features" [listed as "Turn Windows features on or off" in the search bar]. The items in red are the ones I removed:

1. Containers
2. Hyper-V
3. Virtual Machine Platform
4. Windows Hypervisor Platform
5. Windows Subsystem for Linux

I restarted my PC, again, I checked the status of VT-x with the CPU identification utility, and still, it was disabled.

At this point I was pretty much going to throw the towel at the issue until I found some article where someone ran this command manually in an elevated command prompt (cmd.exe):

dism.exe /Online /Disable-Feature:Microsoft-Hyper-V

I restarted my PC, checked the status of VT-x with the CPU identification utility, to my surprise it was showing as ENABLED!!:

When I checked the VirtualBox logs from my running VM after VT-x showed as enabled, I could see the following event instead:

00:00:01.556258 HM: HMR3Init: VT-x w/ nested paging and unrestricted guest execution hw support

In my command-line window, after vagrant up, I could now see:

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: Machine booted and ready!

My solution in a nutshell?

Make sure the OS sees VT-x as enabled using a utility such as "Intel Processor Identification Utility" [Or whatever utility depending on your CPU architecture]. I believe there is a bug in Windows 10 that causes this issue, but I haven't been able to put my finger on it (and I don't have time to do so). It seems Hyper-V is the root cause of all the issues. For the people concerned about not being able to use Docker Desktop anymore, I believe there are alternatives out there for non-Hyper-V solutions (i.e. free Docker EE??).

Good luck.

Answer 4

I also got this issue when I am trying to use laravel/homestead vagrant box. For me, I found out that the issue is caused by WindowsFeature VirtualMachinePlatform. I have enabled it since I am using WSL 2 in my machine. Simply disabling that feature helped with the issue.

To disable the VirtualMachinePlatform feature, open PowerShell as an Administrator and run:

dism.exe /online /Disable-Feature /FeatureName:VirtualMachinePlatform /NoRestart

Then Restart your machine and try vagrant up. It worked for me.

You can enable the VirtualMachinePlatform feature again by simply running the below command on PowerShell as an Administrator:

dism.exe /online /Enable-Feature /FeatureName:VirtualMachinePlatform /all /NoRestart

Then Restart your machine again and the feature is enabled again.

I have reported an issue regarding this also. If anyone needs to keep track on that bug click here