Новая копия Vagrant не создаст закрытый ключ SSH - PullRequest
1 голос
/ 06 ноября 2019

Я пытаюсь настроить новый рабочий компьютер для работы на локальном хосте, и мы переключаемся на использование Vagrant и VirtualBox, а не Ubuntu (чтобы быть более согласованными на всех компьютерах разработчиков). Я использую https://www.sitepoint.com/getting-started-vagrant-windows/ в качестве основы для построения сервера localhost, но он всегда прерывается и истекает в строке «default: SSH метод аутентификации: закрытый ключ».

Я пытаюсьустановить в Windows, используя VirtualBox 6.0.14, Vagrant 2.2.6 и putty-64bit-0.73, при загрузке Ubuntu Server 14.04 (также протестирован с 16.04).

Я пытался следовать инструкциям, приведенным в ссылкевыше. После некоторых исследований я также попытался установить

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

в Vagrantfile и установить

config.ssh.insert_key = false

согласно Невозможно ssh перехватить виртуальные машины, используя небезопасный закрытый ключ (vagrant 1.7.2) .

Это приводит к тому же результату при установке на старых и новых рабочих компьютерах.

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.

Единственной ошибкой была ошибка тайм-аута, которая вообще не ожидалась.

Пустья знаю, нужна ли какая-либо дополнительная информация

...