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

Vagrant freezes on 'SSH auth method: private key' #8157

Closed
PeterDavidCarter opened this Issue Dec 28, 2016 · 68 comments

Comments

Projects
None yet
@PeterDavidCarter

PeterDavidCarter commented Dec 28, 2016

Vagrant version

v1.9.1

Host operating system

Windows 10

Guest operating system

Homestead/Ubuntu 16.04

Vagrantfile

require 'yaml'

VAGRANTFILE_API_VERSION ||= "2"
confDir = $confDir ||= File.expand_path("vendor/laravel/homestead", File.dirname(__FILE__))

homesteadYamlPath = "Homestead.yaml"
homesteadJsonPath = "Homestead.json"
afterScriptPath = "after.sh"
aliasesPath = "aliases"

require File.expand_path(confDir + '/scripts/homestead.rb')

Vagrant.configure(VAGRANTFILE_API_VERSION) do |config|
    if File.exists? aliasesPath then
        config.vm.provision "file", source: aliasesPath, destination: "~/.bash_aliases"
    end

    if File.exists? homesteadYamlPath then
        Homestead.configure(config, YAML::load(File.read(homesteadYamlPath)))
    elsif File.exists? homesteadJsonPath then
        Homestead.configure(config, JSON.parse(File.read(homesteadJsonPath)))
    end

    if File.exists? afterScriptPath then
        config.vm.provision "shell", path: afterScriptPath
    end
end

Debug output

Debug output (Gist)

Expected behavior

The vagrant box was expected to authenticate via private key.

Actual behavior

The vagrant box froze on authenticating via private key.

Steps to reproduce

  1. Run vagrant up with the vagrantfile reproduced above.

References

I note that the solutions suggested for bypassing private key authentication do not appear to work on my setup with my version of Vagrant. The following suggested solution:

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

require 'json'
require 'yaml'

VAGRANTFILE_API_VERSION ||= "2"
confDir = $confDir ||= File.expand_path("~/.homestead")

homesteadYamlPath = confDir + "/Homestead.yaml"
homesteadJsonPath = confDir + "/Homestead.json"
afterScriptPath = confDir + "/after.sh"
aliasesPath = confDir + "/aliases"

require File.expand_path(File.dirname(__FILE__) + '/scripts/homestead.rb')

Vagrant.require_version '>= 1.8.4'

Vagrant.configure(VAGRANTFILE_API_VERSION) do |config|
    if File.exist? aliasesPath then
        config.vm.provision "file", source: aliasesPath, destination: "/tmp/bash_aliases"
        config.vm.provision "shell" do |s|
          s.inline = "awk '{ sub(\"\r$\", \"\"); print }' /tmp/bash_aliases > /home/vagrant/.bash_aliases"
	config.vm.network :private_network, ip: "192.168.10.10", :netmask => "255.255.255.0", auto_config: false
        end
    end
    config.vm.provider "virtualbox" do |vb|
        ### Change network card to PCnet-FAST III
	# For NAT adapter
        vb.customize ["modifyvm", :id, "--nictype1", "Am79C973"]
        # For host-only adapter
        vb.customize ["modifyvm", :id, "--nictype2", "Am79C973"]
      end

    if File.exist? homesteadYamlPath then
        settings = YAML::load(File.read(homesteadYamlPath))
    elsif File.exist? homesteadJsonPath then
        settings = JSON.parse(File.read(homesteadJsonPath))
    end

    config.vm.provision "shell", inline: <<-SHELL
        rm -f /etc/network/interfaces.d/eth1.cfg
	echo "auto eth1" >> /etc/network/interfaces.d/eth1.cfg
	echo "iface eth1 inet static" >> /etc/network/interfaces.d/eth1.cfg
	echo "address 192.168.10.10" >> /etc/network/interfaces.d/eth1.cfg
	echo "netmask 255.255.255.0" >> /etc/network/interfaces.d/eth1.cfg
	ifdown eth1 && ifup eth1
      SHELL

    Homestead.configure(config, settings)

    if File.exist? afterScriptPath then
        config.vm.provision "shell", path: afterScriptPath, privileged: false
    end

    if defined? VagrantPlugins::HostsUpdater
        config.hostsupdater.aliases = settings['sites'].map { |site| site['map'] }
    end
end

Still results in Vagrant checking for private key and stalling at this point.

...

@tapsboy

This comment has been minimized.

Show comment
Hide comment
@tapsboy

tapsboy Dec 29, 2016

I have the same issue on OSX 10.11.6 (El Capitan) and Vagrant 1.9.1

Update: Weird. It doesn't happen anymore after reinstalling vagrant.

Earlier, I did brew cask reinstall vagrant; vagrant plugin repair, where I ended up with frozen state

After running brew cask uninstall vagrant; brew cask install vagrant, it started working fine

tapsboy commented Dec 29, 2016

I have the same issue on OSX 10.11.6 (El Capitan) and Vagrant 1.9.1

Update: Weird. It doesn't happen anymore after reinstalling vagrant.

Earlier, I did brew cask reinstall vagrant; vagrant plugin repair, where I ended up with frozen state

After running brew cask uninstall vagrant; brew cask install vagrant, it started working fine

@PeterDavidCarter

This comment has been minimized.

Show comment
Hide comment
@PeterDavidCarter

PeterDavidCarter Dec 29, 2016

Reinstall of Vagrant didn't work for me, but I'm going to zero everything (cloned Homestead repository, Laravel box file etc) and try again later today. Will add comment with results.

PeterDavidCarter commented Dec 29, 2016

Reinstall of Vagrant didn't work for me, but I'm going to zero everything (cloned Homestead repository, Laravel box file etc) and try again later today. Will add comment with results.

@PeterDavidCarter

This comment has been minimized.

Show comment
Hide comment
@PeterDavidCarter

PeterDavidCarter Dec 29, 2016

Removed Vagrant, Git Bash, Homestead and Laravel box and all references. Reinstalled all of these programmes using default settings. Deleted all private and public RSA keys and regenned without passphrase. Still sticks on SSH auth method: private key and will not progress past this step.

PeterDavidCarter commented Dec 29, 2016

Removed Vagrant, Git Bash, Homestead and Laravel box and all references. Reinstalled all of these programmes using default settings. Deleted all private and public RSA keys and regenned without passphrase. Still sticks on SSH auth method: private key and will not progress past this step.

@FibreFoX

This comment has been minimized.

Show comment
Hide comment
@FibreFoX

FibreFoX Jan 14, 2017

Same here, running on a more simple setup:

Vagrant.configure("2") do |config|
  config.vm.box = "debian/contrib-jessie64"
  
  config.vm.network "public_network"
  config.vm.provider "virtualbox" do |vb|
    vb.gui = true
    vb.memory = "1024"
  end
  config.vm.provision "shell", inline: <<-SHELL
    apt-get update
  SHELL
end

Will try to use different Vagrant-versions and report back/update this message.

Running Vagrant 1.9.1 with VirtualBox 5.1.12 on Windows 10 Home 64bit.

EDIT: same (non working) behaviour when changing to Vagrant 1.8.7 and VirtualBox 5.1.12

EDIT 2: just checked the hint about changing network-cards, even tried to use "virtio", but did not work for me

EDIT 3: just tried some GIST mentioned at #3860 (comment), which is now available as https://gist.github.com/kumaxim/5277f9ac1ab4312b6ec5 ... but failed to work, stopped at "default: SSH auth method: private key" again.

EDIT 4: after fiddling nearly an hour, I recognize that I get a TIMEOUT when trying to get a connection with PuTTY, this is important, because I get "response" instead of nothing ... Changing that network-interface to "bridge-mode", I can get a NORMAL connection. Maybe a problem with port-forwarding?!

