Vvv: SSH Timeout - Cant connect via ssh no matter what

[dezinerdudes]

Dear developers,

Thank you so much for this awesome project that you have created so far. From what Ive read it looks sooo awesome. Thats why I am trying really hard to get it working on my machine, but i simply cannot. I have painstakingly followed your tuturial over and over again step by step for days and tried like a million solutions on google but cannot find out why I experience a certain issue. Please could I ask for someone to give me some more wisdom:

I setup vagrant and VB just as specified. I am able to progress fine in setting up the VM specified in the vvv vagrant file through Git Bash. However, no matter what I try i am not able to ssh into the server. After the terminal comes to 'SSH auth method: private key' it just continues to give me a 'warning: connection timed out. Retrying...' (Please see image below)

I am running windows 8 64bit. I have Git with openssh and keys generated to default .ssh directory. I have tried different terminals and consoles but still not working. My ssh is working though when I connect to other servers. I restarted, deleted, everything the VM and still the same problem. I checked the ports from within the VB GUI settings and even tested with changes port settings but still nothing. Command netstat -a reveals that the vm is open on the corrent ssh ports and listening. Vagrant up command works, but no other command like halt or suspend etc. Reload and status works. Putty with generated vagrant keys according to your wiki article also times out in connection. I have just about read through and tried everything listed in google but cannot get it to work.

Please please help! I really want to use your setup file!

[andrezrv]

Hi @dezinerdudes! Have you tried disabling the Windows firewall? I run into this issue from time to time in Windows machines, and the firewall has always been the problem for me, by blocking inbound and outbound connections.

[lkwdwrd]

I ran into this same thing weekend before last. I'm on OS X 10.8.5, and couldn't for the life of me figure out the problem. Uninstalled and reinstalled a few versions of Virtualbox and Vagrant, and also worked from a fresh checkout of VVV. I tried with trusty64, trusty32, precise64, and precise32, but no matter what I tried it refused to connect.

Google was little help, though the fact that you are on windows is a bit promising. There were a few people reporting success checking their BIOS https://github.com/coreos/coreos-vagrant/issues/63. Other Windows users have suggested disabling Hyper-V as it may interfere with Virtualbox interfaces, though you may also want to run VVV in Hyper-V.

I gave up after about three hours of troubleshooting with no progress. I backed up my home folder, erased and re-installed my OS. Setup for me only takes a couple hours and my machine had a bunch of half installed local packages that I assume were conflicting in some way. Whatever the case, afterwards all pieces of the system ran smoothly. I had previously run into this issue with nokogiri installing any plugin, but that disappeared as well.

Wish I could have found the root cause, but the issue is a nasty one and I didn't want to waste more time on it. I determined it wasn't actually a VVV issue, but that's as far as I got. Something else was going on. Best of luck!

[dezinerdudes]

Thank you both for your suggestions! I am so grateful for the help. So, I tried disabling my firewall and antivirus and same problem. I made sure Hyper-V was turned off, changed all the settings in my Bios to default but still no change. Eventually I tried the versions you suggested: trusty 32 and precise 32. Precise32 worked immediately. It also displays the GUI in VB whereas the others don't. Thanks very much! Maybe I'll be able to help you guys at 10up some day!

[dezinerdudes]

Oh and @lkwdwrd do you think there's is any difference in features or performance running trusty32 vs trusty64 with vvv? Would some features not work if I used trusty32 or precise32?

[simonwheatley]

The arguments put for updating to Trusty64 are in this issue: #334

[jeremyfelt]

I haven't seen a full timeout, but I did have one instance with a CentOS box where I swear that Retrying message displayed 20 times before connecting. This messaging seems (?) newer in Vagrant, so I'm wondering if there's been a change it how it makes the connection to VirtualBox.

@dezinerdudes - what versions of VirtualBox and Vagrant are you using?

[dezinerdudes]

Thank you for the replies, I first tried with the versions of both vvv and VB that were suggested on the vvv page and the current versions of them. So current I am still using the latest of both: VB 4.3.12 and VVV 1.6.3. So now I have managed to get trusty32 working so i guess thats ok.

By the way, yesterday I Iooked again in my vbox log file, and there was some warning that my CPU doesnt support hardware virtualisation. Could that have something to do with the problem?

