Vagrant 冻结（超时）在 SSH 验证方法：私钥

Question

So - i googled this and found about 1 Million Issues regarding vagrant provisioning and ssh agents. I tried lots of solutions and nothing works. I tried adding options for the.network adaptor (VirtualBox), destroying the machine, reinstalling vagrant and so on, everytime i need to run vagrant this thing blocks me from working.

Now i work on a completely fresh OS Installation (Ubuntu 20.04). I install VirtualBox 6.1 like instructed on the oracle website and downloaded the right vagrant binary from vagrantup.com/downloads.

And again - vagrant manages it to fail right-away, So okay - lets face it - vagrant is buggy and should be replaced but there are projects where i wont get any budget to migrate to containers, so i need to make that setup work again - and hopefuly someone has a solution for me. that actually works.

Okay - here the final vagrant up output:

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.

So the machine runs but vagrant was not able to connect and run the provisioning. It basically downloaded the image and started it.

So i try vagrant ssh --debug

The last lines i see:

Checking key permissions: ~/.vagrant.d/insecure_private_key
 INFO ssh: Invoking SSH: /tmp/.mount_vagran2MLjJR/usr/bin/ssh ["vagrant@127.0.0.1", "-p", "2222", "-o", "LogLevel=FATAL", "-o", "Compression=yes", "-o", "DSAAuthentication=yes", "-o", "IdentitiesOnly=yes", "-o", "StrictHostKeyChecking=no", "-o", "UserKnownHostsFile=/dev/null", "-i", "~/.vagrant.d/insecure_private_key"]

And thats it - the command will fail without further notice.

So i can only kill the vm (shutdown using vagrant halt wont work either:) and try to get more logs:

(just to make sure i re-installed the vbguest plugin)

vagrant up --debug

Okay - the screen-output looks like a loop. And i can only find "Attemping SSH connection..." with the given options (path to key, etc)

After a few minutes (i gues the configured timeout) i can see:

INFO interface: Machine: error-exit ["Vagrant::Errors::VMBootTimeout", "Timed out while waiting for the machine to boot. This means that\nVagrant was unable to communicate with the guest machine within\nthe configured (\"config.vm.boot_timeout\" value) time period.\n\nIf you look above, you should be able to see the error(s) that\nVagrant had when attempting to connect to the machine. These errors\nare usually good hints as to what may be wrong.\n\nIf you're using a custom box, make sure that networking is properly\nworking and you're able to connect to the machine. It is a common\nproblem that networking isn't setup properly in these boxes.\nVerify that authentication configurations are also setup properly,\nas well.\n\nIf the box appears to be booting properly, you may want to increase\nthe timeout (\"config.vm.boot_timeout\") value."]

Here is some config:

unless Vagrant.has_plugin?("vagrant-vbguest")
  raise 'vagrant-vbguest is not installed, see README.md!'
end
unless Vagrant.has_plugin?("vagrant-disksize")
  raise 'vagrant-disksize is not installed, see README.md!'
end
Vagrant.configure("2") do |config|
  # https://docs.vagrantup.com
  config.vm.box = "ubuntu/bionic64"
  config.disksize.size = "25GB"

  # forward http traffic
  config.vm.network "forwarded_port", guest: 80, host: 8083
  # forward mysql
  config.vm.network "forwarded_port", guest: 3306, host: 3308
  # forward xdebug
  config.vm.network "forwarded_port", guest: 9000, host: 9000
  # forward elastic
  config.vm.network "forwarded_port", guest: 9200, host: 9200
  # forward solr
  config.vm.network "forwarded_port", guest: 8983, host: 8983

  config.vm.synced_folder ".", "/vagrant",
    type: "virtualbox",
    id: "vagrant-root",
    owner: "vagrant",
    group: "www-data",
    mount_options: ["dmode=775,fmode=664"]

  config.vm.provider "virtualbox" do |vb|
    vb.memory = "8192"
    vb.cpus = 4
    vb.customize [ "modifyvm", :id, "--uartmode1", "disconnected" ]
    vb.customize [ "modifyvm", :id, "--cableconnected1", "on" ]
  end

  config.vm.provision "shell", path: "config/bootstrap.sh"
  config.vm.provision "shell", path: "config/solr.sh"
  config.vm.provision "shell", path: "config/startup.sh", run: "always"

end

My problem is - i have no idea how to solve this. I would be happy if i could disable the ssh authentication or use a password but i would need to connect to the vm to change it... Even if i could login using virtualbox i would only be able to fix my local installation. But there are other people as well working on that code and a solution should fix this.

Just to sum this up once more:

We deal with:

• A standard Ubuntu 20.04
• A standard VirtualBox Installation
• A original vagrant binary

Fresh installation

wont work

Kind regards, Philipp

Answer 1

