Questions & Answers

Vagrant hangs at "SSH auth method: Private key

I am running VirtualBox 5.0.24 and Vagrant 1.8.5 on Digital Ocean VPS running on Ubuntu 14.04 LTS Precise I am using the box ubuntu/precise64 Everything works fine but when i do vagrant up it hangs at the

SSH auth method: Private key

and the exit out giving time out. Now, i can consider increasing the execution time but it already takes a fare amount of time before giving that error. I don't know what I am doing wrong. Here is my VAGRANTFILE

# -*- mode: ruby -*-
# vi: set ft=ruby :

Vagrant.configure("2") do |config| = "ubuntu/precise64"
  config.vm.provider :virtualbox do |vb|
    vb.customize ['modifyvm', :'1cf9e703-607e-4338-9162-20abbeca94b0', '--pae', 'on']
    vb.customize ['modifyvm', :'1cf9e703-607e-4338-9162-20abbeca94b0', '--hwvirtex', 'off']
    vb.customize ['modifyvm', :'1cf9e703-607e-4338-9162-20abbeca94b0', '--vtxvpid', 'off']

2023-01-07 20:30:17
Answers(18) :

Be sure to look at the VM terminal on VirtualBox while vagrant is hanging. For me the issue was a broken file system.

I ran:

fsck -yf /dev/mapper/homestead--vg--root

from the VirtualBox terminal and the issue was resolved.

I had this issue also and I fixed it by opening up the "Oracle Virtual Box Manager" GUI. Go to "Settings" -> "Network" and choose "Adapter 1" then expand the option by clicking on the arrow and make sure that "Cable Connected" is checked.

2023-01-07 20:30:17
Thanks so much for this tip. I had been stuck on this issue for about a day and this solved it for me.
2023-01-07 20:30:17
The option "Cable Connected" was checked by default. I'm still facing the same issue.
2023-01-07 20:30:17
If you guys still have issues after doing this, I recommend you following this answer from a similar question:
2023-01-07 20:30:17
After 4 hrs of being stuck, I found this comment. It was checked, but I simply unchecked it and checked it again and in the background the provisioning continued and unstuck. Thank you so much.
2023-01-07 20:30:17
Thank you so much. But it was ticked & the same issue was there. However, the issue was fixed after I added "private_network", ip: "", auto_config: false to the Vagrantfile and also tick the 'Cable connected' as well. Not sure both were necessary to fix the issue.

I was getting stuck in Windows too at the same SSH auth method: Private key (trying to SSH to an Ubuntu box), and then I get a timeout after a few minutes.

Beware if you are running multiple SSH agents (maybe involuntary). For example, in Windows, you could have both Pageant and OpenSSH Authentication Agent (the ladder you can find under Windows Services). In my case, the private key was added under Pageant but OpenSSH Authentication Agent seems to have taken priority after an OS restart.

Ended up disabling the latter, restarting the OS, loading the key again in Pageant, and then vagrant ssh worked.

I came across this issue when trying use virtualisation (virtualbox + vagrant) on an AWS EC2 Ubuntu 16.04 instance. Apparently, it seems it's not possible because Amazon decided to block that option - virtualbox installation will fail / you will get the message in the title when trying 'vagrant up'. As said in this article (a bit old, but convinced me):

A more complex solution can be found here - but I didn't try it to see if it works:

HVX: Virtual infrastructure for the cloud

Found the following solution on some arcane forum, it works by adding it to the bottom of your Vagrantfile just before the line that says end:

    config.vm.provider "virtualbox" do |vb|
        vb.customize ["modifyvm", :id, "--cableconnected1", "on"]

Does the same as manually changing the setting in VirtualBox AFAIK, but I personally prefer infrastructure as code solutions. That way a colleague doesn't have to deal with the same problem somewhere down the line.

