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

Unable to authorise #8

Closed
matt-oakes opened this issue Apr 15, 2013 · 11 comments
Closed

Unable to authorise #8

matt-oakes opened this issue Apr 15, 2013 · 11 comments

Comments

@matt-oakes
Copy link

I'm attempting to authorise but I keep getting this error:

report/latex git:(master) ✗ ± tugboat authorize                                                                                                                                                    19:20:26
Note: You can get this information from digitalocean.com/api_access

Enter your client key: <removed>
Enter your API key: <removed>
Enter your SSH key path (optional, defaults to ~/.ssh/id_rsa):
Enter your SSH user (optional, defaults to mattoakes): <removed>
Authentication with DigitalOcean failed. Run `tugboat authorize`

These values are defiantly correct and have no extra whitespace around them. I've tried installing the gem both as my normal user and also using sudo.

I'm running OS X 10.8.2, ruby 1.9.3p194 and gem 1.8.25. I've verified that I can access Digital Ocean by browsing to the website and pinging the from the command line.

Any ideas what I'm doing wrong?

@pearkes
Copy link
Collaborator

pearkes commented Apr 15, 2013

GitHub ate my comment, but I essentially said:

cat ~/.tugboat

Verify that's correct, and try regenerating your API key.

If you want to debug the "check" request, run this:

DEBUG=true tugboat authorize

@matt-oakes
Copy link
Author

I tried both of these and got:

report/latex git:(master) ✗ ± cat ~/.tugboat                                                                                                                                                       19:23:47
---
authentication:
  client_key: <removed>
  api_key: <removed>
ssh:
  ssh_user: <removed>
  ssh_key_path: /Users/mattoakes/.ssh/id_rsa
report/latex git:(master) ✗ ± DEBUG=true tugboat authorize                                                                                                                                         19:54:13
Note: You can get this information from digitalocean.com/api_access

