I'm attempting to authorise but I keep getting this error: <div class="snippet-cli

GitHub ate my comment, but I essentially said: <div class="snippet-clipboard-conte

I tried both of these and got: <div class="snippet-clipboard-content notranslate p

tugboat dropblets gives: <div class="snippet-clip

<a class="user-mention notranslate" data-hovercard-type="user" data-hovercard-url="/us

If you're looking for a verbose SSL output, try this: <div class="snippet-clipboar

Unable to authorise about tugboat HOT 11 CLOSED

matt-oakes commented on May 20, 2024

Unable to authorise

from tugboat.

Comments (11)

pearkes commented on May 20, 2024

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

from tugboat.

matt-oakes commented on May 20, 2024

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?

from tugboat.

pearkes commented on May 20, 2024

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!

from tugboat.

matt-oakes commented on May 20, 2024

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?

from tugboat.

jdan commented on May 20, 2024

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

from tugboat.

matt-oakes commented on May 20, 2024

It returns /usr/bin/openssl

from tugboat.

pearkes commented on May 20, 2024

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

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

from tugboat.

pearkes commented on May 20, 2024

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

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

from tugboat.

matt-oakes commented on May 20, 2024

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.

from tugboat.

matt-oakes commented on May 20, 2024

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

Thanks for the help, and for the tool 👍

from tugboat.

pearkes commented on May 20, 2024

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

from tugboat.

Unable to authorise about tugboat HOT 11 CLOSED

Comments (11)

Related Issues (20)

Recommend Projects

React

Vue.js

Typescript

TensorFlow

Django

Laravel

D3

Recommend Topics

javascript

web

server

Machine learning

Visualization

Game

Recommend Org

Facebook

Microsoft

Google

Alibaba

D3

Tencent