devopsgroup-io/vagrant-digitalocean

Vagrant Up hangs after creating droplet + user account...

AlphaDork opened this issue · 3 comments

AlphaDork commented

Vagrant up seems to hang after creating the user account. I can "vagrant ssh" into the box and a droplet is created correctly - but the original command never comes back from the "vagrant up" command. Also if I include a provisioning script - it's never executed (I have to vagrant up --provision that).

I am running this from a Win7x64 box if that's an issue.

C:\Dev\vagrant\xen-jekyll>vagrant up
Bringing machine 'default' up with 'digital_ocean' provider...
   ==> default: Using existing SSH key: Vagrant
   ==> default: Creating a new droplet...
   ==> default: Assigned IP address: <ip-address-censored>
   ==> default: Private IP address: <ip-address-censored>
   Text will be echoed in the clear. Please install the HighLine or Termios libraries to suppress
   Enter passphrase for <path-to-key-file-censored>
   ==> default: Creating user account: ubuntu...*

Vagrant file is below:

# -*- mode: ruby -*-
# vi: set ft=ruby :

# All Vagrant configuration is done below. The "2" in Vagrant.configure
# configures the configuration version (we support older styles for
# backwards compatibility). Please don't change it unless you know what
# you're doing.

Vagrant.configure("2") do |config|

  config.vm.hostname = 'MSPLDTEST'
  # Alternatively, use provider.name below to set the Droplet name. config.vm.hostname takes precedence.

  config.vm.provider :digital_ocean do |provider, override|
    override.ssh.username = 'ubuntu'
    override.ssh.private_key_path = '~/.ssh/id_rsa_mindsplode'
    override.vm.box = 'digital_ocean'
    override.vm.box_url = "https://github.com/devopsgroup-io/vagrant-digitalocean/raw/master/box/digital_ocean.box"

    provider.token = '<token-censored>'
    provider.image = 'ubuntu-16-04-x64'
    provider.region = 'nyc2'
    provider.size = '1gb'
    provider.private_networking = true
    provider.ssh_key_name = Vagrant
    provider.setup = true
  end
end

TIA!

davidmyersdev commented

I'm also experiencing this issue after assigning the IP address:

$ vagrant up --provider=digital_ocean
Bringing machine 'default' up with 'digital_ocean' provider...
==> default: Using existing SSH key: Vagrant
==> default: Creating a new droplet...
==> default: Assigned IP address: REDACTED

config.vm.provider "digital_ocean" do |provider, override|
    # you probably don't need to change these
    override.vm.box = "digital_ocean"
    override.vm.box_url = "https://github.com/devopsgroup-io/vagrant-digitalocean/raw/master/box/digital_ocean.box"

    # configure the DO droplet here
    override.ssh.private_key_path = "~/.ssh/id_rsa"
    provider.token = "REDACTED"
    provider.name = "REDACTED"
    provider.image = "ubuntu-14-04-x64"
    provider.region = "nyc3"
    provider.size = "512mb"
end

Thanks!

EDIT: Nevermind! It looks like I was actually running into the same issue as #134, and I was able to fix it by removing my old ssh key from my DO account.

tarellel commented

I was getting the same issue, I kept freezing after the box was assigned an IP ADDRESS. So I decided to try running vagrant up in debug mode to see what the heck was going on.

VAGRANT_LOG=debug vagrant up --provider=digital_ocean

To be specific the key type I was using for SSH was ed25519, which is supposed to be quite secure. I believe since a fresh box isn't exactly up-to-date. By default it may not support, until OpenSSL/OpenSSH are updated on the VM's. The reason I came to these conclusions is because is part of the debug error stated:

* kex: diffie-hellman-group14-sha1
* host_key: ssh-rsa
* encryption_server: aes128-ctr
* encryption_client: aes128-ctr
* hmac_client: hmac-sha1
* hmac_server: hmac-sha1
* compression_client: none
* compression_server: none

...skip a bunch of processing out...

E, [2016-10-02T17:22:51.152535 #8768] ERROR -- net.ssh.authentication.agent[80dde318]: ignoring unimplemented key:unsupported key type `ssh-ed25519' /Users/Tarellel/.ssh/id_ed25519
E, [2016-10-02T17:22:51.152689 #8768] ERROR -- net.ssh.authentication.agent[80dde318]: ignoring unimplemented key:unsupported key type `ssh-ed25519' /Users/Tarellel/.ssh/digitalocean_ed25519_key
E, [2016-10-02T17:22:51.152834 #8768] ERROR -- net.ssh.authentication.agent[80dde318]: ignoring unimplemented key:unsupported key type `ssh-ed25519' /Users/Tarellel/.ssh/github_id
E, [2016-10-02T17:22:51.152979 #8768] ERROR -- net.ssh.authentication.agent[80dde318]: ignoring unimplemented key:unsupported key type `ssh-ed25519' /Users/Tarellel/.ssh/development_key
E, [2016-10-02T17:22:51.153121 #8768] ERROR -- net.ssh.authentication.agent[80dde318]: ignoring unimplemented key:unsupported key type `ssh-ed25519' /Users/Tarellel/.ssh/localnetwork_id
E, [2016-10-02T17:22:51.153213 #8768] ERROR -- net.ssh.authentication.session[80df3efc]: all authorization methods failed (tried none, publickey)

DEBUG ssh: == Net-SSH connection debug-level log END ==
 INFO ssh: SSH not up: #<Vagrant::Errors::SSHAuthenticationFailed: SSH authentication failed! This is typically caused by the public/private
keypair for the SSH user not being properly set on the guest VM. Please
verify that the guest VM is setup with the proper public key, and that
the private key path for Vagrant is setup properly as well.>

You'll notice from the output that the DigitalOcean VM's do not support ssh-ed25519 key formats by default. From here I tried switching to a different PublicKey type ssh-rsa which is generate the default generated key type on most systems.

# Vagrantfile
override.ssh.private_key_path = '~/.ssh/id_rsa'
#override.ssh.private_key_path = '~/.ssh/digitalocean_ed25519_key'

Now when connecting to the VM's the new output should be similar to (which means it connected can is attempting to run the provision):

⇒ vagrant up --provider=digital_ocean                                                                                                         [05:23PM]
Bringing machine 'default' up with 'digital_ocean' provider...
==> default: Using existing SSH key: Vagrant
==> default: Creating a new droplet...
==> default: Assigned IP address: [REDRACTED]
==> default: DigitalOcean's debian-8 image lacks sudo. Installing now.
==> default: Creating user account: [REDRACTED]...
==> default: Installing rsync to the VM...
==> default: Rsyncing folder: /Users/[REDRACTED]./Desktop/railsBox/ => /vagrant
==> default: Running provisioner: ansible...
    default: Running ansible-playbook...
PYTHONUNBUFFERED=1 ANSIBLE_FORCE_COLOR=true ANSIBLE_HOST_KEY_CHECKING=false ANSIBLE_SSH_ARGS='-o UserKnownHostsFile=/dev/null -o IdentitiesOnly=yes -o ForwardAgent=yes -o UserKnownHostsFile=/dev/null -o ControlMaster=auto -o ControlPersist=60s' ansible-playbook --connection=ssh --timeout=30 --limit="default" --inventory-file=/Users/[REDRACTED]./Desktop/railsBox/.vagrant/provisioners/ansible/inventory --extra-vars="{\"ansible_ssh_user\":\"vagrant\",\"ansible_connection\":\"ssh\",\"ansible_ssh_args\":\"-o ForwardAgent=yes\"}" -vvv provision/playbook.yml
Using /Users/Tarellel/Desktop/railsBox/ansible.cfg as config file

PLAYBOOK: playbook.yml *********************************************************
1 plays in provision/playbook.yml

PLAY [all] *********************************************************************
gsauthof commented

@tarellel it's not just that the target VM doesn't support ed25519 ssh keys - another reason for failure (silent unless debug is enabled) is that the used net-ssh gem doesn't support ed25519. For example, on Fedora 26. See also #273