Enter your client key: <removed>
Enter your API key: <removed>
Enter your SSH key path (optional, defaults to ~/.ssh/id_rsa):
Enter your SSH user (optional, defaults to mattoakes): <removed>
I, [2013-04-15T19:54:32.067432 #68014]  INFO -- : get https://api.digitalocean.com/droplets?client_id=<removed>&api_key=<removed>
D, [2013-04-15T19:54:32.067617 #68014] DEBUG -- request: User-Agent: "Faraday v0.8.7"
Authentication with DigitalOcean failed. Run `tugboat authorize`

Strangely when going to the url provided in the debug in my browser it returns fine with this JSON response:

{
    "status": "OK",
    "droplets": [
        {
            "id": 123456,
            "name": "512VPS",
            "image_id": 12345,
            "size_id": 63,
            "region_id": 2,
            "backups_active": null,
            "ip_address": "127.0.0.1",
            "status": "active"
        }
    ]
}

Obviously I've removed anything sensitive but it all seems to work fine when I use the browser.

Any other things I can do to debug this for you?

pearkes added a commit that referenced this issue Apr 15, 2013
Previously, we were catching everything in a lazy way. Now,
it only catches the exception related to Faraday parsing the response,
which in the case of DigitalOcean is this not authorized page.
@pearkes
Copy link
Collaborator

pearkes commented Apr 15, 2013

What does tugboat droplets show?

I just pushed something which should help with the authorize error. I wasn't being explicit with the exception to raise that error to the user, so perhaps something else happened there.

If you don't mind, could you clone this repo and then bundle and then bundle exec tugboat authorize and see if there's a change?

Appreciate the help!

@matt-oakes
Copy link
Author

tugboat dropblets gives:

~/tmp  ➜ tugboat droplets                                                                                                                                                                          21:12:28
/Users/mattoakes/.rvm/rubies/ruby-1.9.3-p194/lib/ruby/1.9.1/net/http.rb:799:in `connect': SSL_connect returned=1 errno=0 state=SSLv3 read server certificate B: certificate verify failed (Faraday::Error::ConnectionFailed)
<stacktrace removed - it's also below>

Looks like that's the problem, but not sure how to fix it.

The latest master gives this:

tmp/tugboat git:(master) ± bundle exec tugboat authorize                                                                                                                                           21:14:46
Note: You can get this information from digitalocean.com/api_access

Enter your client key: <removed>
Enter your API key: <removed>
Enter your SSH key path (optional, defaults to ~/.ssh/id_rsa):
Enter your SSH user (optional, defaults to mattoakes): <removed>
/Users/mattoakes/.rvm/rubies/ruby-1.9.3-p194/lib/ruby/1.9.1/net/http.rb:799:in `connect': SSL_connect returned=1 errno=0 state=SSLv3 read server certificate B: certificate verify failed (Faraday::Error::ConnectionFailed)
    from /Users/mattoakes/.rvm/rubies/ruby-1.9.3-p194/lib/ruby/1.9.1/net/http.rb:799:in `block in connect'
    from /Users/mattoakes/.rvm/rubies/ruby-1.9.3-p194/lib/ruby/1.9.1/timeout.rb:54:in `timeout'
    from /Users/mattoakes/.rvm/rubies/ruby-1.9.3-p194/lib/ruby/1.9.1/timeout.rb:99:in `timeout'
    from /Users/mattoakes/.rvm/rubies/ruby-1.9.3-p194/lib/ruby/1.9.1/net/http.rb:799:in `connect'
    from /Users/mattoakes/.rvm/rubies/ruby-1.9.3-p194/lib/ruby/1.9.1/net/http.rb:755:in `do_start'
    from /Users/mattoakes/.rvm/rubies/ruby-1.9.3-p194/lib/ruby/1.9.1/net/http.rb:744:in `start'
    from /Users/mattoakes/.rvm/rubies/ruby-1.9.3-p194/lib/ruby/1.9.1/net/http.rb:1284:in `request'
    from /Users/mattoakes/.rvm/rubies/ruby-1.9.3-p194/lib/ruby/1.9.1/net/http.rb:1026:in `get'
    from /Users/mattoakes/.rvm/gems/ruby-1.9.3-p194/gems/faraday-0.8.7/lib/faraday/adapter/net_http.rb:73:in `perform_request'
    from /Users/mattoakes/.rvm/gems/ruby-1.9.3-p194/gems/faraday-0.8.7/lib/faraday/adapter/net_http.rb:38:in `call'
    from /Users/mattoakes/.rvm/gems/ruby-1.9.3-p194/gems/faraday_middleware-0.9.0/lib/faraday_middleware/response_middleware.rb:30:in `call'
    from /Users/mattoakes/.rvm/gems/ruby-1.9.3-p194/gems/faraday-0.8.7/lib/faraday/response.rb:8:in `call'
    from /Users/mattoakes/.rvm/gems/ruby-1.9.3-p194/gems/faraday-0.8.7/lib/faraday/request/url_encoded.rb:14:in `call'
    from /Users/mattoakes/.rvm/gems/ruby-1.9.3-p194/gems/digital_ocean-1.0.1/lib/digital_ocean/authentication_middleware.rb:18:in `call'
    from /Users/mattoakes/.rvm/gems/ruby-1.9.3-p194/gems/faraday-0.8.7/lib/faraday/connection.rb:247:in `run_request'
    from /Users/mattoakes/.rvm/gems/ruby-1.9.3-p194/gems/faraday-0.8.7/lib/faraday/connection.rb:100:in `get'
    from /Users/mattoakes/.rvm/gems/ruby-1.9.3-p194/gems/digital_ocean-1.0.1/lib/digital_ocean/resource/droplet.rb:6:in `list'
    from /Users/mattoakes/tmp/tugboat/lib/tugboat/middleware/check_credentials.rb:11:in `call'
    from /Users/mattoakes/tmp/tugboat/lib/tugboat/middleware/inject_client.rb:14:in `call'
    from /Users/mattoakes/tmp/tugboat/lib/tugboat/middleware/check_configuration.rb:13:in `call'
    from /Users/mattoakes/tmp/tugboat/lib/tugboat/middleware/inject_configuration.rb:11:in `call'
    from /Users/mattoakes/tmp/tugboat/lib/tugboat/middleware/ask_for_credentials.rb:16:in `call'
    from /Users/mattoakes/tmp/tugboat/lib/tugboat/middleware/inject_configuration.rb:11:in `call'
    from /Users/mattoakes/.rvm/gems/ruby-1.9.3-p194/gems/middleware-0.1.0/lib/middleware/runner.rb:31:in `call'
    from /Users/mattoakes/.rvm/gems/ruby-1.9.3-p194/gems/middleware-0.1.0/lib/middleware/builder.rb:102:in `call'
    from /Users/mattoakes/tmp/tugboat/lib/tugboat/cli.rb:32:in `authorize'
    from /Users/mattoakes/.rvm/gems/ruby-1.9.3-p194/gems/thor-0.18.1/lib/thor/command.rb:27:in `run'
    from /Users/mattoakes/.rvm/gems/ruby-1.9.3-p194/gems/thor-0.18.1/lib/thor/invocation.rb:120:in `invoke_command'
    from /Users/mattoakes/.rvm/gems/ruby-1.9.3-p194/gems/thor-0.18.1/lib/thor.rb:363:in `dispatch'
    from /Users/mattoakes/.rvm/gems/ruby-1.9.3-p194/gems/thor-0.18.1/lib/thor/base.rb:439:in `start'
    from /Users/mattoakes/tmp/tugboat/bin/tugboat:4:in `<top (required)>'
    from /Users/mattoakes/.rvm/gems/ruby-1.9.3-p194/bin/tugboat:23:in `load'
    from /Users/mattoakes/.rvm/gems/ruby-1.9.3-p194/bin/tugboat:23:in `<main>'

It's the same error as above but I didn't include the full stack trace in the first instance.

A quick google gives this as an answer from StackOverflow and this is the reference it gives for fixing it on OS X.

I've had a look through your code and it seem to hand off all the actual HTTP stuff to the digital_ocean gem but (with my limited ruby knowledge) then hands it off to Faraday. By the looks of it that's a pretty weel used HTTP library which shouldn't have a problem with root CAs. Everything seems to be at the latest stable versions.

I've not got enough specific knowledge of ruby to figure out where the problem is coming in between all these gems. Any ideas?

@jdan
Copy link

jdan commented Apr 15, 2013

@matto1990 does which openssl return /usr/bin/openssl or some RVM path?

@matt-oakes
Copy link
Author

It returns /usr/bin/openssl

@pearkes
Copy link
Collaborator

pearkes commented Apr 16, 2013

Can you try curling https://www.digitalocean.com?

I've seen a similar issue with SSL. Check out this Twitter thread.

@pearkes
Copy link
Collaborator

pearkes commented Apr 16, 2013

If you're looking for a verbose SSL output, try this:

curl -vv https://www.digitalocean.com

@matt-oakes
Copy link
Author

The curl command works fine both on the homepage URL and the api.digitalocean.com url. I wont post the log because it's all normal.

@matt-oakes
Copy link
Author

Following this guide fixed the problem. It was something wrong with my install, not your program.

Thanks for the help, and for the tool 👍

@pearkes
Copy link
Collaborator

pearkes commented Apr 16, 2013

Great to hear Matt. Glad you brought it up here so other people can find it.

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

3 participants