Okay, by adding the following lines (referenced here: https://github.com/hashicorp/vagrant/issues/11777 ), i can successfully run the provisioning and ssh into the machine.

config.vm.provider :virtualbox do |v|
  v.customize ["modifyvm", :id, "--uart1", "0x3F8", "4"]
  v.customize ["modifyvm", :id, "--uartmode1", "file", File::NULL]
end

So what you seem to need (at the moment - i am 100% sure that the next ssh issue with vagrant is only months away):

Vagrant.configure("2") do |config|
  config.vm.provider "virtualbox" do |vb|
    vb.customize [ "modifyvm", :id, "--uartmode1", "file", File::NULL ]
    vb.customize [ "modifyvm", :id, "--uart1", "0x3F8", "4" ]
    vb.customize [ "modifyvm", :id, "--cableconnected1", "on" ]
  end
end

I noticed that the option vb.customize [ "modifyvm", :id, "--uartmode1", "file", File::NULL ] was already set with a different value ( vb.customize [ "modifyvm", :id, "--uartmode1", "disconnected" ] ) and dont know if you can assign multiple values or the original option caused the problem. So i cant tell more for sure, if someone has more insights on this, a additional explanation would be great.

My version looks like (only the relevant lines):

Vagrant.configure("2") do |config|
  config.vm.provider "virtualbox" do |vb|
    vb.customize [ "modifyvm", :id, "--uartmode1", "disconnected" ]
    vb.customize [ "modifyvm", :id, "--uartmode1", "file", File::NULL ]
    vb.customize [ "modifyvm", :id, "--uart1", "0x3F8", "4" ]
    vb.customize [ "modifyvm", :id, "--cableconnected1", "on" ]
  end
end

Answer 2

I have experienced the same problem on a couple of VMs of mine:

Vagrant + VirtualBox and (1) with CentOS 7 and (2) Ubuntu 18.04 images.

Interestingly, the CentOS 7 VM was working fine previously with port forwarding for port 22 on the guest with port 2229 on the host.

TLDR: remapping the port forward on my VM resolved the problem with my Ubuntu VM, so I'm sharing that tip here.

TLDR2: Docker for Windows caused other issues, that I resolved by removing all trace of Windows-related virtualisation ( taking a sledgehammer to a screwdriver task ).

The LONG story:

On the CentOS VM, vagrant ssh-config showed:

  HostName 127.0.0.1
  User vagrant
  Port 2229
  UserKnownHostsFile /dev/null
  StrictHostKeyChecking no
  PasswordAuthentication no
  IdentityFile "[[[REDACTED]]]/.vagrant/machines/default/virtualbox/private_key"
  IdentitiesOnly yes
  LogLevel FATAL

The notable line for me was IdentityFile showed private_key , which indicated that historically the private key was set up successfully.

However when I discovered this issue with my new Ubuntu VM, I returned to the CentOS VM and discovered that on a vagrant up it was also now timing out at SSH auth method: private key , suggesting that something has changed on my system or with VirtualBox during an update (I am already running the latest Vagrant available now, v2.2.19 ).

I checked my new Ubuntu VM, where vagrant ssh-config showed:

Host default
  HostName 127.0.0.1
  User vagrant
  Port 2222
  UserKnownHostsFile /dev/null
  StrictHostKeyChecking no
  PasswordAuthentication no
  IdentityFile [[[REDACTED]]]/.vagrant.d/insecure_private_key
  IdentitiesOnly yes
  LogLevel FATAL

and I noted that IdentityFile was insecure_private_key .

Without delving into the private keys, I suspected maybe some ports were being tied up, so I remapped the port forwards and I found limited success (ie it worked with the Ubuntu VM) by adding this line into my Vagrantfile :

config.vm.network:forwarded_port, guest: 22, host: 8765, id: 'ssh'

Where the host port was changed from the default 2222 to 8765 (just a random port allocation).

When I ran a vagrant destroy and vagrant up this then brought up the Ubuntu VM and I was able to successfully vagrant ssh into the VM. I ran the vagrant destroy simply because I wanted to start the image afresh, not because I had any indication that I needed to.

However, when I ran this same approach with the CentOS VM, it still timed out, so I am delving into the reason for that.

---

UPDATE:

I have concluded that installing Docker Destkop for Windows caused a series of changes to my system that essentially broke VirtualBox with Vagrant .

I have the following steps as my minimum viable resolution :

1. Uninstall Docker Desktop Client
2. Disable a series of Windows Features that are related to virtualization or containers
3. Check CPU-Z and Intel Processor Identification Utility to verify that VT-x is now enabled
4. Run a vagrant reload on my VM in question
5. Uncheck cable connected and re-check cable connected
6. vagrant ssh now works.

I will need to restore each feature one at a time to see how far I can go before breaking this again.

Here's a screenshot of the various tidbits, and the pointers:

(1) Disabled Containers in Windows (2) Disabled Hyper-V (3) Disabled Virtual Machine Platform (4) Disabled Windows Hypervisor Platform (5) Disabled WSL (6) Now VT-x shows up again (it was not showing up previously) (7) Now SLAT shows up again (it was not showing up previously) (8) CPU-Z sees VT-x as well

I now also note that Enable Nested VT-x is no longer greyed out on my CPU settings menu in VirtualBox.