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

Already on GitHub? Sign in to your account

Deployment from Git on HTTPS fails to use credentials #384

Closed
ain opened this Issue Feb 12, 2013 · 23 comments

Comments

Projects
None yet
3 participants
Contributor

ain commented Feb 12, 2013

The below deploy.rb works, but prompts for username and password twice ignoring scm_username and scm_password:

require "bundler/capistrano"

set :application, "AppName"

set :scm_username, "username"
set :scm_password, "password"
set :scm, :git
set :branch, "master"

set :repository,  "https://repo-url.de:4442/git/repo.git"

set :deploy_via, "copy"
set :copy_cache, false
set :copy_exclude, [".git*", ".DS_Store", "nbproject"]

ssh_options[:forward_agent] = true
set :use_sudo, false
set :keep_releases, 5

task :production do
  set :user, "user"
  set :password, "passwd"
  set :deploy_to, "/var/www/passenger-site.de"
  role :web, "passenger-site.de"
  role :app, "passenger-site.de"
  role :db,  "passenger-site.de", :primary => true
  ssh_options[:port] = 2222
  set :env, "production"
end

namespace :deploy do

  task :restart, :roles => :app, :except => { :no_release => true } do
    run "cd #{current_path}; bundle exec rake assets:precompile"
    run "touch #{File.join(current_path,'tmp','restart.txt')}"
  end

end

ruby 1.8.7 (2012-10-12 patchlevel 371) [i686-darwin11]
Capistrano v2.12.0

Owner

leehambley commented Mar 25, 2013

No output logs?

Owner

leehambley commented Mar 25, 2013

You should use the method user@password:your-host.de:4222 - Git doesn't like giving http credentials.

Contributor

ain commented Mar 25, 2013