2023-01-07 20:30:17
This works best! When sharing your vagrantfile (i.e. because you're working in a team) this is definitely the way to go

In my case, I had gotten into a sort of an invalid state. Running this command before vagrant up did the trick.

Note: Use with caution, as this will clear all data on the vagrant instance.

vagrant destroy --force

Well, i faced similar issue and got the resolution in the below thread: This was caused by me running docker desktop on windows 10, which uses windows SubsystemLinux and utilized Hyper-v to launch the Virtual env. This does not allow or makes Virtual box too slow to respond that the ssh times out and also results in File system errors. you should specially focus on the "turtle" icon which means Virtualbox too slow and i if everything is fine then you will see the "V" icon on virtualbox console. follow the instruction to stop hyper-v reboot the machine and it will work. To turn Hyper-V off completely, do this:

  1. Shut down all programs. You will have to reboot your host.

  2. See I have a 64bit host, but can't install 64bit guests. This tutorial has a couple more things to look for in step 2. Be sure these are all turned off.

  3. Find the Command Prompt icon, right click it and choose Run As Administrator.

  4. Enter this command: bcdedit /set hypervisorlaunchtype off

  5. Enter this command: shutdown -s -t 2

  6. When the computer turns off, unplug it for 20 seconds. Then plug it in again and boot up Windows 10.

I had docker installed, this is why i had this issue. To solved it, i did the following:

systemctl stop docker.service
systemctl stop docker.socket
vagrant destroy
vagrant up

Now it works fine.

I had this issue also and I fixed it by opening up the "Oracle Virtual Box Manager" GUI and go to "Settings" -> "Network" and choose "Adapter 1" then expand the option by clicking on the arrow and make sure that "Cable Connected" is checked.

I tried this answer and found that this was already enabled by default. I Tried disabling and re-enabling and this first gave me the following message Warning: Connection aborted. Retrying... after which vagrant continued the startup and did so successfully

2023-01-07 20:30:18
Welcome to SO Rick. Please notice that your post is not really an answer to the question. Once you have sufficient reputation, if you have a contribution that can improve an existing answer, please comment on it instead of answering again.

Seems like the latest versions are not working on a VPS. I had to choose the older versions of the softwares to run them on this ubuntu VPS The versions i chose was

VirtualBox >= 4.3.12


Vagrant >= 1.5.3

This works but you will have to configure ssh

2023-01-07 20:30:18
What was the solution?

Following the advice from user Kokokoko above I added the following lines to my vagrnt file.

vb.customize ["modifyvm", :id, "--uart1", "0x3F8", "4"]
vb.customize ["modifyvm", :id, "--uartmode1", "file", File::NULL]

installed the latest virtualbox, made sure the vm was halted properly and it worked for me.

using Virtualbox 6.1.32 with Vagrant 2.2.10 with Ubuntu/Xenial64

After spending weeks reading and testing all the answers I found, even the answers that were not marked as correct, I don't remember where, someone mentioned something about Guest Additions... I found the plugin and installed it:

    vagrant plugin install vagrant-vbguest

It works like a charm. Problem solved.

Stack: Virtualbox 6.0, Vagrant 2.2.7, OS Fedora 31

My version virtualbox(5.1.20), vagrant(1.9.3). I solve this error by deleting

v.customize ["modifyvm", :id, "--natdnshostresolver1", "on"]

I´m newbie, hope this help.

enter image description here

I found that my WSL enabled on my Windows 10 so disabled it by using this command

bcdedit /set hypervisorlaunchtype off

but it didn't helped me so i went through Windows features and found that Virtual Machine Platform was turned ON so i look it up and it was linked to WSL so i turned it OFF and my ssh key problem solved.

2023-01-07 20:30:18
Same problem on my side. I think there's an incompatibility issue between Vagrant/VirtualBox & Windows Hypervisor Platform. The way I got Vagrant & WSL 2 working side was to enable/disable the following windows features: + Virtual Machine Platform: On - Windows Hypervisor Platform: Off + Windows Subsystem for Linux: On
2023-01-07 20:30:18
Shoot, I need the Hypervisor. How do we get around this without disabling the Hypervisor? Using the virtual machine in a Hypervisor Win10 VM with the feature disabled is all I can think of but I think 2 layers of VM's might cause problems too.
2023-01-07 20:30:18
@bean I had to disable Virtual Machine Platform feature, but after that vagrant works again (WSL does not). So, WSL2 breaks vagrant on Windows.
2023-01-07 20:30:18
Update 2021: Microsoft WSL 2 has fixed the issue where it broke VirtualBox Virtualization. Now you can run WSL and VirtualBox together without any issue.
2023-01-07 20:30:18
@Myster-Mayur what is the current setup? my windows 10 did an update recently and I'm back to vagrant not working. I have Virutal Machine Platform: On, Win Hypervisor Platform: Off, and Win Subsys for Linux: Off. What's the new correct config?

UPDATE AS OF MAY 2021: So I found that this was an actual bug in Vagrant. The solution comes directly from Hashicorps' GitHub.

Basically open the vagrantfile and add these lines under config.vm.provider :virtualbox do |v| and before end:

v.customize ["modifyvm", :id, "--uart1", "0x3F8", "4"]
v.customize ["modifyvm", :id, "--uartmode1", "file", File::NULL]

If the line is config.vm.provider :virtualbox do |vb| then the code will be:

vb.customize ["modifyvm", :id, "--uart1", "0x3F8", "4"]
vb.customize ["modifyvm", :id, "--uartmode1", "file", File::NULL]

Solved on Windows 11, Virtual Box Version 6.1.40 r154048 (Qt5.6.2), Vagrant 2.3.4

Let's first understand some basic DHCP concepts. If you open up Virtual Box and go to File > Host Network Manager OR type Ctrl + H you will see the following window.

enter image description here

What you need to understand is that a DHCP server simple allocates IPs to new virtual machines in this context.

Click on the DCHP Server tab to see the range of available IP addresses.

enter image description here

What this picture is telling us is that we can allocate IP's ranging from 101 < n < 254 where n is placed on 192.168.56.n

So in our Vagrant file we can do, I picked an arbitrary box:

# -*- mode: ruby -*-
# vi: set ft=ruby :

# All Vagrant configuration is done below. The "2" in Vagrant.configure
# configures the configuration version (we support older styles for
# backwards compatibility). Please don't change it unless you know what
# you're doing.
Vagrant.configure("2") do |config| = "ubuntu/xenial64"

  config.vm.define "web" do |web| "private_network", ip: "", virtualbox__intnet: false


  config.vm.define "db" do |db| "private_network", ip: "", virtualbox__intnet: false

If you want to see the progress of your VM, click on Show enter image description here

It will show you a command line displaying logs of the process

Once that is done, you can ping both of your machines from your host command line:


Pinging with 32 bytes of data:
Request timed out.
Request timed out.
Reply from bytes=32 time=1ms TTL=64
Reply from bytes=32 time=1ms TTL=64

As you can see, oddly enough the first pings timed out but after that they start reaching the VM. For this, I don't have an explanation but it works afterwards.

The virtualbox__intnet: false option basically tells Vagrant to allow connectivity from the host to the VMs. Otherwise, the VMs would only be able to communicate between each other but not the outside world. Here's the doc reference for that

uninstall "open ssh server" & "open ssh client" from "apps => optional feautures", and reinstal "open ssh server" & "open ssh client" enter image description here

Having recently run into this problem myself, I concluded that installing Docker Destkop for Windows caused a series of changes to my system that essentially broke VirtualBox with Vagrant.

I have concluded the following steps as my minimum viable resolution:

  1. Uninstall Docker Desktop Client
  2. Disable a series of Windows Features that are related to virtualization or containers
  3. Check CPU-Z and Intel Processor Identification Utility to verify that VT-x is now enabled
  4. Run a vagrant reload on my VM in question
  5. Uncheck cable connected and re-check cable connected
  6. vagrant ssh now works.

I will need to restore each feature one at a time to see how far I can go before breaking this again.

Here's a screenshot of the various tidbits, and the pointers:

(1) Disabled Containers in Windows (2) Disabled Hyper-V (3) Disabled Virtual Machine Platform (4) Disabled Windows Hypervisor Platform (5) Disabled WSL (6) Now VT-x shows up again (it was not showing up previously) (7) Now SLAT shows up again (it was not showing up previously) (8) CPU-Z sees VT-x as well

I now also note that Enable Nested VT-x is no longer greyed out on my CPU settings menu in VirtualBox.

enter image description here