Valid Password entered in capistrano does not work

151 views
Skip to first unread message

byrnejb

unread,
Dec 2, 2013, 4:21:02 PM12/2/13
to capis...@googlegroups.com
Problem: User logon fails when correct password entered.

I have verified that the password in use works via logging on in a terminal session with the user id given below in the log.  However, inputting this password into the Capistrano-2.5.15 recipe using:

# You can bailout here with ^C (<ctrl-c>)
set( :scm_password, 
      proc{Capistrano::CLI.password_prompt(
        "#{scm_user}@#{scm_server} password: ")} )


Results in this error being logged on the target host and generates the console reproduced below:

Failed password for theheart_test from 216.185.71.241 port 44678 ssh2

Is there some issue with respect to the version of ssh being used?  Is some trailing character being added to the password from the input method?

Versions:
  • Ruby-2.0.0p353
  • Capistrano-2.5.15
  • Rake-10.1.0 / Rails-4.0.1 / etc
Platform:
  • Working on....i86_64 CentOS-6.4
  • Deploying to...i86_64 CentOS-6.4
Logs:

 ** [xnet241.hamilton.harte-lyne.ca :: out] !!Warning!! -    Any attempt to obtain access to this device without
 ** authorisation is a criminal act.
 ** thehea...@vcs-git.hamilton.harte-lyne.ca's password:
thehea...@vcs-git.hamilton.harte-lyne.ca password:
 ** [xnet241.hamilton.harte-lyne.ca :: out]
 ** [xnet241.hamilton.harte-lyne.ca :: out] Permission denied, please try again.
 ** thehea...@vcs-git.hamilton.harte-lyne.ca's password:
 ** [xnet241.hamilton.harte-lyne.ca :: out]
 ** [xnet241.hamilton.harte-lyne.ca :: out] Permission denied, please try again.
 ** thehea...@vcs-git.hamilton.harte-lyne.ca's password:
 ** [xnet241.hamilton.harte-lyne.ca :: out]
 ** [xnet241.hamilton.harte-lyne.ca :: out] Permission denied (publickey,password).
 ** [xnet241.hamilton.harte-lyne.ca :: out] fatal: The remote end hung up unexpectedly
    command finished in 11745ms
*** [deploy:update_code] rolling back
  * executing "rm -rf /var/data/hll_th_test/hll_th_forex_rss/releases/20131202192645; true"
    servers: ["xnet241.hamilton.harte-lyne.ca"]
    [xnet241.hamilton.harte-lyne.ca] executing command
    command finished in 93ms

Donovan Bray

unread,
Dec 2, 2013, 5:22:53 PM12/2/13
to capis...@googlegroups.com
That's a peculiar invocation, use a debugger to make sure :scm_password is set the way you think it is.

Or try:

set(:scm_password) { Capistrano::CLI.password_prompt("#{scm_user}@#{scm_server} password: ")}

byrnejb

unread,
Dec 2, 2013, 9:00:48 PM12/2/13
to capis...@googlegroups.com


On Monday, 2 December 2013 17:22:53 UTC-5, dbray wrote:
That's a peculiar invocation, use a debugger to make sure :scm_password is set the way you think it is.

Or try:

set(:scm_password) { Capistrano::CLI.password_prompt("#{scm_user}@#{scm_server} password: ")}

The form you suggested gives exactly the same behaviour as the one we were already using.

I have also verified that the contents of scm_password is indeed the same as what is input.  I even replaced the block prompt assignment with a string literal:

  set( :scm_password, "the_actual_password" )

and got exactly the same results.

The error string looks like this:
failed: "env HLL_DB_ENV=production PATH=$HOME/.rbenv/shims:$HOME/.rbenv/bin:$PATH RAILS_ENV=production sh -c 'git clone -q -b ForEx-Deploy-V.04.000.0000rc1 ssh://thehea...@vcs-git.hamilton.harte-lyne.ca/var/data/vcs-git/hll/hll_th_forex_rss.git /var/data/hll_th_test/hll_th_forex_rss/releases/20131203013423 && cd /var/data/hll_th_test/hll_th_forex_rss/releases/20131203013423 && git checkout -q -b deploy 4a2be6f366c5bb31205713cc73a04a5996c8ed11 && (echo 4a2be6f366c5bb31205713cc73a04a5996c8ed11 > /var/data/hll_th_test/hll_th_forex_rss/releases/20131203013423/REVISION)'" on xnet241.hamilton.harte-lyne.ca

If I run the sh -c command directly on the host that I am running cap deploy from I get no error and everything is created as expected:

sh -c 'git clone -q -b ForEx-Deploy-V.04.000.0000rc1 ssh://thehea...@vcs-git.hamilton.harte-lyne.ca/var/data/vcs-git/hll/hll_th_forex_rss.git /var/data/hll_th_test/hll_th_forex_rss/releases/20131203013423 && cd /var/data/hll_th_test/hll_th_forex_rss/releases/20131203013423 && git checkout -q -b deploy 4a2be6f366c5bb31205713cc73a04a5996c8ed11 && (echo 4a2be6f366c5bb31205713cc73a04a5996c8ed11 > /var/data/hll_th_test/hll_th_forex_rss/releases/20131203013423/REVISION)'

I have tried this with set( :deploy_via, "checkout" ) and  set( :deploy_via, "remote_cache" ) and both generate the same logon errors.  The failed instructions for both, although different from each other, work perfectly when executed from the user shell on the deployment host.

This has to be an ssh issue of some sort.   Is there any way to get the -v switch passed to ssh as used by Capistrano?



Donovan Bray

unread,
Dec 3, 2013, 12:02:48 AM12/3/13
to capis...@googlegroups.com
what happens when you run this on the host xnet241.hamilton.harte-lyne.ca instead of your deploy host.


--
You received this message because you are subscribed to the Google Groups "Capistrano" group.
To unsubscribe from this group and stop receiving emails from it, send an email to capistrano+...@googlegroups.com.
To view this discussion on the web, visit https://groups.google.com/d/msgid/capistrano/7efb9ac8-35b4-41d8-8122-90644419508e%40googlegroups.com.

For more options, visit https://groups.google.com/groups/opt_out.

James B. Byrne

unread,
Dec 3, 2013, 9:07:22 AM12/3/13
to capis...@googlegroups.com

On Tue, December 3, 2013 00:02, Donovan Bray wrote:
> what happens when you run this on the host
> xnet241.hamilton.harte-lyne.ca instead
> of your deploy host.
>

xnet241 IS the deploy host.


--
*** E-Mail is NOT a SECURE channel ***
James B. Byrne mailto:Byr...@Harte-Lyne.ca
Harte & Lyne Limited http://www.harte-lyne.ca
9 Brockley Drive vox: +1 905 561 1241
Hamilton, Ontario fax: +1 905 561 0757
Canada L8E 3C3

byrnejb

unread,
Dec 3, 2013, 2:50:30 PM12/3/13
to capis...@googlegroups.com
I have gone back to the original deploy.rb recipe and the problem is with whatever capistrano is using for the scm password to log onto the git host:  I see this in the log files on that host:


Dec  3 14:45:21 inet09 unix_chkpwd[2813]: password check failed for user (theheart)
Dec  3 14:45:23 inet09 sshd[2734]: Failed password for theheart from 216.185.71.241 port 44926 ssh2

I have confirmed that providing the password via the login command on that host works and that the same password is now hard-coded into the deploy.rb file.  So, the only remaining question is what format is Capistrano using to encrypt the password before sending it to the remote host.  Our systems run CentOS-6, an RHEL6 rebuild.  Is there something special about CentOS logins?




Lee Hambley

unread,
Dec 3, 2013, 2:59:28 PM12/3/13
to capistrano

There is no *encrypting* you should give SSH keys a shot.

Sent from my Nexus 4.

--
You received this message because you are subscribed to the Google Groups "Capistrano" group.
To unsubscribe from this group and stop receiving emails from it, send an email to capistrano+...@googlegroups.com.

James B. Byrne

unread,
Dec 3, 2013, 3:20:14 PM12/3/13
to capis...@googlegroups.com

On Tue, December 3, 2013 14:59, Lee Hambley wrote:
> There is no *encrypting* you should give SSH keys a shot.
>

Hashing then. According to authconfig both the deploying and repository
servers are using sha512. How does Capistrano send the password?

This looks to me that whatever is happening to prevent the proper password
from being recognized is happening inside Capistrano itself.

** [xnet241.hamilton.harte-lyne.ca :: out] Permission denied
(publickey,password).
** [xnet241.hamilton.harte-lyne.ca :: out] fatal: The remote end hung up
unexpectedly

Yes, we can set up the keys on the git host but, as we spin up and remove
virtual hosts for development and testing, making that an ongoing requirement
is going to be a persistent irritation. Also, we did not have this problem
originally so the issue is either some change to Ruby or some change to
Capistrano.

James B. Byrne

unread,
Dec 3, 2013, 3:25:39 PM12/3/13
to capis...@googlegroups.com

So, I rolled back to version 2.14.1, which was the one available when we last
used this deploy, and things now work.

James B. Byrne

unread,
Dec 3, 2013, 4:23:24 PM12/3/13
to capis...@googlegroups.com
The following versions work:
2.14.1
2.14.2
2.15.2
2.15.3
2.15.4

All the others either throw errors or fail to log on to the git host as
previously described.

Lee Hambley

unread,
Dec 3, 2013, 4:36:59 PM12/3/13
to capistrano
Glad you got everything working again. Remember to lock the version in your Gemfile!
Reply all
Reply to author
Forward
0 new messages