Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Vagrant can't connect to Digital Ocean via ssh #144

Closed
EwanValentine opened this issue Aug 2, 2014 · 23 comments
Closed

Vagrant can't connect to Digital Ocean via ssh #144

EwanValentine opened this issue Aug 2, 2014 · 23 comments

Comments

@EwanValentine
Copy link

My Digital Ocean account has a valid ssh key set-up etc. When I run vagrant up --provider=digital_ocean it hangs for ages. When I run it with VAGRANT_LOG=debug vagrant up --provider=digital_ocean I get loads of warnings and errors claiming the ssh details are failing.

I noticed in those errors:

username: root
password?: false

Or something similar. But the ssh key I'm referencing has a password and the username is ewan. So does anyone know why it would be using 'root' as the user and without a password? I'm not running as sudo or anything either.

I've used the plug-in loads of times well before, but I've just got it set-up on a new laptop with no such luck.

Cheers,

Ewan

@EwanValentine
Copy link
Author

I've now spent about 16 hours just trying to set this up... crazy.

@Olofguard
Copy link

Have you found any solutions for this issue?

@EwanValentine
Copy link
Author

@Olofguard Nope :( Wasted hours trying to get it working. Still no go! What OS are you using?

@Olofguard
Copy link

I'm on OS X 10.9.4.

@EwanValentine
Copy link
Author

@Olofguard Ahh I'm ElementaryOS (Ubuntu based)

@gomes
Copy link

gomes commented Aug 8, 2014

Try to remove your ssh key on Digital Ocean panel. Vagrant try to register the ssh key always when you create a doplet.

@ceedon
Copy link

ceedon commented Oct 20, 2014

Using ssh key already on account or allowing Vagrant to create key yields same result:

...
==> default: Assigned IP address: <address>
<provisioning hangs; manually interrupted.>
^C==> default: Waiting for cleanup before exiting...
Vagrant exited after cleanup due to external interrupt.
$ vagrant ssh
root@<address>'s password:

Vagrantfile follows:

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

     config.vm.hostname = 'hostname'

     config.vm.provider :digital_ocean do |provider, override|
       override.ssh.private_key_path = '~/.ssh/id_rsa'
       override.vm.box = 'digital_ocean'
       override.vm.box_url = "https://github.com/smdahlen/vagrant-digitalocean/raw/master/box/digital_ocean.box"

      provider.token = '<token>'
      provider.image = 'CoreOS (stable) 444.5.0'
      provider.region = 'nyc3'
      provider.size = '512mb'
      provider.ipv6 = true
    end
  end

@Olofguard
Copy link

I take it no one has found a solution to this issue?

@pierreozoux
Copy link

I think I'm hitting this issue right now... And it looks like the same as #134.

I'm trying to use the CoreOS image, and the problem is that I can't override the ssh username.. It's always root, and didn't find a way to override it yet..

I'll try again and send my conclusions.

Cheers

@pierreozoux
Copy link

I managed somehow :)
I just went to the plugin folder (.vagrant.d/gems/gems/vagrant-digitalocean-0.7.1/lib/vagrant-digitalocean/actions) and did search and replace s/root/core/g.

I think the real issue here is because we are not able to override config.ssh.username. Should I open a new issue, or can it stays here?

@sethlivingston
Copy link

I wasn't able to get this working even after trying @pierreozoux's solution. I hope this gets fixed soon. I would help, but I'm not a Rubyer :)

@alanhdu
Copy link

alanhdu commented May 22, 2015

I'm also running into this problem.

My Vagrantfile is:

Vagrant.configure(2) do |config|
  config.vm.define "testertester"
  config.vm.box = "digital_ocean"
  config.vm.box_url="https://github.com/smdahlen/vagrant-digitalocean/raw/master/box/digital_ocean.box"

  config.ssh.private_key_path = "~/.ssh/id_rsa"
  config.ssh.username = "vagrant"

  config.vm.provider :digital_ocean do |provider|
    provider.setup = true
    provider.ssh_key_name = "Vagrant"
    provider.token = <TOKEN>
    provider.image = 'ubuntu-14-04-x64'
    provider.region = 'nyc3'
  end