While searching a way to make it work, I tried different versions of vagrant and virtualbox.
using vagrant 1.9.1
and virtualbox 5.0.30
and virtualbox 5.1.51 (nightly build)

using vagrant 1.8.5
and virtualbox 5.0.30
and virtualbox 5.1.51 (nightly build)

Nothing worked so far!!! And yes, there are a lot of issues which can be found regarding networking-problems:
#7583
#7791
#7995
#8024
#8096
#8115

Will report back after checking with a different windows machine.

FibreFoX commented Jan 14, 2017

Same here, running on a more simple setup:

Vagrant.configure("2") do |config|
  config.vm.box = "debian/contrib-jessie64"
  
  config.vm.network "public_network"
  config.vm.provider "virtualbox" do |vb|
    vb.gui = true
    vb.memory = "1024"
  end
  config.vm.provision "shell", inline: <<-SHELL
    apt-get update
  SHELL
end

Will try to use different Vagrant-versions and report back/update this message.

Running Vagrant 1.9.1 with VirtualBox 5.1.12 on Windows 10 Home 64bit.

EDIT: same (non working) behaviour when changing to Vagrant 1.8.7 and VirtualBox 5.1.12

EDIT 2: just checked the hint about changing network-cards, even tried to use "virtio", but did not work for me

EDIT 3: just tried some GIST mentioned at #3860 (comment), which is now available as https://gist.github.com/kumaxim/5277f9ac1ab4312b6ec5 ... but failed to work, stopped at "default: SSH auth method: private key" again.

EDIT 4: after fiddling nearly an hour, I recognize that I get a TIMEOUT when trying to get a connection with PuTTY, this is important, because I get "response" instead of nothing ... Changing that network-interface to "bridge-mode", I can get a NORMAL connection. Maybe a problem with port-forwarding?!

While searching a way to make it work, I tried different versions of vagrant and virtualbox.
using vagrant 1.9.1
and virtualbox 5.0.30
and virtualbox 5.1.51 (nightly build)

using vagrant 1.8.5
and virtualbox 5.0.30
and virtualbox 5.1.51 (nightly build)

Nothing worked so far!!! And yes, there are a lot of issues which can be found regarding networking-problems:
#7583
#7791
#7995
#8024
#8096
#8115

Will report back after checking with a different windows machine.

@FibreFoX

This comment has been minimized.

Show comment
Hide comment
@FibreFoX

FibreFoX Jan 15, 2017

Same non-working behaiour on Windows 8.1 64bit Pro using Vagrant 1.9.1 with VirtualBox 5.1.4

FibreFoX commented Jan 15, 2017

Same non-working behaiour on Windows 8.1 64bit Pro using Vagrant 1.9.1 with VirtualBox 5.1.4

@FibreFoX

This comment has been minimized.

Show comment
Hide comment
@FibreFoX

FibreFoX Jan 15, 2017

