Capistrano asks for password when deploying, despite SSH keys
Solution 1
The password prompt is because the server you are deploying to is connecting to the git server and needs authentication. Since your local machine (where you are deploying from) already has a valid ssh-key, use that one by enabling forwarding in your Capfile:
set :ssh_options, {:forward_agent => true}
That forwards the authentication from your local machine through when the deployment server tries to connect to your git server.
This is much preferred to putting your private key out on the deployment server!
Another way of getting around the password prompt when the server is ssh'ing back on itself is to tell capistrano not to do so. Thanks to the 'readme' section for Daniel Quimper's capistrano-site5 github repo, we note the following:
set :deploy_via, :copy
Obviously, this works for the case where both the app and git repository are being hosted on the same host. But I guess some of us are doing that :)
Solution 2
Executing ssh-add ~/.ssh/id_rsa
in my local machine fixed the issue for me. It seemed that the ssh command line tool wasn't detecting my identity when called with Capistrano.
Solution 3
I've had the same problem.
This line did'nt work:
set :ssh_options, {:forward_agent => true}
Then I executed mentioned on Dreamhost wiki
[local ~]$ eval `ssh-agent`
[local ~]$ ssh-add ~/.ssh/yourpublickey # omit path if using default keyname
And now I can deploy without password.
Solution 4
The logs show it prompted for a password after logging in via SSH to jellly.com, so it looks like the actual git update is prompting for a password.
I think this is because your repository setting specifies your git user, even though you can access it anonymously in this case.
You should create an anonymous git account and change your repo line like this:
set :repository, "[email protected]:git/jellly.git"
Alternatively, you could put your SSH key ON your production server, but that doesn't sound useful. You also might be able to configure SSH to forward authentication requests back through the initial SSH connection. The anonymous read-only source control for deploy is likely easier, though.
Solution 5
I copy and paste my local machie id_rsa.pub key to remote server authorized_key file and it worked
ehsanul
Updated on May 17, 2020Comments
-
ehsanul about 4 years
My ssh keys are definitely set up correctly, as I'm never prompted for the password when using ssh. But capistrano still asks for a password when deploying with
cap deploy
. It doesn't ask for the password when I setup withcap deploy:setup
though, strangely enough. It would make the deployment cycle so much smoother without a password prompt.Specifics: I'm deploying a Sinatra app to a Dreamhost shared account (which uses Passenger). I had followed a tutorial for doing so long back, which worked perfectly back then. Something broke since. I'm using capistrano (2.5.9) and git version 1.6.1.1. Here's my Capfile:
load 'deploy' if respond_to?(:namespace) # cap2 differentiator set :user, 'ehsanul' set :domain, 'jellly.com' default_run_options[:pty] = true # the rest should be good set :repository, "[email protected]:git/jellly.git" set :deploy_to, "/home/ehsanul/jellly.com" set :deploy_via, :remote_cache set :scm, 'git' set :branch, 'deploy' set :git_shallow_clone, 1 set :scm_verbose, true set :use_sudo, false server domain, :app, :web namespace :deploy do task :migrate do run "cd #{current_path}; /usr/bin/rake migrate environment=production" end task :restart do run "touch #{current_path}/tmp/restart.txt" end end after "deploy", "deploy:migrate"
And here's the output of what happens when I
cap deploy
, upto the password prompt:$ cap deploy * executing `deploy' * executing `deploy:update' ** transaction: start * executing `deploy:update_code' updating the cached checkout on all servers executing locally: "git ls-remote [email protected]:git/jellly.git deploy" /usr/local/bin/git * executing "if [ -d /home/ehsanul/jellly.com/shared/cached-copy ]; then cd /home/ehsanul/jellly.com/shared/cached-copy && git fetch origin && git reset --hard ea744c77b0b939d5355ba2dc50ef1ec85f918d66 && git clean -d -x -f; else git clone --depth 1 [email protected]:git/jellly.git /home/ehsanul/jellly.com/shared/cached-copy && cd /home/ehsanul/jellly.com/shared/cached-copy && git checkout -b deploy ea744c77b0b939d5355ba2dc50ef1ec85f918d66; fi" servers: ["jellly.com"] [jellly.com] executing command ** [jellly.com :: out] [email protected]'s password: Password: ** [jellly.com :: out] ** [jellly.com :: out] remote: Counting objects: 7, done. remote: Compressing objects: 100% (4/4), done.
What could be broken?