[shivapoudel]

@dezinerdudes has already reported this issue so I don't have to open another issue. I am running VVV task on my Windows 8.1 and having similar trouble like @dezinerdudes . @jeremyfelt please try your best to solve this issue as soon as possible.
Since I am the latest version guy and perform updates on day zero as soon as possible. Thus I am using the latest version of both :
Virtual-Box: 4.3.12
Vagrant: 1.6.3

[jeremyfelt]

Is there ever a final error message that appears or does it continue to try connecting?

[shivapoudel]

@jeremyfelt It tries to reconnect for about approx 10 times ( I haven't count it) and displays red text. Since I have reverted back to use stable release there is no problem now. Are you sure ubuntu/trusty64 is best than trusty32 . @jeremyfelt Windows 8 fix is important because stable version is working properly and if released windows users will be suffering badly.

[jeremyfelt]

@shivapoudel It sounds like @lkwdwrd had similar issues with trusty32 and trusty64, so I'm not sure going that way would resolve things. Does trusty32 work for you? I know there's another thread where CPU virtualization could be an issue.

[shivapoudel]

@jeremyfelt I have to use Windows Phone 8 Emulator too, so I have to enable Hyper-V technology which disables the VT-x (Visualization Technology) in my Windows 8.1 OS although I have core series intel processor. Believe me I have run this project without any sort of trouble in my Ubuntu 14.04 and Mountain Lion OS X 10.8 but with Windows 8.1 I was in trouble. When I see About Intel® Virtualization Technology it display's that intel processor with my series support VT-x completely. I also tried checking whether my CPU support VT-x using Intel® Processor Identification Utility and fk it display's mine Intel series processor doesn't support VT-x (Visualization Technology). So I was lucky to read @lkwdwrd issue and tried to disable Hyper-V. After restarting my Windows 8.1, I run **Intel® Processor Identification Utility and hurray !!! VT-x was enable. After this I was able to run ubuntu/trusty64 without any connection issues.

_Last but not least, I came to know that if VT-x Technology isn't supported by your intel Processor than Virtual-box will not support x64(64-bit) boxes and you came to became the victim of this type of connection issues while running x64(64-bit) boxes and for x86(32-Bit) boxes it runs well without connection issues._

[leemarrett]

I'm also experiencing this issue. I have an intel processor which _does_ support virtualisation technology (late 2012 mac mini) and i can't get vvv working with trusty64 due to the timeout issues referenced above. I thought I'd try trusty32 but it looks like it's not going to fix my problem.

Please tell me I don't have to do a @ikwdwrd and start a fresh install?

[lkwdwrd]

Lee, I'd suggest giving trusty32 a try, certainly couldn't hurt. I found
with my machine that the issue had nothing to do with VVV itself since even
when running a vagrant init with a precise32 box and attempting to do a
vagrant up it refused to boot. At that point, the switch to trusty64 had
nothing to do with my issue and the problem was somewhere in between my
machine, Virtualbox, and Vagrant. I'm sure there is a fix without the burn
it to the ground approach that I took, but unfortunately, if trsuty32 or
precise32 don't boot either, it'll be on the Vagrant project that you
should post the issue. I wanted to refresh my machine anyway which is why I
took that approach. Sorry for your trouble, this problem is pretty sticky
and really sucks trying to work out.

[fxbenard]

Maybe nothing to do with the problem but I had the same problem and I solved it by changing the version of ubuntu in VM Virtualbox. It wasn't setup for ubuntu 64 but ubuntu 32. I switched it and it worked

[tubiz]

@fxbenard how did you change the version of ubuntu from 32 to 64. I cant see the 64bit option here.

[fxbenard]

@tubiz Cause my old PC can't virtualize 64 bits, I changed the ubuntu version DOWN to 32 by changing line 31 in Vagrantfile
config.vm.box = "ubuntu/trusty32"

[tubiz]

@fxbenard thanks but am getting this error now

    default: SSH address: 127.0.0.1:2222
    default: SSH username: vagrant
    default: SSH auth method: private key
    default: Warning: Connection timeout. Retrying...
    default: Warning: Remote connection disconnect. Retrying...
    default: Warning: Remote connection disconnect. Retrying...
    default: Warning: Remote connection disconnect. Retrying...
    default: Warning: Authentication failure. Retrying...
    default: Warning: Authentication failure. Retrying...
    default: Warning: Authentication failure. Retrying...
    default: Warning: Authentication failure. Retrying...
    default: Warning: Authentication failure. Retrying...
    default: Warning: Authentication failure. Retrying...
    default: Warning: Authentication failure. Retrying...
    default: Warning: Authentication failure. Retrying...
    default: Warning: Authentication failure. Retrying...
    default: Warning: Authentication failure. Retrying...

[dezinerdudes]

I see there are still some users who are experiencing this issue. So, I will attempt to summarise a list below of some possible solutions to the SSH timeout problem:

• Make sure your firewall or antivirus is not blocking the program (which I doubt will happen often)
• Give your vagrant machine some time for timeouts to happen. If you dont have a very fast PC / Mac, the VM will take while to boot into an SSH ready state, so timeouts will happen.
• Therefore, first try to let vagrant timeout COMPLETELY before concluding that there is a fault.
• If vagrant times out completely then increase the timeout limit in the vagrant file to a few min and try again.
• If that still doesnt work, then try to clean boot your vagrant machine through the VirtualBox interface and enable the GUI of the machine beforehand. If the GUI doesn't show anything happening (ie. just blackscreen, no text) while it is booting, then your vagrant machine has got problems.
• Destroy the entire machine through the VB interface and reinstall.
• Delete the ubuntu image files in the Vagrant Images folder in the user folder and redownload and install.
• Do you even have an intel processor that supports 64bit hardware virtualisation? Google it. If you do, make sure there is no setting in your Bios disabling this feature.
• Disable hyper-v feature if you are running windows 7 or 8. Google how to disable.
• Make sure you are running through an SSH enabled client. Use Git bash. Download: http://git-scm.com/downloads
• Install a 32bit version of ubuntu like trusty32 or precise32. Just change the version in the vagrant file and reinstall vagrant in new directory.
• Make sure you are using the latest vagrant and virtualbox versions.
• Last resorts: Format your computer, reinstall windows and buy an intel core isomething processor.

Hope that helps.

[lpickerson86]

thanks, but I have same "Authentication failure" problem like say @tubiz:

devops@devops-server:~/workspace/coreos-vagrant$ vagrant up
Bringing machine 'core-01' up with 'virtualbox' provider...
==> core-01: Importing base box 'coreos-alpha'...
==> core-01: Matching MAC address for NAT networking...
==> core-01: Setting the name of the VM: coreos-vagrant_core-01_1405929178704_22375
==> core-01: Clearing any previously set network interfaces...
==> core-01: Preparing network interfaces based on configuration...
    core-01: Adapter 1: nat
    core-01: Adapter 2: hostonly
==> core-01: Forwarding ports...
    core-01: 22 => 2222 (adapter 1)
==> core-01: Running 'pre-boot' VM customizations...
==> core-01: Booting VM...
==> core-01: Waiting for machine to boot. This may take a few minutes...
    core-01: SSH address: 127.0.0.1:2222
    core-01: SSH username: vagrant
    core-01: SSH auth method: private key
    core-01: Warning: Connection timeout. Retrying...
    core-01: Warning: Authentication failure. Retrying...
    core-01: Warning: Authentication failure. Retrying...
    core-01: Warning: Authentication failure. Retrying...
    core-01: Warning: Authentication failure. Retrying...
    core-01: Warning: Authentication failure. Retrying...
    core-01: Warning: Authentication failure. Retrying...
    core-01: Warning: Authentication failure. Retrying...
    core-01: Warning: Authentication failure. Retrying...
    core-01: Warning: Authentication failure. Retrying...
    core-01: Warning: Authentication failure. Retrying...
    core-01: Warning: Authentication failure. Retrying...
    core-01: Warning: Authentication failure. Retrying...
    core-01: Warning: Authentication failure. Retrying...
    core-01: Warning: Authentication failure. Retrying...
    core-01: Warning: Authentication failure. Retrying...
    core-01: Warning: Authentication failure. Retrying...
    core-01: Warning: Authentication failure. Retrying...
    core-01: Warning: Authentication failure. Retrying...
    core-01: Warning: Authentication failure. Retrying...
    core-01: Warning: Authentication failure. Retrying...
    core-01: Warning: Authentication failure. Retrying...
    core-01: Warning: Authentication failure. Retrying...
    core-01: Warning: Authentication failure. Retrying...
    core-01: Warning: Authentication failure. Retrying...
    core-01: Warning: Authentication failure. Retrying...
    core-01: Warning: Authentication failure. Retrying...
    core-01: Warning: Authentication failure. Retrying...
    core-01: Warning: Authentication failure. Retrying...
    core-01: Warning: Authentication failure. Retrying...
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.

I create new Issue on CoreOS repo: Issue#176

[lpickerson86]

@tubiz you need add to Vagrant file: config.ssh.username = "core". It's work for my recent cloused Issue#176

[jeremyfelt]

I just noticed on my home machine that I wasn't getting the same number of Warning: Connection timeout. Retrying... messages as I am on my work machine with VVV. On two halt/up instances, I see the message only once each time, which is acceptable.

This may not be a solution for every case, but it's worth looking into–this suggestion on SO sets the v.gui = true flag, which causes VirtualBox to open the console for the machine as it's booting. In some cases, it may be an error with the boot process that is causing the long delay.

Probably not the answer for those with the same issue on a fresh checkout, but worth checking to see what the output is. I wish I brought my work machine home so that I could have a better answer immediately, but I'll check in the morning.

[magic2goodil]

I have also seen this issue when the MAC address set for the Host-only Adapter does not match that of the virtual machine's ethernet1 adapter. If you can get your virtual machine to boot up from within VirtualBox, open up a terminal and check the MAC address under your 2nd adapter listed when you fire off: ifconfig -a. Strip out the colons and that's what your MAC address should be entered as in virtualbox.

Here's a shortcut for finding the correct MAC address on linux: ifconfig -a | grep eth1 | cut -f 11 -d ' ' | sed 's/://g' | awk '{print toupper($0)}'

[tjanson]

I’m not using VVV (never heard of it, to be honest), but came here after googling

Warning: Remote connection disconnect. Retrying...

It turned out to be a well know issue with Trusty 64 boxes. Maybe that applies to some of you.

[mar-io]

Yeah I was having this same error on my Windows 7 64 bit laptop. To fix I went into the BIOS and looked for the Virtualization Settings. I made sure to enable Intel Virtualization. Once that was done and the machine rebooted I was able to 'vagrant up" with no problem.

[janika]

I can confirm that on Ubuntu 14.04 the connection timeout problem with ubuntu/trusty64 virtual machine was fixed when I enabled Intel Virtualization from the BIOS.

[vgrinko]

Best recommendation for me was to load it with GUI (configurable in Vagrantfile).
Logged in with vagrant:vagrant.

Checked if SSHD is running
# service sshd status (CentOs 5.3).
And then tried to run it. It gave me error:
# sudo service sshd start
/var/empty/sshd must be owned by root and not group or world-writable

I had to chown and chmod, that issue was originally introduced by me before.

[ziali]

I did a 'vagrant reload' and it said there were some issues with the ssh credentials or networking, but it was able to resolve them and it provisioned the machine as normal

[martinezdelariva]

If it helps my problem was the firewall. Thanks @dezinerdudes

[itmecho]

Hi @dezinerdudes !

I had this problem for a long time. It was really annoying as at work I was using using ubuntu/trusty64 and at home I had to change it to trusty32 to get it to run. I recently started using Docker which only runs on 64 bit systems. This meant that manually changing the image to trusty32 was no longer an option.

I finally found this thread and was reading through it until I found @janika 's comment about the BIOS setting. I went into my BIOS and sure enough, after some trawling through pages of settings I found that Intel Virtualization technology was disabled. I enabled it, rebooted and my problem was solved!

Hopefully this helps you or someone else! (Also, massive thanks @janika !!)

[dezinerdudes]

Awesome! Thanks for sharing.

[oliversalzburg]

Just FYI, it can be pretty helpful to simply start the VM in the VirtualBox GUI to see what the issue might be:

[ss44]

Enabling the virtualization settings in the bios worked for me. cheers!

[xitude]

I fixed my with a firewall issue. I had to added it to connections.

[xacaxulu]

+1

[mucsi96]

Enabling the virtualization settings in the bios worked for me as well.(64 bit Windows 8.1) thanks!

[morganda]

I just ran into a similar issue (same error message).

Setup: I have several boxes in 1 Vagrantfile (testing a replication set in mysql). Each box was pretty much the same except for the name, the IP, and how it's provisioned.

Problems: While spinning up and down some of these boxes, tweaking my provisioners, and the Vagrantfile, I started to get this issue on one of my boxes. I attempted to destroy the the box, vagrant box remove, rm -rf .vagrant/ to no avail. I set the gui flag so I could get on the box and see what wasn't right. The box hadn't taken the IP I had given it! No idea why.

Solution: There was a typo in my Vagrantfile. I'm not exactly sure where the typo was, because I just blew away the config and copied it over from a functioning box and just tweaked it so it had the IP and name that I had before. I wish I had taken the time to identify the typo in my Vagrantfile, but I was annoyed enough that I didn't care at the time.

Hope that helps someone.

[latentgod]

Oh... I also face this problem ,and I spend 4 hours to solve this problem . First, according to way which appear on internet ,it doesn't work. At last,I discovery my vmware network card is conflict with virtualbox network card.Important ,the vboxnet must be in 192.168.10.0/24 and the ip of Homestead.yaml also must be in 192.168.10.0/24 .So you may be modify vmware network ,and it can't in 192.168.10.0/24. The above is my solutions.

[hkic]

My private_key file is missing in PATH_TO\.vagrant\machines\default\virtualbox. After restoring it, vagrant box can authenticate the ssh connection.

[mtrovo]

@hkic thanks for the comment, my vm had the same problem and I fixed it based on this link http://stackoverflow.com/a/23554973/305116, basically I just added my personal private key to the Vagrantfile and it all worked.

  # SSH Agent Forwarding
  #
  # Enable agent forwarding on vagrant ssh commands. This allows you to use ssh keys
  # on your host machine inside the guest. See the manual for `ssh-add`.
  config.ssh.private_key_path = '~/.ssh/id_rsa'
  config.ssh.forward_agent = true

[spigotdesign]

Thanks @mtrovo adding the private_key_path line worked for me too.

[ronezone]

@badmadrad Your answer worked for me on Windows 8.1 64-bit! ENABLED Virtualization Technology in BIOS. Thank you!

FYI to others when searching for how to update your BIOS: include your machine's manufacturer and model in your google search! F10 on boot for HP Envy. Cheers, Ron

[jmcbee]

@badmadrad Congralutations on your PhD!

[poznet]

Anwser is simple

stop vagrant
remove insecure_private_key from c:\users\username.vagrant\
vagrant up

key will be regenerated and setup

[GuerrillaCoder]

Hey Guys,

I had same issue but I enabled virtualization in my bios and it fixed it. Weird thing is that other boxes were working without it enabled.

Check your bios. It will probably be under advanced -> CPU

[jmcbee]

It will work without VT-X enabled but for 64bit boxes it needs VT-X that's why it's failing to start.

[schikulski]

I've tried the following:

• Clean install of VirtualBox and Vagrant
• Checked CPU for VT-X support (I'm running a newer Mac so it should be OK).
• Using 32-bit image(just in case)
• Setting the timeout to at least 15min

But I'm still getting the same error as above.
I tested with a clean vagrant init hashicorp/precise32 - and that worked perfectly:

==> default: Waiting for machine to boot. This may take a few minutes...
default: SSH address: 127.0.0.1:2200
default: SSH username: vagrant
default: SSH auth method: private key
==> default: Machine booted and ready!

But with VVV It's trying to connect to 127.0.0.1:2222. And I'm getting the same error as the other ones:

==> 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: Warning: Connection timeout. Retrying...

Anyone have any ideas why this i happening? And why is VVV using port 2222 and the clean vargrantfile using 2200?

Edit:
When I simply changed to hashicorp/precise32in the original VVV VagrantFile it actually worked as expected. Connection using port 2222.

Edit2:
The chef/ubuntu-14.04 box worked as expected too, so there's obviously something up with the ubuntu/trusty64 box.

[YordanGeorgiev]

@dezinerdudes commented on Jul 3, 2014 - your check list was quite comprehensive ... the problem with the https://atlas.hashicorp.com/ubuntu/boxes/trusty64/versions/20150609.0.10 version is that once initialized there is a keyboard input needed ( to select from the bootloader menu !!!! ) OMG I am installing a headless guest image in order to avoid messing with GUI , but no first I have to install VB extension pack , enable display server in VB and after that start remote Desktop Connection to a console to hit down arrow and press Enter for the guest to boot for first time !!! ..... I would consider this a bug with the 20150609.0.10 version ;o) ... Anyway your check list was the most detailed one I found on the broad Internet for this problem ...

[redconfetti]

I ran into an issue with my Vagrant box that brought up the following error when I'd try to use vagrant ssh.

ssh_exchange_identification: Connection closed by remote host

It turns out that this was caused by my Ansible scripts reconfiguring sshd to run on port 2222, because I thought this was needed for my local development environments setup. It turns out that Vagrant or Virtualbox (I'm not sure which one) sets up port forwarding from localhost (127.0.0.1) on port 2222 to the VM on port 22.

I simply needed to reconfigure SSHD to run on port 22.

[plahpoy]

While this might not be the 'best' way to do it, and it does not 'fix' the key issue, this is what worked for me and got me up and running to the point I could at least use it:

Vagrant 1.7.4 / Windows 7 / non production

Edit the Vagrantfile and add the following 3 lines:

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

That's what worked for me.

[ghost]

I was having this issue with an AMD based machine - had to enable "Secure Virtual Machine Mode" in BIOS and it worked without a hitch

[fjarrett]

I spent many hours trying to resolve this on OS X El Capitan only to discover that custom DNS servers I had set in my Wi-Fi settings were causing SSH to timeout :tired_face: Removed them and everything worked again as normal. Hope this helps someone else avoid the headache I just gave myself...

[alex1a]

@fjarrett i don't test, but i think i'm having the same problem, do my custom dns server in my bridged connection on win7

[ronezone]

Thank you @poznet. Your answer worked for me after my IT addressed issues with my Windows 10 upgrade and broke my glorious VVV env. After I re-enabled VT-x in BIOS (Virtualization Technology), I was seeing errors indicating ssh issues; so I removed the insecure_private_key from C:\Users\<username>.<domain>\.vagrant.d\ and it was recreated without issue on next vagrant up ...YAY!

Here is output I was seeing:

$ vagrant reload
==> default: Removing hosts
==> default: Attempting graceful shutdown of VM...
    default: Guest communication could not be established! This is usually because
    default: SSH is not running, the authentication information was changed,
    default: or some other networking issue. Vagrant will force halt, if
    default: capable.
==> default: Forcing shutdown of VM...
==> default: Checking if box 'ubuntu/trusty64' is up to date...
==> default: A newer version of the box 'ubuntu/trusty64' is available! You currently
==> default: have version '20151203.2.0'. The latest is version '20151217.0.0'. Run
==> default: `vagrant box update` to update.
==> default: Clearing any previously set forwarded ports...
==> default: Clearing any previously set network interfaces...
==> default: Preparing network interfaces based on configuration...
    default: Adapter 1: nat
==> default: Forwarding ports...
    default: 80 => 8080 (adapter 1)
    default: 22 => 2222 (adapter 1)
==> default: Running 'pre-boot' VM customizations...
==> 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: Warning: Connection timeout. Retrying... 
    default: Warning: Connection timeout. Retrying... 
    default: Warning: Connection timeout. Retrying...
   …
    default: Warning: Connection timeout. Retrying...
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.

$ vagrant halt
==> default: Running triggers before halt...
==> default: Executing command "vagrant ssh -c vagrant_halt"...
==> default: ssh_exchange_identification: read: Connection reset by peer
==> default: Command execution finished.
The command "vagrant ssh -c 'vagrant_halt'" returned a failed exit code. The
error output is shown below:

ssh_exchange_identification: read: Connection reset by peer

VirtualBox GUI -> Start...

Failed to open a session for the virtual machine vagrant-local.
Failed to assign the machine to the session (E_FAIL).
Result Code:    VBOX_E_VM_ERROR (0x80BB0003)
Component:  Machine
Interface:  IMachine {480cf695-2d8d-4256-9c7c-cce4184fa048}
Callee RC:  E_FAIL (0x80004005)

Failed to open a session for the virtual machine vagrant-local.
The VM session was aborted.
Result Code:    E_FAIL (0x80004005)
Component:  SessionMachine
Interface:  ISession {12f4dcdb-12b2-4ec1-b7cd-ddd9f6c5bf4d}

[llawrenc]

Hi All, for what it is worth, I had this same issue with SSH remote disconnect error on boot and solved it for my circumstances. I fixed the bios setting for virtualization and tried all other solutions above to no avail. I destroyed and reprovisioned the vagrant machine from scratch and this solved it, no intervention required - it's even using the default Vagrantfile.

LL

[jartaud]

Thanks @ronezone. Removing the key works for me.

[is-aka-konor]

Thanks @lkwdwrd,
I turned Hyper V off and it helped me.

[mrjamiebowman]

I am having a lot of issues SSH into my vagrant ubuntu box.. but just to eliminate possibilities I initialized a lucid32 and was able to SSH into that without any problems.

[vekexasia]

Here i can't connect from an ubuntu host. Virtualbox is 5.0.10
ping gives From 192.168.50.1 icmp_seq=1 Destination Host Unreachable

In virtualbox gui the machine is up and running while not showing anything in the "preview"

I waited more than 20 mins for the vm to boot i believe there's something not working properly.

[unfulvio]

I experience this problem when my machine is suspended

At first I thought it'd happen when my machine get suspended and VVV was already up, then at host resume it's not accessible

However I noticed that even if I haven't yet started VVV and I suspend the host, SSH will have problems when I resume and can't vagrant up

The issue happens with Ubuntu 15.10 and VMWare Workstation -- had similar problems with Virtualbox 5 as well

[mohamdio]

I solved the problem by changing the version of ubuntu in vagrantfile to trusty32 instead of 64 in VM Virtualbox because my laptop (old) can't virtualize 64 bits like what @fxbenard did, after down ot 32 get the same problem again and solved it by doing this solution from here
https://github.com/mitchellh/vagrant/issues/3860#issuecomment-167664778
Add or change in the vagrantfile provider section:

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

i hope this will help someone

[balmas]

@mohamdio thanks so much this did the trick for me too!

[cfoellmann]

this should be written up for the docs!?

[onshop]

Oddly, to get vagrant up progressing further, in the BIOS settings I had to:

Disable: Virtualisation
Enable: VT-X

[cristovaov]

@onshop I believe this is something that VirtualBox menions in its documentation

[jeffreygnatek]

i was having this issue and i followed the instructions to completely remove vagrant, including plugins etc, and remove virtualbox, then brew installed them and installed the trigger and host-updater plugin, then everything appeared to work ok.

[malanve]

Make sure the Virtual Machine's sshd service starts up on bootup

[ocombe]

OMG thank you @shivapoudel, I disabled Hyper-V and vagrant is able to connect to ssh again! I think this option was activated by visual studio to run the Windows Phone VMs. If anyone has this problem, here is how to disable it: http://www.eightforums.com/tutorials/42041-hyper-v-enable-disable-windows-8-a.html then just reboot and it will work again !

[JJJ]

I'll drop this here. For me, it was the sheer number of directories in VVV's www directory (about 339k.)

[giovannipds]

Hello peoople! I didn't read it all but, I just came by to gave my little contribution. Based on your comments, I was able to diagnostic what my problem was (the same issue / related solutions). And this is the knowledge that helped me through that. First, I had 2 different problems:

1. vagrant up wasn't able to find my ssh 'id_rsa' (because I didn't have it yet, at that time):
   I ran ssh-keygen -t rsa -b 4096 -C "[email protected]", based on this GitHub's article, and voilá, steped through that;
2. Then, I got the same problem as you guys "Warning: Connection timed out. Retrying...", eternally...:
   So, reading your comments, I had to restart my system and look at my BIOS (F2 to get there, on PC), and there I've noticed that Virtualization was disabled. I've enabled that, saved, and started the system once again, to check if has changed anything.

After that, vagrant up worked like a charm! It's 4am but it is running! How cool is that, hã? :D As I know there are very few masochist developers like me, that would try this at Windows, specially at Windows 10, I just couldn't not to forget coming here and left my word... another important information, is that, I was trying to set-up Laravel 5, using Homestead, VirtualBox, composer etc. It has worked. So, hope this comment helps someone like the comments on this issue helped me. My best wishes. G-bye!

[tonygilkerson]

I was having the same issue on windows and turning off my local firewall as suggested above fix the problem. Thanks very much.

[sedulousfunds]

I spent two days trying to get vagrant ssh or any ssh client to connect with vagrant/VM on Windows 10 with no luck - both git ssh and vagrant ssh connections were refused. After working through every recommendation on this thread, I found out the problem was that I had to completely remove my anti-virus (Iolo System Mechanic/System Shield). Note that simply disabling real-time protection made no difference. Once I deleted System Mechanic and replaced with Windows Defender (included in Windows 10) as my anti-virus app, vagrant up completely provisioned vvv and I was good to go - I will leave it to smarter people to explain why. Hope this helps!

[WRRB]

I'm on windows 7. What worked for me was changing the box.
boxcutter/ubuntu1404-desktop didn't work (I couldn't ssh into that one no matter what I tried)
janihur/ubuntu-1404-desktop & boxcutter/centos72-desktop both did work from the get go.

[stuartjnelson]

I just started getting this error last week. I've trawled the internet for fixes but as of yet nothing has worked. I'm running;

• OSX 10.11.6
• Vagrant 1.8.5
• VirtualBox 5.0.16
• Ansible 2.0.2.0

Has anyone else come across this issue recently? I've tried everything I can find form creating a new user to PRAM restart to trying to bypass SSH to manual settings the username & password in my vagrant file;

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

Any advice anyone has would be much appreciated!

[msdos]

@stuartjnelson Unfortunately, I had to run vagrant ssh-config and delete the key that it's shown, then run vagrant destroy to completely solve my problem.

[rmansnacks]

I solved it, it's really trivial. Go to your virtualbox settings of machine -> network -> under your first adapter (set to nat) click on advanced end check "Cable connected" and click OK.

It's sounds easy, but it took me while to troubleshoot. I've installed new vagrant along with new vbox, I've set new machine in my no firewall no virus scanner environment. I've tried to connect via vagrant with no result. Then i've decided i'll copy my vagrant ssh key to other machine. I've couldn't connect (i had no adapter set on vb). So i made public adapter on my vbox (this is when i realised that default option is set to cable not connected). So i went to my machine to check the state of my network adapter, it was fun to realize that it was disconnected :) It came with last Virtualbox update. Im most certainly sure that my solution will solve problem for most of you. It's bad habit of us not to check vbox settings.

[AlEltono]

Thanks rmansnacks !
I was looking for the same issue for 2 hours now, but checking "Cable Connected" fixed it for me.

Strange that it's "unplugged" by default...

[JJJ]

Everything is better with screenshots.

[rmansnacks]

It's cross platform issue, should i to turn on 3 different computers to make those screens? We are people of it not screen readers ;)

[probablyabear]

Confirmed @AlEltono's solution worked for me on El Capitan 10.11.6 (15G1108)

[timgvandijk]

Wauw, worked through at least a dozen Stack Overflow / Laravel.io / Laracasts threads, reinstalled vagrant, virtualbox, and homestead, and tried tons of proposed solutions, only to find out the source of all this madness is one lonely unchecked checkmark ^^

Thanks @rmansnacks, I can sleep in peace now.

[v1ncen]

Same here. Thanks too @rmansnacks! Worked for me on macOS Sierra with VirtualBox 5.0.30 r112061

[stevenbuehner]

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

[lvillarino]

Confirmed @AlEltono's solution worked for me on El Capitan 10.11.6

[pankaj9492]

Hi All,
I did try all things which is mention above threads, but problem is not solved so any can give me correct solution for it.

I am using cantos 6.2 and with virtual box 5.1 and Vagrant 1.9.3 for installing PredictionIO.

vagrant up has stuck and timeout error after increasing time too.

[ralphxlx]

Hi @pankaj9492 , I got same problem. Did you fixed it? But i has been installed homestead-2.0.box

[tomjn]

I'm closing this out as most of the issues are with older versions of VB/Vagrant/VVV, and need to be retested with the latest versions

[lock[bot]]

This thread has been automatically locked since there has not been any recent activity after it was closed. Please open a new issue for related bugs.