"vagrant up" it stops at SSH auth method: private key

17,278

Solution 1

(Posted on behalf of the OP).

Solution: I activated the Hardware acceleration in the BIOS environment.

Solution 2

I had the same issue today and I found that my VirtualBox Settings (Network | Advanced | Cable Connected) were set correctly (that is the checkbox was checked.) I started comparing this VM, which has been stable for months, with some of my other VMs and found the only difference was in the Network Adapters, as Adapter 2 was different than all the rest.

Adapter 1 was set to the following:

Attached To:   NAT
Adapter Type:  Intel PRO/1000 MT Desktop ....

while Adapter 2 was set to the following...

Attached To:   Host-only Adapter
Adapter Type:  PCnet-FAST III ...

I have not changed any of these network settings in VirtualBox, ever. Once I set Adapter 2 Adapter Type to the same settings as Adapter 1 as stated above, I then vagrant halt and vagrant up and back to normal.

Solution 3

After a couple of days of trying to solve the problem with "SSH auth method: private key", it was found that windows 10 has a conflict with vagrant.

As a tool to validate the status of virtualization, the program was used: "https://www.intel.com/content/www/us/en/download/12136/28539/intel-processor-identification-utility-windows-version .html "

I show you the capture of the initial state: enter image description here

Fix it by disabling the following windows features: enter image description here

Once the aforementioned features were deactivated and the computer was restarted, I share the new state of the processor where it is evident that virtualization is already working: enter image description here

PS: On saying that you already activate virtualization on the board (bios)

With this solution already vagrant works perfectly for me.

Solution 4

I had this problem and this is how I got get Vagrant & WSL2 working side by side

I have the following environment:

  • Hardware Virtualization enabled in BIOS

  • Windows 10 (Insider Program with Release Preview Channel)

    -- Windows 10 with WSL 2 Version 10.0.19041 Build 19041

  • VirtualBox 6.1.12

    -- Extension Pack Installed

  • Vagrant 2.2.9

These are the settings that worked for me:

  • Windows Hypervisor Platform: Off
  • Virtual Machine Platform: On
  • Windows Subsystem for Linux: On

enter image description here

Solution 5

the firewall message blocked the box of boot.

step 1

vagrant file:

config.vm.provider "virtualbox" do |vb|
   vb.gui = true
end

step 2

sudo user:

sudo ufw disable

Share:
17,278
Arnau Guadall
Author by

Arnau Guadall

I'm in love with Web Technologies and discover new things to stay tune in this world.

Updated on June 26, 2022

Comments

  • Arnau Guadall
    Arnau Guadall almost 2 years

    I'm trying to install laravel on my computer with homestead environment. I followed all steps on the official documentation. And when I execute my "vagrant up" my console displays the following error.

    vagrant up error.

    Stops at SSH auth method. Previously I configured the ssh-keygen with "ssh-keygen -t rsa -b 4096 -C "[email protected]"

    I added the host piece at .rb file: Hosts

    Even .yaml file. I think I edited properly yaml file

    At hosts file I added: "192.168.10.10 administracio.dev" at the bottom of the file.

    And then when I let this error crash it shows the following error:

    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.
    

    Any suggestions?