vagrant stuck at "default: Warning: Connection timeout. Retrying..."

Question

I googling for some days and i do not find any solution to solve my problem.

I pretty sure, This problem not from VT-x because I using bento/ubuntu-14.04-i386 on Windows 8.1 (I guess my CPU allow to use 32bit as guest but 64bit dont C2D E7200)

I clone github repo from laravel/settler and replace config.vm.box = 'bento/ubuntu-14.04' into config.vm.box = 'bento/ubuntu-14.04-i386' on Vagrantfile

And start vagrant with vagrant up and i get this

λ vagrant up
Bringing machine 'default' up with 'virtualbox' provider...
==> default: Importing base box 'bento/ubuntu-14.04-i386'...
==> default: Matching MAC address for NAT networking...
==> default: Checking if box 'bento/ubuntu-14.04-i386' is up to date...
==> default: Setting the name of the VM: settler_default_1446635664316_42330
==> default: Clearing any previously set network interfaces...
==> default: Preparing network interfaces based on configuration...
    default: Adapter 1: nat
==> default: Forwarding ports...
    default: 80 => 8000 (adapter 1)
    default: 3306 => 33060 (adapter 1)
    default: 5432 => 54320 (adapter 1)
    default: 35729 => 35729 (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...
    default: Warning: Connection timeout. Retrying...
    default: Warning: Connection timeout. Retrying...
    default: Warning: Connection timeout. Retrying...
    default: Warning: Connection timeout. Retrying...
    default: Warning: Connection timeout. Retrying...
    default: Warning: Connection timeout. Retrying...
    default: Warning: Connection timeout. Retrying...
    default: Warning: Connection timeout. Retrying...
    default: Warning: Connection timeout. Retrying...
    default: Warning: Connection timeout. Retrying...
    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 ssh-config

Host default
  HostName 127.0.0.1
  User vagrant
  Port 2222
  UserKnownHostsFile /dev/null
  StrictHostKeyChecking no
  PasswordAuthentication no
  IdentityFile C:/Users/Jame/.vagrant.d/insecure_private_key
  IdentitiesOnly yes
  LogLevel FATAL

vagrant global-status

id       name    provider   state   directory
------------------------------------------------------------------------------------------
87ba96c  default virtualbox running C:/Users/Jame/Dropbox/Private/myscript/config/settler

The above shows information about all known Vagrant environments
on this machine. This data is cached and may not be completely
up-to-date. To interact with any of the machines, you can go to
that directory and run Vagrant, or you can use the ID directly
with Vagrant commands from any directory. For example:
"vagrant destroy 1a2b3c4d"

and GUI is

Please help, Thank :)

Answer 1

This might have various reasons and it's mostly about private / public keys. You can follow these step to troubleshoot:

1) First of all try if you can ssh with password to make sure that it's about keys. If you can't, then you should first find the reason for that and step 3 would be helpful in that case too.

2) Second thing to do is to find out which private key vagrant is using. Run vagrant ssh-config and check IdentityFile, in your case this is the default insecure_private_key provided by vagrant.

3) Now run vagrant ssh -- -v which will show you the details of ssh progress, double check the private key that is used. If you see smt. like this at the end you can be sure that server cannot match your public key and that's the problem:

debug1: Authentications that can continue: publickey,password
debug1: Next authentication method: publickey
debug1: Trying private key: /Users/ozan/.vagrant.d/insecure_private_key
debug1: Authentications that can continue: publickey,password
debug1: Next authentication method: password
vagrant@127.0.0.1's password:
debug1: Authentications that can continue: publickey,password
Permission denied, please try again.
vagrant@127.0.0.1's password:

4) ssh your guest with password and check if the public key is ok. You should check the permissions of the ~/.ssh directory and the /.ssh/authorized_keys file. They must be 755 (drwx------) and 600 (-rw-------) respectively and they must be owned by vagrant user.

5) Check that the public key matches your private key. To do so generate the public key from private key like ssh-keygen -f ~/.vagrant.d/insecure_private_key -y on your host and compare it with the one in ~/.ssh/authorized_keys

Also make sure that the keys is in the ~/.ssh/authorized_keys are on a single line, if you do smt. like copy paste it can happen that newline characters are inserted which will obviously break the public key.

---

And here are some notes about vagrant and homestead which would help:

Normally vagrant replaces this insecure_private_key with some secure one and adjusts everything at startup or halt if config.ssh.insert_key is set totrue in you configuration (which is the default in the latest version 1.7.4). So you might see some path under your .vagrant directory for the IdentityFile.

The problem in my case was, you can define which private key to use in your Homestead.yaml normally, however homestead didn't respect the custom keys for some reason, and vagrant didn't replace the insecure key too...

So I basically generated and copied the public key of the private key that is listed as IdentityFile and put it into authorized_keys which did solve the issue.

After fixing the public key I realized that vagrant replaced the insecure_private_key with some secure one successfuly...