DEBUG ssh: == Net-SSH connection debug-level log START ==
DEBUG ssh: D, [2017-01-15T01:19:49.798332 #8564] DEBUG -- net.ssh.transport.session[354924c]: establishing connection to 127.0.0.1:2222

DEBUG ssh: == Net-SSH connection debug-level log END ==
 INFO ssh: SSH not ready: #<Vagrant::Errors::NetSSHException: An error occurred in the underlying SSH library that Vagrant uses.
The error message is shown below. In many cases, errors from this
library are caused by ssh-agent issues. Try disabling your SSH
agent or removing some keys and try again.

If the problem persists, please report a bug to the net-ssh project.

Net::SSH::ConnectionTimeout>

Calling vagrant up --debug > start.log 2>&1 shows the part above ... is it just me, or is something broken with NAT-communication? Running netstat does not show anything to listen on any interface regarding SSH 22 nor 2222.

FibreFoX commented Jan 15, 2017

DEBUG ssh: == Net-SSH connection debug-level log START ==
DEBUG ssh: D, [2017-01-15T01:19:49.798332 #8564] DEBUG -- net.ssh.transport.session[354924c]: establishing connection to 127.0.0.1:2222

DEBUG ssh: == Net-SSH connection debug-level log END ==
 INFO ssh: SSH not ready: #<Vagrant::Errors::NetSSHException: An error occurred in the underlying SSH library that Vagrant uses.
The error message is shown below. In many cases, errors from this
library are caused by ssh-agent issues. Try disabling your SSH
agent or removing some keys and try again.

If the problem persists, please report a bug to the net-ssh project.

Net::SSH::ConnectionTimeout>

Calling vagrant up --debug > start.log 2>&1 shows the part above ... is it just me, or is something broken with NAT-communication? Running netstat does not show anything to listen on any interface regarding SSH 22 nor 2222.

@FibreFoX

This comment has been minimized.

Show comment
Hide comment
@FibreFoX

FibreFoX Jan 15, 2017

C:\projects\someVM\.vm>ssh vagrant@127.0.0.1 -p 2222 -i C:/Users/FibreFoX/.vagrant.d/insecure_private_key
ssh: connect to host 127.0.0.1 port 2222: Connection refused

C:\projects\someVM\.vm>vagrant status
Current machine states:

default                   running (virtualbox)

The VM is running. To stop this VM, you can run `vagrant halt` to
shut it down forcefully, or you can run `vagrant suspend` to simply
suspend the virtual machine. In either case, to restart it again,
simply run `vagrant up`.

C:\projects\someVM\.vm>vagrant ssh

C:\projects\someVM\.vm>

Seems like the core-problem is virtualbox not being able to forward the ports ... can ANYONE confirm this, maybe this is even on different platforms?

FibreFoX commented Jan 15, 2017

C:\projects\someVM\.vm>ssh vagrant@127.0.0.1 -p 2222 -i C:/Users/FibreFoX/.vagrant.d/insecure_private_key
ssh: connect to host 127.0.0.1 port 2222: Connection refused

C:\projects\someVM\.vm>vagrant status
Current machine states:

default                   running (virtualbox)

The VM is running. To stop this VM, you can run `vagrant halt` to
shut it down forcefully, or you can run `vagrant suspend` to simply
suspend the virtual machine. In either case, to restart it again,
simply run `vagrant up`.

C:\projects\someVM\.vm>vagrant ssh

C:\projects\someVM\.vm>

Seems like the core-problem is virtualbox not being able to forward the ports ... can ANYONE confirm this, maybe this is even on different platforms?

@FibreFoX

This comment has been minimized.

Show comment
Hide comment
@FibreFoX

FibreFoX Jan 15, 2017

@PeterDavidCarter Hi there, does port-forwarding work for you in general? I tried to activate "port forwarding" with a fresh VM without using Vagrant ... and it does not work. Maybe some VirtualBox bug?

EDIT: this is not box-related, every box does not work for me

EDIT 2: maybe related: https://forums.virtualbox.org/viewtopic.php?f=6&t=77575 will report back after checking

FibreFoX commented Jan 15, 2017

@PeterDavidCarter Hi there, does port-forwarding work for you in general? I tried to activate "port forwarding" with a fresh VM without using Vagrant ... and it does not work. Maybe some VirtualBox bug?

EDIT: this is not box-related, every box does not work for me

EDIT 2: maybe related: https://forums.virtualbox.org/viewtopic.php?f=6&t=77575 will report back after checking

@FibreFoX

This comment has been minimized.

Show comment
Hide comment
@FibreFoX

FibreFoX Jan 26, 2017

Hey guys/gals, after fighting this problem, I found MY personal solution:

! removing all installed security-software !

I don't know why this happened, but after removing my firewall-software, this started to work and it was NO Vagrant-issue.

Can anyone on this thread confirm this, or at least check if the started VM has open ports? (I used process explorer for this)

FibreFoX commented Jan 26, 2017

Hey guys/gals, after fighting this problem, I found MY personal solution:

! removing all installed security-software !

I don't know why this happened, but after removing my firewall-software, this started to work and it was NO Vagrant-issue.

Can anyone on this thread confirm this, or at least check if the started VM has open ports? (I used process explorer for this)

@stevenbuehner

This comment has been minimized.

Show comment
Hide comment
@stevenbuehner

stevenbuehner Feb 13, 2017

Installing the newest VirtualBox 5.0.32-112930-OSX.dmg solved the issue entirely for me on OSX 10.12.3 ...

stevenbuehner commented Feb 13, 2017

Installing the newest VirtualBox 5.0.32-112930-OSX.dmg solved the issue entirely for me on OSX 10.12.3 ...

@sanderso510

This comment has been minimized.

Show comment
Hide comment
@sanderso510

sanderso510 Feb 15, 2017

Noob here. (hope I'm not hijacking this thread)

Been battling similar issue for many days. During vagrant up, I see a timeout during the SSH connect and before the VM is up. The odd thing is inconsistency...the VM has only come up a few times in the past many days.

My setup is Archx32 (using old/slow hardware)
Box = ogarcia/archlinux-x32
Vagrant v1.9.1
Virtualbox = v5.1.14-1

I have a simple Vagrantfile:
no provisioning (neither file nor shell)
no .private_key_path setting
no port forwarding
.insert_key = false
.forward_agent = true
.username = "vagrant"
.password = "vagrant"
.boot_timeout = 600
.network = "private_network", ip: "192.168.33.10"

The setup above worked and the VM came up.
Then I removed the username and password lines and the setup didn't work.
Then I restored the username and password lines and the setup didn't work.
I increased the boot_timeout to 900 then 1200. Both didn't work.
(I use a vagrant destroy then vagrant up on every test cycle.)

My setup always seems to fail (timeout) during the attempt to establish SSH. After failure, vagrant status shows the VM running (like the FibreFoX screen shot on Jan 14) and vagrant ssh fails. However, I can ssh into the VM to see that my sync'd folder and /vagrant are NOT present in the VM. Also, I can ssh into the host from a tty or via PuTTY on a Win10 machine on the LAN.

My problem is similar to those seen in the prior comments. I look forward to additional comments on this thread in hopes of getting my setup working reliably.

Thnx.

sanderso510 commented Feb 15, 2017

Noob here. (hope I'm not hijacking this thread)

Been battling similar issue for many days. During vagrant up, I see a timeout during the SSH connect and before the VM is up. The odd thing is inconsistency...the VM has only come up a few times in the past many days.

My setup is Archx32 (using old/slow hardware)
Box = ogarcia/archlinux-x32
Vagrant v1.9.1
Virtualbox = v5.1.14-1

I have a simple Vagrantfile:
no provisioning (neither file nor shell)
no .private_key_path setting
no port forwarding
.insert_key = false
.forward_agent = true
.username = "vagrant"
.password = "vagrant"
.boot_timeout = 600
.network = "private_network", ip: "192.168.33.10"

The setup above worked and the VM came up.
Then I removed the username and password lines and the setup didn't work.
Then I restored the username and password lines and the setup didn't work.
I increased the boot_timeout to 900 then 1200. Both didn't work.
(I use a vagrant destroy then vagrant up on every test cycle.)

My setup always seems to fail (timeout) during the attempt to establish SSH. After failure, vagrant status shows the VM running (like the FibreFoX screen shot on Jan 14) and vagrant ssh fails. However, I can ssh into the VM to see that my sync'd folder and /vagrant are NOT present in the VM. Also, I can ssh into the host from a tty or via PuTTY on a Win10 machine on the LAN.

My problem is similar to those seen in the prior comments. I look forward to additional comments on this thread in hopes of getting my setup working reliably.

Thnx.

@FibreFoX

This comment has been minimized.

Show comment
Hide comment
@FibreFoX

FibreFoX Feb 15, 2017

@sanderso510 For me it was removing my firewall-software ... never got problems since. Can you check if the process opens any ports (netstat)?

FibreFoX commented Feb 15, 2017

@sanderso510 For me it was removing my firewall-software ... never got problems since. Can you check if the process opens any ports (netstat)?

@sanderso510

This comment has been minimized.

Show comment
Hide comment
@sanderso510

sanderso510 Feb 15, 2017

Thnx for reply FibreFoX.

The Arch host box is relatively clean and I'm certain it doesn't have any firewall software that I installed. The box sits behind a router which has been running w/o issues for years. That said, I'll double check the Arch box and pull out any firewall sw I see.

ran:
netstat | grep user/1001 yields no data (vagrant = UID 1001)
(this assumes the process will have been run by user vagrant)

I can't help but think the wonky behavior is due to the 32b architecture of the hardware. Accordingly, will be installing vagrant on a 64b win10 box later and hope for better results.

Thnx again.

sanderso510 commented Feb 15, 2017

Thnx for reply FibreFoX.

The Arch host box is relatively clean and I'm certain it doesn't have any firewall software that I installed. The box sits behind a router which has been running w/o issues for years. That said, I'll double check the Arch box and pull out any firewall sw I see.

ran:
netstat | grep user/1001 yields no data (vagrant = UID 1001)
(this assumes the process will have been run by user vagrant)

I can't help but think the wonky behavior is due to the 32b architecture of the hardware. Accordingly, will be installing vagrant on a 64b win10 box later and hope for better results.

Thnx again.

@chrisroberts

This comment has been minimized.

Show comment
Hide comment
@chrisroberts

chrisroberts Mar 2, 2017

Member

Hi there. Has the original issue been resolved or is the behavior still being seen using the latest Vagrant release? Thanks!

Member

chrisroberts commented Mar 2, 2017

Hi there. Has the original issue been resolved or is the behavior still being seen using the latest Vagrant release? Thanks!

@nonameolsson

This comment has been minimized.

Show comment
Hide comment
@nonameolsson

nonameolsson Mar 28, 2017

I upgraded to the latest version of Vagrant and Virtualbox, and that solved my problem!

nonameolsson commented Mar 28, 2017

I upgraded to the latest version of Vagrant and Virtualbox, and that solved my problem!

@chrisroberts

This comment has been minimized.

Show comment
Hide comment
@chrisroberts

chrisroberts Apr 12, 2017

Member

Hey there,

I am going to close this due to lack of response. If this is still occurring, please open a new issue and follow the provided issue template that appears when you click the "New Issue" button. This will help us in getting a reproduction and fix. Thanks! 😄

Member

chrisroberts commented Apr 12, 2017

Hey there,

I am going to close this due to lack of response. If this is still occurring, please open a new issue and follow the provided issue template that appears when you click the "New Issue" button. This will help us in getting a reproduction and fix. Thanks! 😄

@PortNumber53

This comment has been minimized.

Show comment
Hide comment
@PortNumber53

PortNumber53 Apr 28, 2017

This still happens for me.
Vagrant 1.9.3

VBoxManage --version
5.1.20r114629

OSX El Capitain 10.11.6

BASH 4.4.12(1)-release (x86_64-apple-darwin15.6.0)

Vagrant plug ins
vagrant-docker-compose
vagrant-hostsupdater

VM debian/contrib-jessie64

PortNumber53 commented Apr 28, 2017

This still happens for me.
Vagrant 1.9.3

VBoxManage --version
5.1.20r114629

OSX El Capitain 10.11.6

BASH 4.4.12(1)-release (x86_64-apple-darwin15.6.0)

Vagrant plug ins
vagrant-docker-compose
vagrant-hostsupdater

VM debian/contrib-jessie64

@scottbrumley

This comment has been minimized.

Show comment
Hide comment
@scottbrumley

scottbrumley May 1, 2017

Had the same issue. Was loading docker and with it iptables. Iptables must have been blocking once the box rebooted.

scottbrumley commented May 1, 2017

Had the same issue. Was loading docker and with it iptables. Iptables must have been blocking once the box rebooted.

@fadiabualnaser

This comment has been minimized.

Show comment
Hide comment
@fadiabualnaser

fadiabualnaser May 2, 2017

I have the same issue :(

fadiabualnaser commented May 2, 2017

I have the same issue :(

@FibreFoX

This comment has been minimized.

Show comment
Hide comment
@FibreFoX

FibreFoX May 2, 2017

Maybe vagrant can do port-checks (like using netstat) for verifying these ports are OPEN, not to rely on the implicit way. My problems disapeared after finding virtualbox not having opened/listening on the forwarded ports

FibreFoX commented May 2, 2017

Maybe vagrant can do port-checks (like using netstat) for verifying these ports are OPEN, not to rely on the implicit way. My problems disapeared after finding virtualbox not having opened/listening on the forwarded ports

@ryanpineo

This comment has been minimized.

Show comment
Hide comment
@ryanpineo

ryanpineo May 14, 2017

same issue, dont think this should have been closed

ryanpineo commented May 14, 2017

same issue, dont think this should have been closed

@DanAtShenTech

This comment has been minimized.

Show comment
Hide comment
@DanAtShenTech

DanAtShenTech May 14, 2017

Same issue here too, and I agree this should not have been closed. Running on Windows 7 as host with Unbuntu 14 guest. I've spent hours trying to fix this. I've tried re-installing VBox (after cleaning out all settings it left behind), reinstalled Vagrant - nothing works. The VM does start - I run with UI turned on in the Vagrantfile, and I can log into Ubuntu, but it always hangs at SSH auth method: private key.

DanAtShenTech commented May 14, 2017

Same issue here too, and I agree this should not have been closed. Running on Windows 7 as host with Unbuntu 14 guest. I've spent hours trying to fix this. I've tried re-installing VBox (after cleaning out all settings it left behind), reinstalled Vagrant - nothing works. The VM does start - I run with UI turned on in the Vagrantfile, and I can log into Ubuntu, but it always hangs at SSH auth method: private key.

@DanAtShenTech

This comment has been minimized.

Show comment
Hide comment
@DanAtShenTech

DanAtShenTech May 14, 2017

A simple breakthrough here: the default Vagrantfile didn't include a mapping of a port from the host machine to 22 on the guest and it occurred to me that maybe the default mapping of port 2222 (host) to 22 (guest) wasn't being honored. I put the following line in to make the mapping explicit, and the key-based SSH authentication has now started working:
config.vm.network "forwarded_port", guest: 22, host: 2222, host_ip: "127.0.0.1", id: 'ssh'

DanAtShenTech commented May 14, 2017

A simple breakthrough here: the default Vagrantfile didn't include a mapping of a port from the host machine to 22 on the guest and it occurred to me that maybe the default mapping of port 2222 (host) to 22 (guest) wasn't being honored. I put the following line in to make the mapping explicit, and the key-based SSH authentication has now started working:
config.vm.network "forwarded_port", guest: 22, host: 2222, host_ip: "127.0.0.1", id: 'ssh'

@emfluenceindia

This comment has been minimized.

Show comment
Hide comment
@emfluenceindia

emfluenceindia May 26, 2017

Till yesterday it worked perfectly OK for me. Today I have got stuck at default: SSH auth method: private key and nothing happens beyond this point :(

Vagrant version: 1.9.4
VirtualBox version: 5.1.22

One more strange thing I noticed when I run virtualbox --version command. Instead of showing the version in CL interface it is opening the GUI. I am on Ubuntu 14.04 LTS

vagrant global-status shows:

id name provider state directory
eb9b569 default virtualbox running /var/www/html/yrcf

vagrant reload didn't work. I also tried vagrant halt followed by vagrant up. This didn't work for me either.

emfluenceindia commented May 26, 2017

Till yesterday it worked perfectly OK for me. Today I have got stuck at default: SSH auth method: private key and nothing happens beyond this point :(

Vagrant version: 1.9.4
VirtualBox version: 5.1.22

One more strange thing I noticed when I run virtualbox --version command. Instead of showing the version in CL interface it is opening the GUI. I am on Ubuntu 14.04 LTS

vagrant global-status shows:

id name provider state directory
eb9b569 default virtualbox running /var/www/html/yrcf

vagrant reload didn't work. I also tried vagrant halt followed by vagrant up. This didn't work for me either.

@DanAtShenTech

This comment has been minimized.

Show comment
Hide comment
@DanAtShenTech

DanAtShenTech May 28, 2017

DanAtShenTech commented May 28, 2017

@jhgaylor

This comment has been minimized.

Show comment
Hide comment
@jhgaylor

jhgaylor May 28, 2017

I added this block to my vagrantfile and no longer had this problem.

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

I found this idea here #8056 (comment)

jhgaylor commented May 28, 2017

I added this block to my vagrantfile and no longer had this problem.

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

I found this idea here #8056 (comment)

@b33rcity

This comment has been minimized.

Show comment
Hide comment
@b33rcity

b33rcity Jun 18, 2017

None of the tips in this thread worked for me. I found elsewhere (and lost the link, sorry--different computer) a suggestion to make sure the processor is virtualization-ready.

"Well, der, I have a Core i5 which comes with vt-x!"

Yeah, so did I. I double checked BIOS just in case, and sure enough that feature was present but disabled. Enabled it and the ssh hang went away instantly.

One way you can check is try to open the box from the provider (VirtualBox in my case). If it's, say, CentOS you're trying to run, it will straight up tell you that it's not finding a 64 bit processor that it can use.

b33rcity commented Jun 18, 2017

None of the tips in this thread worked for me. I found elsewhere (and lost the link, sorry--different computer) a suggestion to make sure the processor is virtualization-ready.

"Well, der, I have a Core i5 which comes with vt-x!"

Yeah, so did I. I double checked BIOS just in case, and sure enough that feature was present but disabled. Enabled it and the ssh hang went away instantly.

One way you can check is try to open the box from the provider (VirtualBox in my case). If it's, say, CentOS you're trying to run, it will straight up tell you that it's not finding a 64 bit processor that it can use.

@DanAtShenTech

This comment has been minimized.

Show comment
Hide comment
@DanAtShenTech

DanAtShenTech Dec 4, 2017

@goosehub Sorry I don't have more to offer at this point. I'm running Ubuntu 14 and have a very minimal config file. I've turned off checking for updates to my base box and I also run with nfs turned on for the synced folder, but I wouldn't think that either of these would have anything to do with the communication error you're experiencing. At one point in the past I turned logging on at its lowest level to see what was going on at startup, and that helped me figure out that my keys were messed up, but of course you know that you have some sort of communication problem, so I don't know that that would help you either. I'll be very interested to know if you're able to get this worked out.

DanAtShenTech commented Dec 4, 2017

@goosehub Sorry I don't have more to offer at this point. I'm running Ubuntu 14 and have a very minimal config file. I've turned off checking for updates to my base box and I also run with nfs turned on for the synced folder, but I wouldn't think that either of these would have anything to do with the communication error you're experiencing. At one point in the past I turned logging on at its lowest level to see what was going on at startup, and that helped me figure out that my keys were messed up, but of course you know that you have some sort of communication problem, so I don't know that that would help you either. I'll be very interested to know if you're able to get this worked out.

@goosehub

This comment has been minimized.

Show comment
Hide comment
@goosehub

goosehub Dec 4, 2017

@DanAtShenTech ah, I didn't think of using --debug

When I run `vagrant up --debug &> vagrant.log, I find it more or less repeats this block of debug text after it starts the SSH keys step. Been looking at it for a while, but no idea what most of this means or why it's repeating.

DEBUG ssh: Checking key permissions: /home/clong/.vagrant.d/insecure_private_key
 INFO interface: detail: SSH address: 127.0.0.1:2222
 INFO interface: detail:     homestead-7: SSH address: 127.0.0.1:2222
    homestead-7: SSH address: 127.0.0.1:2222
 INFO interface: detail: SSH username: vagrant
 INFO interface: detail:     homestead-7: SSH username: vagrant
    homestead-7: SSH username: vagrant
 INFO interface: detail: SSH auth method: private key
 INFO interface: detail:     homestead-7: SSH auth method: private key
    homestead-7: SSH auth method: private key
-- starts repeating here
 INFO subprocess: Starting process: ["/usr/bin/VBoxManage", "showvminfo", "fe321db5-563c-4dc3-b56c-40de4a3c828b", "--machinereadable"]
 INFO subprocess: Command not in installer, restoring original environment...
DEBUG subprocess: Selecting on IO
DEBUG subprocess: stdout: name="homestead-7"
groups="/"
ostype="Ubuntu (64-bit)"
UUID="fe321db5-563c-4dc3-b56c-40de4a3c828b"
CfgFile="/home/clong/VirtualBox VMs/homestead-7/homestead-7.vbox"
SnapFldr="/home/clong/VirtualBox VMs/homestead-7/Snapshots"
LogFldr="/home/clong/VirtualBox VMs/homestead-7/Logs"
hardwareuuid="fe321db5-563c-4dc3-b56c-40de4a3c828b"
memory=2048
pagefusion="off"
vram=8
cpuexecutioncap=100
hpet="off"
chipset="piix3"
firmware="BIOS"
cpus=1
pae="on"
longmode="on"
synthcpu="off"
bootmenu="messageandmenu"
boot1="disk"
boot2="dvd"
boot3="none"
boot4="none"
acpi="on"
ioapic="on"
biossystemtimeoffset=0
rtcuseutc="on"
hwvirtex="on"
nestedpaging="on"
largepages="on"
vtxvpid="on"
vtxux="on"
VMState="running"
VMStateChangeTime="2017-12-04T16:40:08.862000000"
monitorcount=1
accelerate3d="off"
accelerate2dvideo="off"
teleporterenabled="off"
teleporterport=0
teleporteraddress=""
teleporterpassword=""
tracing-enabled="off"
tracing-allow-vm-access="off"
tracing-config=""
autostart-enabled="off"
autostart-delay=0
defaultfrontend=""
storagecontrollername0="IDE Controller"
storagecontrollertype0="PIIX4"
storagecontrollerinstance0="0"
storagecontrollermaxportcount0="2"
storagecontrollerportcount0="2"
storagecontrollerbootable0="on"
storagecontrollername1="SATA Controller"
storagecontrollertype1="IntelAhci"
storagecontrollerinstance1="0"
storagecontrollermaxportcount1="30"
storagecontrollerportcount1="1"
storagecontrollerbootable1="on"
"IDE Controller-0-0"="none"
"IDE Controller-0-1"="none"
"IDE Controller-1-0"="none"
"IDE Controller-1-1"="none"
"SATA Controller-0-0"="/home/clong/VirtualBox VMs/homestead-7/ubuntu-16.04-amd64-disk001.vmdk"
"SATA Controller-ImageUUID-0-0"="81c0d693-fcb4-40e5-90f0-af9df1d15121"
natnet1="nat"
macaddress1="0800273B4CC5"
cableconnected1="off"
nic1="nat"
nictype1="82540EM"
nicspeed1="0"
mtu="0"
sockSnd="64"
sockRcv="64"
tcpWndSnd="64"
tcpWndRcv="64"
Forwarding(0)="ssh,tcp,127.0.0.1,2222,,22"
Forwarding(1)="tcp27017,tcp,,27017,,27017"
Forwarding(2)="tcp33060,tcp,,33060,,3306"
Forwarding(3)="tcp4040,tcp,,4040,,4040"
Forwarding(4)="tcp44300,tcp,,44300,,443"
Forwarding(5)="tcp54320,tcp,,54320,,5432"
Forwarding(6)="tcp8000,tcp,,8000,,80"
Forwarding(7)="tcp8025,tcp,,8025,,8025"
hostonlyadapter2="vboxnet0"
macaddress2="080027F4D534"
cableconnected2="on"
nic2="hostonly"
nictype2="Am79C973"
nicspeed2="0"
nic3="none"
nic4="none"
nic5="none"
nic6="none"
nic7="none"
nic8="none"
hidpointing="ps2mouse"
hidkeyboard="ps2kbd"
uart1="off"
uart2="off"
lpt1="off"
lpt2="off"
audio="pulse"
clipboard="disabled"
draganddrop="disabled"
SessionType="headless"
VideoMode="640,480,32"@0,0
vrde="on"
vrdeport=5988
vrdeports="5988"
vrdeaddress="127.0.0.1"
vrdeauthtype="null"
vrdemulticon="off"
vrdereusecon="off"
vrdevideochannel="off"
vrdeproperty[TCP/Ports]="5988"
vrdeproperty[TCP/Address]="127.0.0.1"
usb="off"
ehci="off"
SharedFolderNameMachineMapping1="home_vagrant_code"
SharedFolderPathMachineMapping1="/var/www/foobar"
SharedFolderNameMachineMapping2="vagrant"
SharedFolderPathMachineMapping2="/home/clong/Homestead"
VRDEActiveConnection="off"
VRDEClients=0
vcpenabled="off"
vcpscreens=0
vcpfile="/home/clong/VirtualBox VMs/homestead-7/homestead-7.webm"
vcpwidth=1024
vcpheight=768
vcprate=512
vcpfps=25
GuestMemoryBalloon=0
GuestOSType="Ubuntu_64"
GuestAdditionsRunLevel=0
DEBUG subprocess: Waiting for process to exit. Remaining to timeout: 32000
DEBUG subprocess: Exit status: 0
DEBUG virtualbox_4_3: Searching for SSH port: 22
DEBUG virtualbox_4_3: read_forward_ports: uuid=fe321db5-563c-4dc3-b56c-40de4a3c828b active_only=false

Sometimes it includes this

DEBUG ssh: Checking key permissions: /home/clong/.vagrant.d/insecure_private_key
 INFO ssh: Attempting SSH connection...
 INFO ssh: Attempting to connect to SSH...
 INFO ssh:   - Host: 127.0.0.1
 INFO ssh:   - Port: 2222
 INFO ssh:   - Username: vagrant
 INFO ssh:   - Password? false
 INFO ssh:   - Key Path: ["/home/clong/.vagrant.d/insecure_private_key"]
DEBUG ssh:   - connect_opts: {:auth_methods=>["none", "hostbased", "publickey"], :config=>false, :forward_agent=>true, :send_env=>false, :keys_only=>true, :paranoid=>false, :password=>nil, :port=>2222, :timeout=>15, :user_known_hosts_file=>[], :verbose=>:debug, :logger=>#<Logger:0x00000002a3a190 @progname=nil, @level=0, @default_formatter=#<Logger::Formatter:0x00000002a3a140 @datetime_format=nil>, @formatter=nil, @logdev=#<Logger::LogDevice:0x00000002a3a0f0 @shift_size=nil, @shift_age=nil, @filename=nil, @dev=#<StringIO:0x00000002a3a1e0>, @mutex=#<Logger::LogDevice::LogDeviceMutex:0x00000002a3a0a0 @mon_owner=nil, @mon_count=0, @mon_mutex=#<Mutex:0x00000002a39fd8>>>>, :keys=>["/home/clong/.vagrant.d/insecure_private_key"]}

And sometimes it includes this

DEBUG ssh: == Net-SSH connection debug-level log START ==
DEBUG ssh: D, [2017-12-04T11:40:09.111102 #18051] DEBUG -- net.ssh.transport.session[17b923c]: establishing connection to 127.0.0.1:2222
D, [2017-12-04T11:40:09.111377 #18051] DEBUG -- net.ssh.transport.session[17b923c]: connection established
I, [2017-12-04T11:40:09.111447 #18051]  INFO -- net.ssh.transport.server_version[17b8634]: negotiating protocol version
DEBUG ssh: == Net-SSH connection debug-level log END ==
 INFO ssh: SSH not ready: #<Vagrant::Errors::NetSSHException: An error occurred in the underlying SSH library that Vagrant uses.
The error message is shown below. In many cases, errors from this
library are caused by ssh-agent issues. Try disabling your SSH
agent or removing some keys and try again.

If the problem persists, please report a bug to the net-ssh project.

timeout during server version negotiating>

So "An error occurred in the underlying SSH library that Vagrant uses." sounds very relevant probably? Any idea on how I would debug an issue in the underlying SSH library, or anything else these logs might be suggesting to be the issue?

goosehub commented Dec 4, 2017

@DanAtShenTech ah, I didn't think of using --debug

When I run `vagrant up --debug &> vagrant.log, I find it more or less repeats this block of debug text after it starts the SSH keys step. Been looking at it for a while, but no idea what most of this means or why it's repeating.

DEBUG ssh: Checking key permissions: /home/clong/.vagrant.d/insecure_private_key
 INFO interface: detail: SSH address: 127.0.0.1:2222
 INFO interface: detail:     homestead-7: SSH address: 127.0.0.1:2222
    homestead-7: SSH address: 127.0.0.1:2222
 INFO interface: detail: SSH username: vagrant
 INFO interface: detail:     homestead-7: SSH username: vagrant
    homestead-7: SSH username: vagrant
 INFO interface: detail: SSH auth method: private key
 INFO interface: detail:     homestead-7: SSH auth method: private key
    homestead-7: SSH auth method: private key
-- starts repeating here
 INFO subprocess: Starting process: ["/usr/bin/VBoxManage", "showvminfo", "fe321db5-563c-4dc3-b56c-40de4a3c828b", "--machinereadable"]
 INFO subprocess: Command not in installer, restoring original environment...
DEBUG subprocess: Selecting on IO
DEBUG subprocess: stdout: name="homestead-7"
groups="/"
ostype="Ubuntu (64-bit)"
UUID="fe321db5-563c-4dc3-b56c-40de4a3c828b"
CfgFile="/home/clong/VirtualBox VMs/homestead-7/homestead-7.vbox"
SnapFldr="/home/clong/VirtualBox VMs/homestead-7/Snapshots"
LogFldr="/home/clong/VirtualBox VMs/homestead-7/Logs"
hardwareuuid="fe321db5-563c-4dc3-b56c-40de4a3c828b"
memory=2048
pagefusion="off"
vram=8
cpuexecutioncap=100
hpet="off"
chipset="piix3"
firmware="BIOS"
cpus=1
pae="on"
longmode="on"
synthcpu="off"
bootmenu="messageandmenu"
boot1="disk"
boot2="dvd"
boot3="none"
boot4="none"
acpi="on"
ioapic="on"
biossystemtimeoffset=0
rtcuseutc="on"
hwvirtex="on"
nestedpaging="on"
largepages="on"
vtxvpid="on"
vtxux="on"
VMState="running"
VMStateChangeTime="2017-12-04T16:40:08.862000000"
monitorcount=1
accelerate3d="off"
accelerate2dvideo="off"
teleporterenabled="off"
teleporterport=0
teleporteraddress=""
teleporterpassword=""
tracing-enabled="off"
tracing-allow-vm-access="off"
tracing-config=""
autostart-enabled="off"
autostart-delay=0
defaultfrontend=""
storagecontrollername0="IDE Controller"
storagecontrollertype0="PIIX4"
storagecontrollerinstance0="0"
storagecontrollermaxportcount0="2"
storagecontrollerportcount0="2"
storagecontrollerbootable0="on"
storagecontrollername1="SATA Controller"
storagecontrollertype1="IntelAhci"
storagecontrollerinstance1="0"
storagecontrollermaxportcount1="30"
storagecontrollerportcount1="1"
storagecontrollerbootable1="on"
"IDE Controller-0-0"="none"
"IDE Controller-0-1"="none"
"IDE Controller-1-0"="none"
"IDE Controller-1-1"="none"
"SATA Controller-0-0"="/home/clong/VirtualBox VMs/homestead-7/ubuntu-16.04-amd64-disk001.vmdk"
"SATA Controller-ImageUUID-0-0"="81c0d693-fcb4-40e5-90f0-af9df1d15121"
natnet1="nat"
macaddress1="0800273B4CC5"
cableconnected1="off"
nic1="nat"
nictype1="82540EM"
nicspeed1="0"
mtu="0"
sockSnd="64"
sockRcv="64"
tcpWndSnd="64"
tcpWndRcv="64"
Forwarding(0)="ssh,tcp,127.0.0.1,2222,,22"
Forwarding(1)="tcp27017,tcp,,27017,,27017"
Forwarding(2)="tcp33060,tcp,,33060,,3306"
Forwarding(3)="tcp4040,tcp,,4040,,4040"
Forwarding(4)="tcp44300,tcp,,44300,,443"
Forwarding(5)="tcp54320,tcp,,54320,,5432"
Forwarding(6)="tcp8000,tcp,,8000,,80"
Forwarding(7)="tcp8025,tcp,,8025,,8025"
hostonlyadapter2="vboxnet0"
macaddress2="080027F4D534"
cableconnected2="on"
nic2="hostonly"
nictype2="Am79C973"
nicspeed2="0"
nic3="none"
nic4="none"
nic5="none"
nic6="none"
nic7="none"
nic8="none"
hidpointing="ps2mouse"
hidkeyboard="ps2kbd"
uart1="off"
uart2="off"
lpt1="off"
lpt2="off"
audio="pulse"
clipboard="disabled"
draganddrop="disabled"
SessionType="headless"
VideoMode="640,480,32"@0,0
vrde="on"
vrdeport=5988
vrdeports="5988"
vrdeaddress="127.0.0.1"
vrdeauthtype="null"
vrdemulticon="off"
vrdereusecon="off"
vrdevideochannel="off"
vrdeproperty[TCP/Ports]="5988"
vrdeproperty[TCP/Address]="127.0.0.1"
usb="off"
ehci="off"
SharedFolderNameMachineMapping1="home_vagrant_code"
SharedFolderPathMachineMapping1="/var/www/foobar"
SharedFolderNameMachineMapping2="vagrant"
SharedFolderPathMachineMapping2="/home/clong/Homestead"
VRDEActiveConnection="off"
VRDEClients=0
vcpenabled="off"
vcpscreens=0
vcpfile="/home/clong/VirtualBox VMs/homestead-7/homestead-7.webm"
vcpwidth=1024
vcpheight=768
vcprate=512
vcpfps=25
GuestMemoryBalloon=0
GuestOSType="Ubuntu_64"
GuestAdditionsRunLevel=0
DEBUG subprocess: Waiting for process to exit. Remaining to timeout: 32000
DEBUG subprocess: Exit status: 0
DEBUG virtualbox_4_3: Searching for SSH port: 22
DEBUG virtualbox_4_3: read_forward_ports: uuid=fe321db5-563c-4dc3-b56c-40de4a3c828b active_only=false

Sometimes it includes this

DEBUG ssh: Checking key permissions: /home/clong/.vagrant.d/insecure_private_key
 INFO ssh: Attempting SSH connection...
 INFO ssh: Attempting to connect to SSH...
 INFO ssh:   - Host: 127.0.0.1
 INFO ssh:   - Port: 2222
 INFO ssh:   - Username: vagrant
 INFO ssh:   - Password? false
 INFO ssh:   - Key Path: ["/home/clong/.vagrant.d/insecure_private_key"]
DEBUG ssh:   - connect_opts: {:auth_methods=>["none", "hostbased", "publickey"], :config=>false, :forward_agent=>true, :send_env=>false, :keys_only=>true, :paranoid=>false, :password=>nil, :port=>2222, :timeout=>15, :user_known_hosts_file=>[], :verbose=>:debug, :logger=>#<Logger:0x00000002a3a190 @progname=nil, @level=0, @default_formatter=#<Logger::Formatter:0x00000002a3a140 @datetime_format=nil>, @formatter=nil, @logdev=#<Logger::LogDevice:0x00000002a3a0f0 @shift_size=nil, @shift_age=nil, @filename=nil, @dev=#<StringIO:0x00000002a3a1e0>, @mutex=#<Logger::LogDevice::LogDeviceMutex:0x00000002a3a0a0 @mon_owner=nil, @mon_count=0, @mon_mutex=#<Mutex:0x00000002a39fd8>>>>, :keys=>["/home/clong/.vagrant.d/insecure_private_key"]}

And sometimes it includes this

DEBUG ssh: == Net-SSH connection debug-level log START ==
DEBUG ssh: D, [2017-12-04T11:40:09.111102 #18051] DEBUG -- net.ssh.transport.session[17b923c]: establishing connection to 127.0.0.1:2222
D, [2017-12-04T11:40:09.111377 #18051] DEBUG -- net.ssh.transport.session[17b923c]: connection established
I, [2017-12-04T11:40:09.111447 #18051]  INFO -- net.ssh.transport.server_version[17b8634]: negotiating protocol version
DEBUG ssh: == Net-SSH connection debug-level log END ==
 INFO ssh: SSH not ready: #<Vagrant::Errors::NetSSHException: An error occurred in the underlying SSH library that Vagrant uses.
The error message is shown below. In many cases, errors from this
library are caused by ssh-agent issues. Try disabling your SSH
agent or removing some keys and try again.

If the problem persists, please report a bug to the net-ssh project.

timeout during server version negotiating>

So "An error occurred in the underlying SSH library that Vagrant uses." sounds very relevant probably? Any idea on how I would debug an issue in the underlying SSH library, or anything else these logs might be suggesting to be the issue?

@mirmdasif

This comment has been minimized.

Show comment
Hide comment
@mirmdasif

mirmdasif Dec 5, 2017

mirmdasif commented Dec 5, 2017

@goosehub

This comment has been minimized.

Show comment
Hide comment
@goosehub

goosehub Dec 5, 2017

I was able to resolve the issue. I had at the start of my problems a 4.x.x virtualbox. I updated the virtualbox, but the problems continued. Even though it appeared in the terminal that I was using the most recent virtualbox, I ran box list, then removed all boxes, then added a new box. Then vagrant up worked!! Feedback to the vagrant devs for what it's worth, with how often and difficult this issue is, if there's a way to catch it and provide a useful error message, it'd be very helpful. Thanks for all your help.

goosehub commented Dec 5, 2017

I was able to resolve the issue. I had at the start of my problems a 4.x.x virtualbox. I updated the virtualbox, but the problems continued. Even though it appeared in the terminal that I was using the most recent virtualbox, I ran box list, then removed all boxes, then added a new box. Then vagrant up worked!! Feedback to the vagrant devs for what it's worth, with how often and difficult this issue is, if there's a way to catch it and provide a useful error message, it'd be very helpful. Thanks for all your help.

@Elite40

This comment has been minimized.

Show comment
Hide comment
@Elite40

Elite40 Dec 11, 2017

Thank you @mirmdasif, that worked for me!

Elite40 commented Dec 11, 2017

Thank you @mirmdasif, that worked for me!

@Ezerous

This comment has been minimized.

Show comment
Hide comment
@Ezerous

Ezerous Dec 14, 2017

I am still experiencing the issue.

  • I start on a fresh Ubuntu 16.04 VPS, I update and upgrade everything
  • I install the latest VirtualBox (v5.2) following the official instructions
  • I install the latest Vagrant (v2.0.1)
  • Running e.g. vagrant init bento/ubuntu-16.04 (doesn't matter which box) and Vagrant freezes on 'SSH auth method: private key'

The debug output is the same as the one @goosehub posted above.
I tried every suggestion:

  • Checked if virtualization is enabled (using kvm-ok)
  • vb.customize ["modifyvm", :id, "--cableconnected1", "on"] or manually checking the box
    etc.

Ezerous commented Dec 14, 2017

I am still experiencing the issue.

  • I start on a fresh Ubuntu 16.04 VPS, I update and upgrade everything
  • I install the latest VirtualBox (v5.2) following the official instructions
  • I install the latest Vagrant (v2.0.1)
  • Running e.g. vagrant init bento/ubuntu-16.04 (doesn't matter which box) and Vagrant freezes on 'SSH auth method: private key'

The debug output is the same as the one @goosehub posted above.
I tried every suggestion:

  • Checked if virtualization is enabled (using kvm-ok)
  • vb.customize ["modifyvm", :id, "--cableconnected1", "on"] or manually checking the box
    etc.
@DanAtShenTech

This comment has been minimized.

Show comment
Hide comment
@DanAtShenTech

DanAtShenTech Dec 14, 2017

@Ezerous Not likely this will help, but do you have the vagrant-vbguest Plugin installed?

DanAtShenTech commented Dec 14, 2017

@Ezerous Not likely this will help, but do you have the vagrant-vbguest Plugin installed?

@Ezerous

This comment has been minimized.

Show comment
Hide comment
@Ezerous

Ezerous Dec 14, 2017

@DanAtShenTech I hadn't. I did install it, nothing changed though.

Ezerous commented Dec 14, 2017

@DanAtShenTech I hadn't. I did install it, nothing changed though.

@ERPedersen

This comment has been minimized.

Show comment
Hide comment
@ERPedersen

ERPedersen Dec 28, 2017

I experienced this problem after updating my BIOS. For some reason, enabling VT-x alone didn't solve the issue. I'm running Windows 10 Version 1703 (Build 15063.786) on an Intel i5-6200U processor. Trying to start a laravel/homestead box on Vagrant 2.0.1. The following steps fixed it for me:

  • Enable VT-x in BIOS (Intel Virtualization Technology)
  • vagrant box add laravel/homestead --force
  • vagrant destroy
  • vagrant up --provision

ERPedersen commented Dec 28, 2017

I experienced this problem after updating my BIOS. For some reason, enabling VT-x alone didn't solve the issue. I'm running Windows 10 Version 1703 (Build 15063.786) on an Intel i5-6200U processor. Trying to start a laravel/homestead box on Vagrant 2.0.1. The following steps fixed it for me:

  • Enable VT-x in BIOS (Intel Virtualization Technology)
  • vagrant box add laravel/homestead --force
  • vagrant destroy
  • vagrant up --provision
@alexeightsix

This comment has been minimized.

Show comment
Hide comment
@alexeightsix

alexeightsix Jan 4, 2018

I did the following which worked, not sure if it will work for others though:

  1. vagrant global-status
  2. "suspend" any running instances (I had a few running)
  3. You can do vagrant suspend
  4. vagrant reload <id of instance that won't boot)

alexeightsix commented Jan 4, 2018

I did the following which worked, not sure if it will work for others though:

  1. vagrant global-status
  2. "suspend" any running instances (I had a few running)
  3. You can do vagrant suspend
  4. vagrant reload <id of instance that won't boot)
@csimpi

This comment has been minimized.

Show comment
Hide comment
@csimpi

csimpi Feb 5, 2018

Sometimes I have to work on a project for weeks in a row, I don't have time to reboot my notebook every day, to refresh VAGRANT machine, so I'm still getting similar crashing issues with VAGRANT all the time (because of the memory handling leaks/overflows).

After a bunch of occasions, I tried to collect my experiences about how to save your data after a big VAGRANT crash.

I'm updating the document with my new experiences about this.

https://github.com/csimpi/notes/blob/master/vagrant.md

csimpi commented Feb 5, 2018

Sometimes I have to work on a project for weeks in a row, I don't have time to reboot my notebook every day, to refresh VAGRANT machine, so I'm still getting similar crashing issues with VAGRANT all the time (because of the memory handling leaks/overflows).

After a bunch of occasions, I tried to collect my experiences about how to save your data after a big VAGRANT crash.

I'm updating the document with my new experiences about this.

https://github.com/csimpi/notes/blob/master/vagrant.md

@totymedli

This comment has been minimized.

Show comment
Hide comment
@totymedli

totymedli Feb 14, 2018

I opened up VirtualBox to shut down the VM, then ran vagrant up and during it I pulled out and plugged in the physical Ethernet cable. This solved it for me.

Seems like connection fault can cause this problem too. Might worth checking, especially if you also have Wi-Fi enabled, in which case you might not notice the network problem from the lack of Internet.

totymedli commented Feb 14, 2018

I opened up VirtualBox to shut down the VM, then ran vagrant up and during it I pulled out and plugged in the physical Ethernet cable. This solved it for me.

Seems like connection fault can cause this problem too. Might worth checking, especially if you also have Wi-Fi enabled, in which case you might not notice the network problem from the lack of Internet.

@montao

This comment has been minimized.

Show comment
Hide comment
@montao

montao Apr 23, 2018

I too have this error for weeks, effectively making my vagrant installation unusable.

montao commented Apr 23, 2018

I too have this error for weeks, effectively making my vagrant installation unusable.

@ApoorvSaxena

This comment has been minimized.

Show comment
Hide comment
@ApoorvSaxena

ApoorvSaxena May 18, 2018

Following the above comments, I tried executing following commands repeatedly:

  • vagrant reload
  • vagrant halt
  • vagrant up

though wasn't able to succeed, finally I executed vagrant destroy followed by vagrant up (considering that vagrant caches the previously downloaded modules, it didn't download anything), this time it executed flawlessly and printed the following:

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

ApoorvSaxena commented May 18, 2018

Following the above comments, I tried executing following commands repeatedly:

  • vagrant reload
  • vagrant halt
  • vagrant up

though wasn't able to succeed, finally I executed vagrant destroy followed by vagrant up (considering that vagrant caches the previously downloaded modules, it didn't download anything), this time it executed flawlessly and printed the following:

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

This comment has been minimized.

Show comment
Hide comment
@FFattor

FFattor May 19, 2018

I found a solution for me. Enter to the BIOS an check that virtualization is enabled.
http://www.fixedbyvonnie.com/2014/11/virtualbox-showing-32-bit-guest-versions-64-bit-host-os/#.WwCtskiFOUl

FFattor commented May 19, 2018

I found a solution for me. Enter to the BIOS an check that virtualization is enabled.
http://www.fixedbyvonnie.com/2014/11/virtualbox-showing-32-bit-guest-versions-64-bit-host-os/#.WwCtskiFOUl

@topubuf

This comment has been minimized.

Show comment
Hide comment
@topubuf

topubuf Jun 7, 2018

solution from @mirmdasif worked for me. Thank you

topubuf commented Jun 7, 2018

solution from @mirmdasif worked for me. Thank you

@externl

This comment has been minimized.

Show comment
Hide comment
@externl

externl Jun 7, 2018

I've experienced this in the past when the guest firewall is doing ssh rate limiting.

externl commented Jun 7, 2018

I've experienced this in the past when the guest firewall is doing ssh rate limiting.

@amadeann

This comment has been minimized.

Show comment
Hide comment
@amadeann

amadeann Jun 8, 2018

The only reliable way to go around this I found is to reboot my machine (both on Windows 10, and Ubuntu 16.04).

amadeann commented Jun 8, 2018

The only reliable way to go around this I found is to reboot my machine (both on Windows 10, and Ubuntu 16.04).

@twknab

This comment has been minimized.

Show comment
Hide comment
@twknab

twknab Jun 26, 2018

@ApoorvSaxena vagrant destroy followed by vagrant up worked for me -- thx so much for this

twknab commented Jun 26, 2018

@ApoorvSaxena vagrant destroy followed by vagrant up worked for me -- thx so much for this

@dgoscn

This comment has been minimized.

Show comment
Hide comment
@dgoscn

dgoscn Jul 3, 2018

Yeah. Enable Virtualization on your BIOS.
Worked for me.
Regards!

dgoscn commented Jul 3, 2018

Yeah. Enable Virtualization on your BIOS.
Worked for me.
Regards!

@unavailabl3

This comment has been minimized.

Show comment
Hide comment
@unavailabl3

unavailabl3 Sep 26, 2018

fghjk
Thank me later :D

WORKED!!!! DO it when it freezes on "auth method: private key"

unavailabl3 commented Sep 26, 2018

fghjk
Thank me later :D

WORKED!!!! DO it when it freezes on "auth method: private key"

@MatheusRV

This comment has been minimized.

Show comment
Hide comment
@MatheusRV

MatheusRV Sep 28, 2018

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

MatheusRV commented Sep 28, 2018

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

@paolooo

This comment has been minimized.

Show comment
Hide comment
@paolooo

paolooo Oct 15, 2018

This worked for me:
https://stackoverflow.com/a/52223651/959060

I'm running the following software:

$ VBoxManage --version
5.0.26r108824

$ vagrant --version
Vagrant 2.1.4

$ vagrant plugin list
vagrant-bindfs (1.1.0, global)

  • Version Constraint: > 0
    vagrant-hostmanager (1.8.9, global)
    vagrant-hostsupdater (1.1.1.160, global)
    vagrant-proxyconf (1.5.2, global)
  • Version Constraint: > 0
    vagrant-share (1.1.9, global)
  • Version Constraint: > 0
    vagrant-vbguest (0.15.2, global)
  • Version Constraint: > 0

paolooo commented Oct 15, 2018

This worked for me:
https://stackoverflow.com/a/52223651/959060

I'm running the following software:

$ VBoxManage --version
5.0.26r108824

$ vagrant --version
Vagrant 2.1.4

$ vagrant plugin list
vagrant-bindfs (1.1.0, global)

  • Version Constraint: > 0
    vagrant-hostmanager (1.8.9, global)
    vagrant-hostsupdater (1.1.1.160, global)
    vagrant-proxyconf (1.5.2, global)
  • Version Constraint: > 0
    vagrant-share (1.1.9, global)
  • Version Constraint: > 0
    vagrant-vbguest (0.15.2, global)
  • Version Constraint: > 0
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment