dezinerdudes commented 10 years ago

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 commented 10 years ago

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 commented 10 years ago

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 commented 10 years ago

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 commented 10 years ago

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 commented 10 years ago

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

jeremyfelt commented 10 years ago

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 commented 10 years ago

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 commented 10 years ago

@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 commented 10 years ago

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

shivapoudel commented 10 years ago

@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 commented 10 years ago

@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 commented 10 years ago

@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 commented 10 years ago

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 commented 10 years ago

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 commented 10 years ago

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 commented 10 years ago

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

fxbenard commented 10 years ago

@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 commented 10 years ago

@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 commented 10 years ago

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 commented 10 years ago

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 commented 10 years ago

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

jeremyfelt commented 10 years ago

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 commented 10 years ago

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 commented 10 years ago

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 commented 10 years ago

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 commented 10 years ago

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 commented 10 years ago

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 commented 10 years ago

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 commented 10 years ago

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

itmecho commented 10 years ago

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 commented 10 years ago

Awesome! Thanks for sharing.

oliversalzburg commented 9 years ago

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

ss44 commented 9 years ago

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

xitude commented 9 years ago

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

xacaxulu commented 9 years ago

+1

mucsi96 commented 9 years ago

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

morganda commented 9 years ago

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 commented 9 years ago

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 commented 9 years ago

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

mtrovo commented 9 years ago

@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 commented 9 years ago

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

ronezone commented 9 years ago

@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 commented 9 years ago

@badmadrad Congralutations on your PhD!

poznet commented 9 years ago

Anwser is simple

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

key will be regenerated and setup

GuerrillaCoder commented 9 years ago

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 commented 9 years ago

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

schikulski commented 9 years ago

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 commented 9 years ago

@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 commented 9 years ago

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 commented 9 years ago

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.

Varying-Vagrant-Vagrants / VVV

SSH Timeout - Cant connect via ssh no matter what #375

service sshd status (CentOs 5.3).

sudo service sshd start

Vagrant 1.7.4 / Windows 7 / non production