Skip to content

Deploy fails when using password authentication method (capistrano 3 doesn't ask for password) #714

Closed
rocketblr opened this Issue Oct 17, 2013 · 10 comments

7 participants

@rocketblr

Hi,

I am not sure whether it is an issue or I am doing something wrong. Anyway, below are my ssh settings which are not working:

server "X.X.X.X", roles: %{web app db}, ssh_options: {
    user: "user",
    forward_agent: true,
    auth_methods: %w(password)
}

Deploy fails on git:wrapper task. See trace:

guzarevicha@guzarevicha-H87M-D3H:~/projects/app$ cap production deploy --trace
** Invoke production (first_time)
** Execute production
** Invoke load:defaults (first_time)
** Execute load:defaults
** Invoke deploy (first_time)
** Execute deploy
** Invoke deploy:starting (first_time)
** Invoke deploy:set_shared_assets (first_time)
** Execute deploy:set_shared_assets
** Execute deploy:starting
** Invoke deploy:check (first_time)
** Execute deploy:check
** Invoke git:check (first_time)
** Invoke git:wrapper (first_time)
** Execute git:wrapper
cap aborted!
user
/home/guzarevicha/.rvm/gems/ruby-2.0.0-p247@app/gems/net-ssh-2.7.0/lib/net/ssh.rb:215:in `start'
/home/guzarevicha/.rvm/gems/ruby-2.0.0-p247@app/gems/sshkit-1.1.0/lib/sshkit/backends/netssh.rb:156:in `ssh'
/home/guzarevicha/.rvm/gems/ruby-2.0.0-p247@app/gems/sshkit-1.1.0/lib/sshkit/backends/netssh.rb:68:in `upload!'
/home/guzarevicha/.rvm/gems/ruby-2.0.0-p247@app/gems/capistrano-3.0.0/lib/capistrano/tasks/git.rake:11:in `block (3 levels) in '
/home/guzarevicha/.rvm/gems/ruby-2.0.0-p247@app/gems/sshkit-1.1.0/lib/sshkit/backends/netssh.rb:42:in `instance_exec'
/home/guzarevicha/.rvm/gems/ruby-2.0.0-p247@app/gems/sshkit-1.1.0/lib/sshkit/backends/netssh.rb:42:in `run'
/home/guzarevicha/.rvm/gems/ruby-2.0.0-p247@app/gems/sshkit-1.1.0/lib/sshkit/runners/parallel.rb:12:in `block (2 levels) in execute'

If you add password password: "password", it will work. However I don't think that it is a good idea to push password into a repository.

Am I missing something? Or is it a bug?

@kirs
Capistrano member
kirs commented Oct 17, 2013

It's not a good idea to use password auth generally. Just add your public key on the server and use it without password.

@rocketblr

@kirs Yes, I know. But the question is still on. Capistrano 2 worked perfectly asking password when deploying. Now it fails with a non-informative message.

@damphyr
damphyr commented Oct 18, 2013

@kirs and in the cases where the server is not yet setup for passwordless authentication you don't really have much choice but to do it manually. With Cap2 we always had a task to setup passwordless authentication.
Much cleaner, especially when you have many new servers.
This is something I would put in the provisioning stage nowadays (e.g. in the Chef scripts) but in some cases Chef is overkill and a simple cap task will do the job.
The silent "death" when the password is missing is something we should change pronto though.

@excid3
excid3 commented Oct 28, 2013

I'm having the same trouble with password authentication.

@leehambley
Capistrano member

If you really, really want to use passwords, here's a tip: don't. Passwords are easy to share, easy to crash, hard to revoke, and easy to lose.

If you are certain that you want to do things so incorrectly, and unprofessionally as to risk being breached because you are too lazy to set up SSH keys (sorry if I'm being harsh, but damn.)

then the following:

server "X.X.X.X", roles: %{web app db}, ssh_options: {
    user: "user",
    forward_agent: true,
    auth_methods: %w(password)
}

Needs to include a password: "idontgiveadamnaboutsecurity" key in the hash (along side ssh_options, not in it.)

@leehambley leehambley closed this Oct 28, 2013
@leehambley
Capistrano member

If you add password password: "password", it will work. However I don't think that it is a good idea to push password into a repository.

It's an even worse idea to use passwords to log onto servers in 2013 with the prevalence of high speed password cracking tools, even if you use denyhosts and a restrictive rate limiting firewall, etc, etc - passwords, and root login should be disabled.

It was intentionally made difficult to do this, because I believe so firmly that it's a stupid idea. For throw away toy scripts the password:"mysecret" is supported, but it shouldn't be a part of your professional tool kit.

For an easy guide on how to set up SSH to not get owned: http://lani78.wordpress.com/2008/08/08/generate-a-ssh-key-and-disable-password-authentication-on-ubuntu-server/

@excid3
excid3 commented Oct 28, 2013

Haha fair enough, I was just setting things up to test against a local VM that's never going to be exposed to the public.

And for anyone else who wants to do this, use an ENV variable so you don't have to store the password in the source.

@leehambley
Capistrano member
@joxxoxo
joxxoxo commented Dec 4, 2013

We can set ENV variables which I don't like as it will be saved in some env file (like .bashrc) or in command line history.

Also we can ask user for password almost like it was earlier (almost cuz I'm unable to find similar to 'CLI ask password'):

set :password, ask('Server password:', nil)
server '', user: 'user', password: fetch(:password), roles: %w{web app db}

But the thing is there's no message like

"Unable to connect to the server XXX as UUU"

or something, and you have to look at the backtrace carefully, open gem sources, etc.
Which is just inconvenient.

@russellsilva

The silent "death" when the password is missing is something we should change pronto though.

I'm using Capistrano 3.1.0. The error message originally reported in this ticket, which gives no clear indication as to what the problem is, has not changed. Is this something that can be updated so that the error message is more helpful?

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Something went wrong with that request. Please try again.