3

I am trying to set up a new work computer for localhost work, and we are switching to use Vagrant and VirtualBox rather than Ubuntu (to be more consistent across out developer computers). I'm using https://www.sitepoint.com/getting-started-vagrant-windows/ as a basis for building the localhost server, but it always breaks and times out at the line 'default: SSH auth method: private key'.

I am trying to install on Windows, using VirtualBox 6.0.14, Vagrant 2.2.6 and putty-64bit-0.73, while loading Ubuntu Server 14.04 (also tested with 16.04).

I have tried following the instructions as provided in the link above. After some research I have, also tried setting

config.ssh.private_key_path = ["C:/Users/Me/.vagrant.d/insecure_private_key"]

in the Vagrantfile and setting

config.ssh.insert_key = false

as per Can't ssh to vagrant VMs using the insecure private key (vagrant 1.7.2).

This has the same result when installing on the old and new work computers.

C:\Users\Me\Documents\vagrant_test>vagrant init ubuntu/trusty64
A `Vagrantfile` has been placed in this directory. You are now ready to `vagrant up` your first virtual environment! Please read the comments in the Vagrantfile as well as documentation on `vagrantup.com` for more information on using Vagrant.

C:\Users\Me\Documents\vagrant_test>vagrant up
Bringing machine 'default' up with 'virtualbox' provider...
==> default: Box 'ubuntu/trusty64' could not be found. Attempting to find and install...
    default: Box Provider: virtualbox
    default: Box Version: >= 0
==> default: Loading metadata for box 'ubuntu/trusty64'
    default: URL: https://vagrantcloud.com/ubuntu/trusty64
==> default: Adding box 'ubuntu/trusty64' (v20190429.0.1) for provider: virtualbox
    default: Downloading: https://vagrantcloud.com/ubuntu/boxes/trusty64/versions/20190429.0.1/providers/virtualbox.box
    default: Download redirected to host: cloud-images.ubuntu.com
    default:
==> default: Successfully added box 'ubuntu/trusty64' (v20190429.0.1) for 'virtualbox'!
==> default: Importing base box 'ubuntu/trusty64'...
==> default: Matching MAC address for NAT networking...
==> default: Checking if box 'ubuntu/trusty64' version '20190429.0.1' is up to date...
==> default: Setting the name of the VM: vagrant_test_default_1572996714007_64150
==> default: Clearing any previously set forwarded ports...
Vagrant is currently configured to create VirtualBox synced folders with the `SharedFoldersEnableSymlinksCreate` option enabled. If the Vagrant guest is not trusted, you may want to disable this option. For more information on this option, please refer to the VirtualBox manual:

  https://www.virtualbox.org/manual/ch04.html#sharedfolders

This option can be disabled globally with an environment variable:

  VAGRANT_DISABLE_VBOXSYMLINKCREATE=1

or on a per folder basis within the Vagrantfile:  config.vm.synced_folder '/host/path', '/guest/path', SharedFoldersEnableSymlinksCreate: false
==> default: Clearing any previously set network interfaces...
==> default: Preparing network interfaces based on configuration...
    default: Adapter 1: nat
==> default: Forwarding ports...
    default: 22 (guest) => 2222 (host) (adapter 1)
==> 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
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.

The only error has been the time-out error, which was not expected at all.

Let me know if any further information is needed

  • Have you removed the VM with `vagrant destroy` and then re-created to apply those changes? – Daniel Nov 06 '19 at 13:07
  • I have attempted to remove and re-install a few times (incl. deleting and re-installing Vagrant and VirtualBox). The method used didn't include `vagrant destroy`, but instead I accessed VirtualBox's interface, set the box to 'power down', then 'remove' and 'delete all files'. Then I went to the vagrant_test folder and deleted it's contents manually. – Matthew Coates Nov 06 '19 at 20:56
  • I attempted to remove the last test, incorporating the `vagrant destroy` and reinstall - save outcome I'm afraid. – Matthew Coates Nov 06 '19 at 21:53
  • Tested on a non-work laptop without issue. I'm guessing that something about the work software installed is interfering with the connection between vagrant and Putty - is there a good way to check for this? – Matthew Coates Nov 10 '19 at 20:50
  • Commonly virus/malware scanners and similar stuff or firewalls cause problems like this. I'd always disable them and re-try to make sure they're not responsible. – Daniel Nov 11 '19 at 07:29
  • I just gave that a try, but it seems to still be stalling at the same point - 'default: SSH auth method: private key', sorry – Matthew Coates Nov 11 '19 at 23:31

0 Answers0