Yeah, that worked, but only for passwords that have no special characters :(

And of course the format would then have to be user:password@your-host.de:4442

Owner

leehambley commented Mar 25, 2013

Unfortunately this is a problem of the way Git does authentication for
HTTPS repositories, it's not possible to pass username or password on the
CLI. But we could wrap something with an expect (man 1 expect) or similar
script, or try to provide an GIT_ASKPASS program that would do the same; we
have the same problems with the WIP hosted webbased Capistrano solution
we're developing internally.

Lee Hambley

http://lee.hambley.name/

On 25 March 2013 11:42, Ain Tohvri notifications@github.com wrote:

Yeah, that worked, but only for passwords that have no special characters
:(


Reply to this email directly or view it on GitHubhttps://github.com/capistrano/capistrano/issues/384#issuecomment-15386580
.

Contributor

ain commented Mar 25, 2013

Yup. I'm using HTTPS over the auth framework and repo management. Also many of the SVN deployments I'm about to migrate over to Git did work seamlessly over HTTPS, would be nice to use more or less the same logic also for Git.

Let me know if there's anything I could test for you, I've got quite a few test-cases that use Capistrano across Rails and Symfony projects at slightly varying configurations and additional recipes.

Owner

leehambley commented Mar 25, 2013

Hey, that's very much appreciated. You might look at finding a reliable way
to make https authentication with Git /never/ prompt, but always accept
something from the environment.

( I wasn't successful ) - for an internal can I reach this repository
script, I had to do something like this:

env -i GIT_TRACE=1 GIT_ASKPASS=/bin/echo SSH_ASKPASS=/bin/echo git
ls-remote

Ugly, but with that I was able to verify if the repository was accessible
by inline username:password - or via ssh with keys (according to
~/.ssh/config)

I might point out that in order to use Github with https, you have to have
a password with no special characters, or configure the credential helper (
https://github.com/pah/git-credential-helper) in advance, or use your OAuth
token (
https://github.com/blog/1270-easier-builds-and-deployments-using-git-over-https-and-oauth
)

It seems like Git over https is a bit of an after thought, behind their
native protocol and native over ssh. I'd like to find a neat solution,
though. (without resorting to setting git config options in order to
perform the clone/command and then unsetting them)

Grab me on Skype/IRC and we can have a look at it? Or we can keep working
here, I'm fine either way.

Lee Hambley

http://lee.hambley.name/

On 25 March 2013 14:15, Ain Tohvri notifications@github.com wrote:

Yup. I'm using HTTPS over the auth framework and repo management. Also
many of the SVN deployments I'm about to migrate over to Git did work
seamlessly over HTTPS, would be nice to use more or less the same logic
also for Git.

Let me know if there's anything I could test for you, I've got quite a few
test-cases that use Capistrano across Rails and Symfony projects at
slightly varying configurations and additional recipes.


Reply to this email directly or view it on GitHubhttps://github.com/capistrano/capistrano/issues/384#issuecomment-15392370
.

Owner

leehambley commented Apr 2, 2013

Feedback? I'm closing here pending a bit more discussion.

@leehambley leehambley closed this Apr 2, 2013

@leehambley leehambley reopened this Jun 7, 2013

Contributor

ain commented Jun 12, 2013

I've been trying to use Cap 3 to test it, but no success. Is it ready to be used or still work in progress?

The problem is the documentation, i.e. getting the connection to the stage doesn't seem to work for me, e.g.

server 'server.de', roles: %w{web app db}, port: 2222, keys: [File.join(ENV["HOME"], ".ssh", "id_rsa")]

Trace:

** Invoke staging (first_time)
** Execute staging
** Invoke deploy (first_time)
** Execute deploy
** Invoke deploy:starting (first_time)
** Invoke deploy:ensure_stage (first_time)
** Execute deploy:ensure_stage
** Execute deploy:starting
** Invoke deploy:started (first_time)
** Execute deploy:started
** Invoke deploy:check (first_time)
** Execute deploy:check
** Invoke git:check (first_time)
** Invoke git:wrapper (first_time)
** Execute git:wrapper
cap aborted!
Connection refused - connect(2)
/Users/ain/.rvm/gems/ruby-2.0.0-p195/gems/net-ssh-2.6.7/lib/net/ssh/transport/session.rb:67:in `initialize'
/Users/ain/.rvm/gems/ruby-2.0.0-p195/gems/net-ssh-2.6.7/lib/net/ssh/transport/session.rb:67:in `open'
/Users/ain/.rvm/gems/ruby-2.0.0-p195/gems/net-ssh-2.6.7/lib/net/ssh/transport/session.rb:67:in `block in initialize'
/Users/ain/.rvm/rubies/ruby-2.0.0-p195/lib/ruby/2.0.0/timeout.rb:52:in `timeout'
/Users/ain/.rvm/rubies/ruby-2.0.0-p195/lib/ruby/2.0.0/timeout.rb:97:in `timeout'
/Users/ain/.rvm/gems/ruby-2.0.0-p195/gems/net-ssh-2.6.7/lib/net/ssh/transport/session.rb:67:in `initialize'
/Users/ain/.rvm/gems/ruby-2.0.0-p195/gems/net-ssh-2.6.7/lib/net/ssh.rb:192:in `new'
/Users/ain/.rvm/gems/ruby-2.0.0-p195/gems/net-ssh-2.6.7/lib/net/ssh.rb:192:in `start'
/Users/ain/.rvm/gems/ruby-2.0.0-p195/gems/sshkit-0.0.25/lib/sshkit/backends/netssh.rb:124:in `ssh'
/Users/ain/.rvm/gems/ruby-2.0.0-p195/gems/sshkit-0.0.25/lib/sshkit/backends/netssh.rb:42:in `upload!'
/Users/ain/.rvm/gems/ruby-2.0.0-p195/gems/capistrano-3.0.0.pre3/lib/capistrano/tasks/git.rake:11:in `block (3 levels) in '
/Users/ain/.rvm/gems/ruby-2.0.0-p195/gems/sshkit-0.0.25/lib/sshkit/backends/netssh.rb:16:in `instance_exec'
/Users/ain/.rvm/gems/ruby-2.0.0-p195/gems/sshkit-0.0.25/lib/sshkit/backends/netssh.rb:16:in `run'
/Users/ain/.rvm/gems/ruby-2.0.0-p195/gems/sshkit-0.0.25/lib/sshkit/runners/parallel.rb:29:in `block (2 levels) in execute'
Tasks: TOP => git:check => git:wrapper
Owner

leehambley commented Jun 12, 2013

I've never tested it with that combination of arguments, any of these
issues that come up, if you can post a stack trace, you would help me
immensely. Right now Tom (@seenmyfate) and I are using Cap3 in a few
different projects with a lot of success, but more use-cases, and more eyes
are always important!

Lee Hambley

http://lee.hambley.name/
+49 (0) 170 298 5667

On 12 June 2013 17:23, Ain Tohvri notifications@github.com wrote:

I've been trying to use Cap 3 to test it, but no success. Is it ready to
be used or still a work in progress?

The problem is the documentation, i.e. getting the connection to the stage
doesn't seem to work for me, e.g.

server 'server.de', roles: %w{web app db}, port: 2222, keys:
[File.join(ENV["HOME"], ".ssh", "id_rsa")]


Reply to this email directly or view it on GitHubhttps://github.com/capistrano/capistrano/issues/384#issuecomment-19333198
.

Contributor

ain commented Jun 13, 2013

Could you post a sample config for v3?

Owner

leehambley commented Jun 13, 2013

The simplest thing that works, for me at least is:

Desktop  cap uptime
Password:
 INFO leehambley@localhost:22 has uptime 9:18  up 1 day, 17:39, 1 user, load averages: 0.79 0.97 1.13Desktop  cat Capfile
require 'capistrano/setup'

server 'localhost'

task :uptime do
  on roles(:all) do |host|
    info "#{host} has uptime #{capture(:uptime)}"
  end
end
Owner

leehambley commented Jun 13, 2013

And a second log with a remote server, just to prove that it's not a localhost fluke:

Desktop  grep -A3 "Host harrow" ~/.ssh/config
Host harrow
User <not so fast!>
HostName 78.46.106.75Desktop  cat Capfile
require 'capistrano/setup'

server 'harrow'

task :uptime do
  on roles(:all) do |host|
    info "#{host} has uptime #{capture(:uptime)}"
  end
endDesktop  !cap
➜  Desktop  cap uptime --trace --verbose
** Invoke uptime (first_time)
** Execute uptime
 INFO leehambley@harrow:22 has uptime 09:21:01 up 50 days, 14:41,  0 users,  load average: 0.08, 0.05, 0.05
Contributor

ain commented Jun 13, 2013

As you can see from the log, it fails on git:wrapper. What's happening there? Are you uploading to /tmp… on the remote?

ain$ sudo cap staging deploy --trace
/Users/ain/.rvm/gems/ruby-2.0.0-p195/gems/sshkit-0.0.25/lib/sshkit.rb:3: warning: already initialized constant SSHKit::StandardError
/Users/ain/.rvm/rubies/ruby-2.0.0-p195/lib/ruby/gems/2.0.0/gems/sshkit-0.0.25/lib/sshkit.rb:3: warning: previous definition of StandardError was here
** Invoke staging (first_time)
** Execute staging
** Invoke deploy (first_time)
** Execute deploy
** Invoke deploy:starting (first_time)
** Invoke deploy:ensure_stage (first_time)
** Execute deploy:ensure_stage
** Execute deploy:starting
** Invoke deploy:started (first_time)
** Execute deploy:started
** Invoke deploy:check (first_time)
** Execute deploy:check
** Invoke git:check (first_time)
** Invoke git:wrapper (first_time)
** Execute git:wrapper
cap aborted!
Connection refused - connect(2)
/Users/ain/.rvm/rubies/ruby-2.0.0-p195/lib/ruby/gems/2.0.0/gems/net-ssh-2.6.7/lib/net/ssh/transport/session.rb:67:in `initialize'
/Users/ain/.rvm/rubies/ruby-2.0.0-p195/lib/ruby/gems/2.0.0/gems/net-ssh-2.6.7/lib/net/ssh/transport/session.rb:67:in `open'
/Users/ain/.rvm/rubies/ruby-2.0.0-p195/lib/ruby/gems/2.0.0/gems/net-ssh-2.6.7/lib/net/ssh/transport/session.rb:67:in `block in initialize'
/Users/ain/.rvm/rubies/ruby-2.0.0-p195/lib/ruby/2.0.0/timeout.rb:52:in `timeout'
/Users/ain/.rvm/rubies/ruby-2.0.0-p195/lib/ruby/2.0.0/timeout.rb:97:in `timeout'
/Users/ain/.rvm/rubies/ruby-2.0.0-p195/lib/ruby/gems/2.0.0/gems/net-ssh-2.6.7/lib/net/ssh/transport/session.rb:67:in `initialize'
/Users/ain/.rvm/rubies/ruby-2.0.0-p195/lib/ruby/gems/2.0.0/gems/net-ssh-2.6.7/lib/net/ssh.rb:192:in `new'
/Users/ain/.rvm/rubies/ruby-2.0.0-p195/lib/ruby/gems/2.0.0/gems/net-ssh-2.6.7/lib/net/ssh.rb:192:in `start'
/Users/ain/.rvm/gems/ruby-2.0.0-p195/gems/sshkit-0.0.25/lib/sshkit/backends/netssh.rb:124:in `ssh'
/Users/ain/.rvm/gems/ruby-2.0.0-p195/gems/sshkit-0.0.25/lib/sshkit/backends/netssh.rb:42:in `upload!'
/Users/ain/.rvm/rubies/ruby-2.0.0-p195/lib/ruby/gems/2.0.0/gems/capistrano-3.0.0.pre3/lib/capistrano/tasks/git.rake:11:in `block (3 levels) in '
/Users/ain/.rvm/gems/ruby-2.0.0-p195/gems/sshkit-0.0.25/lib/sshkit/backends/netssh.rb:16:in `instance_exec'
/Users/ain/.rvm/gems/ruby-2.0.0-p195/gems/sshkit-0.0.25/lib/sshkit/backends/netssh.rb:16:in `run'
/Users/ain/.rvm/gems/ruby-2.0.0-p195/gems/sshkit-0.0.25/lib/sshkit/runners/parallel.rb:29:in `block (2 levels) in execute'
Tasks: TOP => git:check => git:wrapper
Owner

seenmyfate commented Jun 13, 2013

Could this be caused by SSHKit defaulting to port 22? I think in the current implementation it will only be parsed as part of the host string - server 'server.de:2222', roles: %w{web app db}

Owner

leehambley commented Jun 13, 2013

Entirely possible Tom.

Yes we do upload to /tmp, is that a problem?

On Thursday, June 13, 2013, Tom Clements wrote:

Could this be caused by SSHKit defaulting to port 22? I think in the
current implementation it will only be parsed as part of the host string - server
'server.de:2222', roles: %w{web app db}


Reply to this email directly or view it on GitHubhttps://github.com/capistrano/capistrano/issues/384#issuecomment-19386488
.

Lee Hambley

http://lee.hambley.name/
+49 (0) 170 298 5667

Contributor

ain commented Jun 13, 2013

I still get the above trace and Connection refused even with the port in the host string. Since it's a key-based auth, I'm afraid the problem is there. On old Cap 2 deploy I always defined the keys with [File.join(ENV["HOME"], ".ssh", "id_rsa_wtmh")].

Owner

leehambley commented Jun 13, 2013

Sshkit is the driver for cap

On Thursday, June 13, 2013, Ain Tohvri wrote:

Maybe I've been misleading you, but I'm trying to deploy over HTTPS, now
in latest Cap 3. How is SSHKit involved in that?


Reply to this email directly or view it on GitHubhttps://github.com/capistrano/capistrano/issues/384#issuecomment-19389206
.

Lee Hambley

http://lee.hambley.name/
+49 (0) 170 298 5667

Contributor

ain commented Jun 13, 2013

Ok so it seems the failure is in making a connection on a non-standard port with a key. I set the port in server and also adjusted SSH config to point to the identity:

Host server.de
User deployer
IndentityFile ~/.ssh/id_rsa_wtmh

but it's not picking it up, the result is the same as in the above trace, Connection refused.

Owner

leehambley commented Jun 13, 2013

Great, thanks for the input Ain, Tom and I both dedicate Fridays to cap so
this is near perfect timing, expect a fix vvveeerrryy soon

On Thursday, June 13, 2013, Ain Tohvri wrote:

Ok so it seems the failure is in making a connection on a non-standard
port with a key. I set the port in server and also adjusted SSH config to
point to the identity:

Host server.de
User deployer
IndentityFile ~/.ssh/id_rsa_wtmh

but it's not picking it up, the result is the same as in the above trace, Connection
refused.


Reply to this email directly or view it on GitHubhttps://github.com/capistrano/capistrano/issues/384#issuecomment-19390079
.

Lee Hambley

http://lee.hambley.name/
+49 (0) 170 298 5667

Contributor

ain commented Jun 13, 2013

NB! v3 label also applies to this topic, the latter part of it at least :)

@seenmyfate seenmyfate added a commit that referenced this issue Jun 14, 2013

@seenmyfate seenmyfate Support setting of SSHKit::Host variables
Variables passed to the `server` or `role` syntax are correctly
assigned on the SSHKit::Host instance:

    server 'example1.com', roles: %w{web app}, user: 'tomc', port: 2222
    server 'example2.com', roles: %w{web app}, keys: '~/.ssh/key'

Expect this to close issue #384
5d2fb93
Owner

seenmyfate commented Jun 14, 2013

@ain this last commit combined with the latest version of SSHKit will now correctly set the variables passed in port and key/keys - hopefully this will resolve your issue, please let me know how you get on

Contributor

ain commented Jun 14, 2013

Connection is fine now!

Tested with a privileged user (no keys) and deployment user (keys) of limited privileges, on a non-standard port, connection was successful on both.

I've split the further issue I'm having to #507.

Owner

leehambley commented Jun 14, 2013

Whoohoo great, serves me right for reading emails in chronological order, great news guys!

@leehambley leehambley closed this Oct 7, 2013

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment