I have a server with Ubuntu 12.04, Virtualbox 4.3 and Vagrant 1.5.1. I'm trying to use this box http://puppet-vagrant-boxes.puppetlabs.com/centos-64-x64-vbox4210.box however unsucessfully. When I run "vagrant up" I get this message:

Bringing machine 'default' up with 'virtualbox' provider...
==> default: Importing base box 'centos-64-x64-vbox4210'...
==> default: Matching MAC address for NAT networking...
==> default: Setting the name of the VM: rafael_default_1396403974194_51967
==> 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: 22 => 2222 (adapter 1)
==> default: Booting VM...
==> default: Waiting for machine to boot. This may take a few minutes...
    default: SSH address:
    default: SSH username: vagrant
    default: SSH auth method: private key
    default: Error: Connection timeout. Retrying...
    default: Error: Connection timeout. Retrying...
    default: Error: Connection timeout. Retrying...
    default: Error: Connection timeout. Retrying...
    default: Error: 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.

This is my Vagrant file

# Vagrantfile API/syntax version. Don't touch unless you know what you're doing!

Vagrant.configure(VAGRANTFILE_API_VERSION) do |config|
  # All Vagrant configuration is done here. The most common configuration
  # options are documented and commented below. For a complete reference,
  # please see the online documentation at vagrantup.com.

  # Every Vagrant virtual environment requires a box to build off of.
  config.vm.box = "centos-64-x64-vbox4210"
  config.vm.boot_timeout = 600
  # The url from where the 'config.vm.box' box will be fetched if it
  # doesn't already exist on the user's system.
  # config.vm.box_url = "http://domain.com/path/to/above.box"

  # Create a forwarded port mapping which allows access to a specific port
  # within the machine from a port on the host machine. In the example below,
  # accessing "localhost:8080" will access port 80 on the guest machine.
  # config.vm.network "forwarded_port", guest: 80, host: 8080

  # Create a private network, which allows host-only access to the machine
  # using a specific IP.
  # config.vm.network "private_network", ip: ""

  # Create a public network, which generally matched to bridged network.
  # Bridged networks make the machine appear as another physical device on
  # your network.
  # config.vm.network "public_network"

  # If true, then any SSH connections made will enable agent forwarding.
  # Default value: false
  # config.ssh.forward_agent = true

  # Share an additional folder to the guest VM. The first argument is
  # the path on the host to the actual folder. The second argument is
  # the path on the guest to mount the folder. And the optional third
  # argument is a set of non-required options.
  # config.vm.synced_folder "../data", "/vagrant_data"
  # Enable provisioning with chef server, specifying the chef server URL,
  # and the path to the validation key (relative to this Vagrantfile).
  # The Opscode Platform uses HTTPS. Substitute your organization for
  # ORGNAME in the URL and validation key.
  # If you have your own Chef Server, use the appropriate URL, which may be
  # HTTP instead of HTTPS depending on your configuration. Also change the
  # validation key to validation.pem.
  # config.vm.provision "chef_client" do |chef|
  #   chef.chef_server_url = "https://api.opscode.com/organizations/ORGNAME"    
  #   chef.validation_key_path = "ORGNAME-validator.pem"
  # end
  # If you're using the Opscode platform, your validator client is
  # ORGNAME-validator, replacing ORGNAME with your organization name.
  # If you have your own Chef Server, the default validation client name is
  # chef-validator, unless you changed the configuration.
  #   chef.validation_client_name = "ORGNAME-validator"

my server doesn't have graphic interface How can I fix it? Thanks.

  • Any firewall rules that can affect?
    – pbacterio
    Oct 24, 2014 at 11:45

14 Answers 14


First, try: to see what vagrant private key in you machine config

$ vagrant ssh-config


$ vagrant ssh-config
Host default
  User vagrant
  Port 2222
  UserKnownHostsFile /dev/null
  StrictHostKeyChecking no
  PasswordAuthentication no
  IdentityFile C:/Users/konst/.vagrant.d/insecure_private_key
  IdentitiesOnly yes
  LogLevel FATAL

Vagrant SSH Config Docs

Second, do: Change content of file insecure_private_key with content of yorn own system private key

  • Try other box https://vagrantcloud.com/discover/featured
    – shilovk
    May 10, 2014 at 20:12
  • This seems to work perfect! I removed the insecure key and let Vagrant generate it's own new and works like a charm Nov 5, 2015 at 10:24
  • 1
    How did you achieve that? Which file did you edit?
    – cookie
    Apr 17, 2016 at 7:29
  • @cookie C:/Users/USER_NAME/.vagrant.d/insecure_private_key
    – shilovk
    Apr 17, 2016 at 9:18
  • 1
    It's quite unclear what has to be done - which file should be found where and replaced with which other's file content.
    – lubosdz
    Apr 20, 2018 at 11:24

The SSH connection timeout during boot phase can happen from different reasons such as:

  • system awaits for user interaction (e.g. share partition is not ready),
  • sshd misconfiguration,
  • firewall misconfiguration (in case it's not local),
  • mismatch of your private key,
  • config.vm.boot_timeout time period time is too low (which yours is fine),
  • make sure that the virtualization is enabled in BIOS.

To debug the problem, please run it as:

VAGRANT_LOG=debug vagrant up

If there is nothing obvious, then try to connect to it from another terminal, by vagrant ssh or by:

vagrant ssh-config > vagrant-ssh; ssh -F vagrant-ssh default

If the SSH still fails, re-run it with a GUI (e.g. config.gui = true).

If it's not, check the running processes (e.g. by: vagrant ssh -c 'pstree -a') or verify your sshd_config.

If it is disposable VM, you can always destroy it and up it again. Also consider upgrading your Vagrant and Virtualbox.


Try opening port 22 on the firewall.

Using the Oracle VM VirtualBox Manager, start your VM directly or

add this to your Vagrantfile

config.vm.provider :virtualbox do |vb|
  vb.gui = true

and run "vagrant up"

login using default vagrant credentials

user: vagrant
pass: vagrant

add firewall rule

sudo ufw allow 22

try to enable your GUI of virtual box as reported in this post Vagrant stuck connection timeout and follow steps in comments.

if it doesn't work try to add this modification to your vagrantfile:

create a file named "script.sh" that contains the following commands:

mkdir /home/vagrant/.ssh
wget --no-check-certificate -O authorized_keys 'https://github.com/mitchellh/vagrant/raw/master/keys/vagrant.pub'
mv authorized_keys /home/vagrant/.ssh
chown -R vagrant /home/vagrant/.ssh
chmod -R go-rwsx /home/vagrant/.ssh

then a add this to your vagrantfile:

  # running script shell
    config.vm.provision :shell, :path => "script.sh"

You need to able the GUI. Remove the comment of this lines in your Vagrant file:

config.vm.provider :virtualbox do |vb|
  vb.gui = true

After you need shutdown your machine and start again:

vagrant halt
vagrant up

config.vm.boot_timeout - The time in seconds that Vagrant will wait for the machine to boot and be accessible. By default this is 300 seconds.

I'd increase this until you are able to vagrant SSH in.

  • I tried and it didn't work. =/ I seted timeout 600
    – PoLIVoX
    Apr 2, 2014 at 11:05
  • Can you post your Vagrantfile?
    – dmourati
    Apr 2, 2014 at 14:44
  • I posted my Vagrantfile.
    – PoLIVoX
    Apr 3, 2014 at 2:23

I just solved a similar issue.

Problem: The command to login to the guest development environment, vagrant ssh, was timing out. It routinely works fine on another host machine.

Debugging steps:

  1. In the Vagrantfile, I enabled the Virtualbox GUI (as recommended in another answer) to see what was causing the timeout. Ubuntu was asking for a login and password, which it shouldn’t because it should be using the ssh key instead.

  2. Rather than running vagrant ssh, I ran an equivalent ssh command many times, adding and removing different ssh options. One of the timeout error messages read “could not login to [example.com]” … which makes no sense because this issue has nothing to do with [example.com].

  3. So that prompted me to look at the .ssh/config where [example.com] might have some relevance.

Root Cause: In .ssh/config, there was an entry without Host set, accidentally. Therefore, it was applying that config rule to all ssh calls, including vagrant ssh (which is just a shortcut for a longer ssh command).

Solution: Make sure every .ssh/config entry has Host set.


Try generating insecure_private_key

I solved this by removing the insecure_private_key, located under ~/.vagrant.d

maybe the reason is insecure_private_key file is old


I had the same problem. I deleted everything from SystemPrefereces->Security->Firewall and removed all services from SystemPreferences->Shared. Then I enabled remote login again. That fixed the problem in my case. If this doesn't solve your problem you can visit this site and check it out yourself. (ServerFaqs)


I experienced a similar issue. Here is what I did.

  • Enabled virtualization in BIOS
  • Ran ssh-add ~/.vagrant.d/insecure_private_key
  • Added config.vm.boot_timeout = 600 to my ~/Homestead/Vagrantfile

It's working fine now.


How i fixed:

in vagrantfile, enabled / un-comment the belows ...

config.vm.network "private_network", ip: ""
config.vm.network "public_network"

This problem could be caused by many factors including a situation where the VM box hangs waiting for response from the user. However a common problem has been the mismatch between the private key and the public keys. To rectify this problem, you need to provide a private key file on your host machine that matches the public key file on the VM box. I posted a solution with 3 optional approaches on our blog here...



This works for me:

  1. login with :gui by login/pass: vagrant/vagrant
  2. modify the /etc/rc.local file to include the line sh /etc/init.d/networking restart just before exit 0
  3. disable :gui
  4. vagrant up or vagrant reload



I have the same problem and this is my first experience with vagrant.

I managed to "solve" the problem by using a public network instead of a private one

config.vm.network "public_network", ip: ""

Replace with an IP belonging to your network class.

I'd like to understand what's wrong with the private network though ...

  • it didn't work yet. =/
    – PoLIVoX
    Apr 4, 2014 at 11:46
  • then be sure that you have the latest version of vagrant and virtualbox (download the package from the website)
    – damko
    Apr 5, 2014 at 13:11
  • btw I had several problems during the installation due to some custom settings like "~/.bashrc" and the presence of "/etc/SuSE-release" in my Mint 15 box (required by another software). But among all the changes that I've made I truly believe that what fixed it is the installation of the latest packages
    – damko
    Apr 5, 2014 at 13:53
  • I updated my server and didn't work! =/
    – PoLIVoX
    Apr 5, 2014 at 14:46
  • I didn't use the packages provided by my distribution. I downloaded from their (vagrant and virtualbox) official websites
    – damko
    Apr 6, 2014 at 12:25

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Not the answer you're looking for? Browse other questions tagged or ask your own question.