[Capistrano] Re: Capistrano 2.0.0 => 2.1.0 no prompt for SSH password, non-root user can't run "cap" at all

[Jamis Buck]

On Oct 20, 2007, at 11:19 PM, Ron wrote:

some background info first:
I use capistrano-ext (1.2.0) to  set up staging and production
environments.  SSH runs on a non-standard port 2000.

I upgraded from 2.0.0 to 2.1.0 today.  Sadly, my deployment script is
broken.


First, I can't run capistrano as a non-root user any more.
cap help
/usr/bin/cap:16:in `load': no such file to load -- cap (LoadError)
from /usr/bin/cap:16

That sounds like a broken installation... do you have more than one version of Ruby installed, or Ruby installed in more than one place? You might try uninstalling cap and trying to reinstall.

When I run it as root user:
"cap staging deploy" complained about

connection failed for: localhost (Errno::ENOENT: No such file or
directory - /root/.ssh/id_rsa.pub)

Do you have ssh_options[:keys] specified somewhere in your deploy.rb? If so, make sure it specifies absolute paths and not relative paths to the key file(s).

I looked at http://gemtacular.com/gemdocs/capistrano-2.1.0/doc/ classes/Capistrano/SSH.html

and found out about ssh_options[:auth_methods]

so I added the following to deploy.rb:
ssh_options[:auth_methods] = %w(password keyboard-interactive)

the public key error is gone.

But I got the following error:
 ** [deploy:update_code] exception while rolling back:
Capistrano::ConnectionError, connection failed for: localhost
(Net::SSH::AuthenticationFailed: deployuser)
connection failed for: localhost (Net::SSH::AuthenticationFailed:
deployuser)


No SSH password prompt.

Are you setting the :password variable anywhere? If so, Capistrano will use that value rather than prompting, so make sure it is correct.

Please consider that they are lots of people depending on
Capistrano.   Breaking working deployment scripts will cause a lot of
grieves.

- Jamis

I understand problems like this can be frustrating, but also know that I did have a pre-release version of cap 2.1 available for a full month, and received only one problem report, which was tracked down to an issue with the remote server's OS. I do my best to ensure compatibility, but no one is perfect, especially if people aren't helping out by trying the preview releases (since I do not have access to more than a tiny tiny subset of the environments that people are deploying to).

smime.p7s
Description: S/MIME cryptographic signature