end

@godlovesugly
Copy link

I've run into this issue myself and managed to fix it by going on the https://cloud.digitalocean.com/settings/security page and setting the ssh key value for the 'vagrant' username to be my public ssh key.

Check out the help articles for more info on adding ssh keys: https://cloud.digitalocean.com/settings/security/help/articles

@alanhdu
Copy link

alanhdu commented May 26, 2015

@godlovesugly Thank you! Worked like a charm.

@akeles
Copy link

akeles commented Jun 2, 2015

I spent hours trying to solve this.
The story is that I managed to get the droplet up from Machine A using digitalOcean_rsa and digitalOcean_rsa.pub.

Later I tried the same steps from another machine B and it failed.
Finally got it to work by renaming digitalOcean_rsa => do_rsa & digitalOcean_rsa.pub => do_rsa_pub

My guess is that multiple SSH keys with the same filename is causing conflict even though the old ssh key is removed from the DigitalOcean console.

@michelekappa
Copy link

In my case, @pierreozoux led me to a workaround for this.
Many are using CoreOS as I can see, so in this regards, the condition is pretty simple: CoreOS only has 'core' user (no root) and sudo access is not authorized; therefore I had to correct some files inside ~/.vagrant.d/gems/gems/vagrant-digitalocean-0.7.7/lib/vagrant-digitalocean/actions. So I did a grep -nr 'root', which showed the following:

  1. setup_user.rb contains a temporary override to root user, which is unneeded in CoreOs. Commenting out this file and its occurences inside actions.rb (in the parent folder), stopped it nagging about it in the debug.
  2. changing to 'core' the occurrences of 'root' inside create.rb, rebuild.rb and setup_sudo.rb resolved the remaining issues.
    Being a workaround, ymmv.

@catrixs
Copy link

catrixs commented Sep 2, 2015

@michelekappa Thank you, it works.

Or config provider.setup = false.

@Tusharsb
Copy link

Tusharsb commented Oct 5, 2015

Following @pierreozoux solution, the following steps worked for me

  • type ssh-keygen in your console. this will generate ~/.ssh/id_rsa and ~/ssh/id_rsa.pub in your machine
  • type cat ~/.ssh/id_rsa.pub in console. this will display the contents of your public certificate. Copy paste this in "add new ssh key" form inside https://cloud.digitalocean.com/settings/security . Choose 'Vagrant' as key name (not 'vagrant') and paste whatever you copied from console into Public SSH Key textbox
  • try vagrant up --provider=digital_ocean

@shanemgrey
Copy link
Contributor

+1

I've had it working at some point where I could start vagrant fully every time, but couldn't halt it as noted in another issue I started.

Now I can't get it to start fully due to SSH connection issues. It seems to be some kind of problem with timing as the debug log looks like it's getting connected and the key works, but then vagrant keeps trying and starts failing.

None of the solutions mentioned so far have resolved this for me.

I'd like to help fix this and other SSH related issues on this project if I can be of any help.

If I kill the vagrant up process and try vagrant ssh, I get prompted for a root password. But since I'm using keys, there is no root password known at this time.
Checking the DO control panel, my public key is being copied up correctly and shows as "Vagrant"

Here's the log

with lots of the noise removed

On the first few tries, SSH isn't up. So it correctly fails.

 INFO ssh: Attempting to connect to SSH...
 INFO ssh:   - Host: 104.236.42.183
 INFO ssh:   - Port: 22
 INFO ssh:   - Username: root
 INFO ssh:   - Password? false
 INFO ssh:   - Key Path: ["/Users/shanegrey/.ssh/id_rsa"]
DEBUG ssh: == Net-SSH connection debug-level log START ==
DEBUG ssh: D, [2015-10-21T19:10:31.259126 #57084] DEBUG -- net.ssh.transport.session[8152e5dc]: establishing connection to 104.236.42.183:22

DEBUG ssh: == Net-SSH connection debug-level log END ==
 INFO ssh: SSH not up: 
Lots of debug info...

Then it is able to connect to SSH and tries the public key and apparently succeeds.

D, [2015-10-21T19:10:42.109726 #57084] DEBUG -- net.ssh.authentication.methods.publickey[804b3e64]: trying publickey (public key here)
Lots of debug info...

D, [2015-10-21T19:10:42.269501 #57084] DEBUG -- net.ssh.authentication.methods.publickey[804b3e64]: publickey succeeded (public key here)

But then for some reason it tries again and fails. And keeps failing in this way until I kill the process.

DEBUG ssh: == Net-SSH connection debug-level log END ==
 INFO ssh: SSH is ready!
 INFO ssh: Connection errored, not re-using. Will reconnect.
DEBUG ssh: #<Timeout::Error: execution expired>
Lots of debug info...

D, [2015-10-21T19:10:47.921219 #57084] DEBUG -- net.ssh.authentication.methods.publickey[80905864]: trying publickey (public key here)
E, [2015-10-21T19:10:47.976265 #57084] ERROR -- net.ssh.authentication.session[814faac0]: all authorization methods failed (tried none, publickey)

DEBUG ssh: == Net-SSH connection debug-level log END ==
 INFO retryable: Retryable exception raised: #<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.>

My vagrant file

Vagrant.configure('2') do |config|
  config.vm.box = 'digital_ocean'
  config.ssh.private_key_path = '~/.ssh/id_rsa'
  config.vm.provider :digital_ocean do |provider|
    provider.token = ENV['DO_TOKEN']
    provider.image = '14058541'
    provider.region = 'nyc3'
    provider.size = '1gb'
  end
end

@shanemgrey
Copy link
Contributor

More info.

I've tried to dig into this project code and find the cause of this, but ruby isn't a strong skill for me, and I haven't gotten to know the vagrant code base either. So I didn't find the cause, but I did find that changing my vagrant config makes it work or not.

This works:

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

  config.vm.provider :digital_ocean do |provider, override|
    override.ssh.private_key_path = '~/.ssh/id_rsa'
    override.vm.box = 'digital_ocean'
    override.vm.box_url = "https://github.com/smdahlen/vagrant-digitalocean/raw/master/box/digital_ocean.box"

    provider.token = ENV['DO_TOKEN']
    provider.image = 'ubuntu-14-04-x64'
    provider.region = 'nyc3'
    provider.size = '1gb'
  end
end

But change the provider.image to an image I made with packer from 14.04, and it no longer allows my ssh key to work.

So I suspect there is something wrong with my image as relates to the ssh key.

Any ideas why the base image works, but my image derived from a base doesn't?

@shanemgrey
Copy link
Contributor

Working on this a bit more and I found the source of the issue (for me, in this one case anyway) was that something was happening while using packer to provision a new image from a previously created one.

Without going into details on the packer issue, here in a vagrant repo, the cause of not being able to login with the SSH key wasn't that the key was wrong or missing. It was that something is changing the owner of the /root directory to www-data.

Everything below /root is still owned by the root user. But that base directory being owned by the apache user causes SSH to refuse to work because the ssh keys can be gotten to by the apache user, not just the root user. This is a good safety feature. I'm still not sure what's causing the ownership change though.

Fixing the issue manually requires getting a root password generated for the droplet, logging in as root, and issuing chown root:root /root

I'm hoping this helps someone else if you haven't found the solution yet with the other reasons for failure. If I can isolate the cause of the change, I'll add that here. Never the less, it seems in this case unrelated to vagrant or this plugin.

@tarellel
Copy link

tarellel commented Oct 2, 2016

I could be wrong but I believe this is the same issue as #244 seeing as how it was almost the exact same output I was receiving. I'm waiting for a response from the other commenters, but I believe I posted a solution. It has to do with DO's default accepted sshkeys.

You can view my comment/solution here.

@lpgn
Copy link

lpgn commented Mar 3, 2017

user should not be "root" it is "core"...

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests