59

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 with cap 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,  "ehsanul@jellly.com: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 ehsanul@jellly.com: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 ehsanul@jellly.com: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] ehsanul@jellly.com'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?

ehsanul
  • 7,737
  • 7
  • 33
  • 43

7 Answers7

72

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.

Pablo Torrecilla
  • 2,098
  • 20
  • 15
  • 4
    I added that command to my bash_profile file, so I am sure that the default identity is loaded wherever I start a new terminal session. – Pablo Torrecilla Nov 22 '16 at 17:59
  • This also solved it for me, but every now and them (randomly as it seems) I have to run it again. – sandre89 Apr 04 '17 at 03:58
  • Not sure if this was the upgrade to OSX Sierra or what, but I had to do the same thing. – Joel Grannas Apr 10 '17 at 13:25
  • One of these brilliant copy/paste answers that save the day! Thanks – chosta Apr 19 '17 at 14:15
  • I had problem deploying Rails app with Capistrano 3 on macOS Sierra (on Yosemite all had been fine), I was prompted to enter password each time (but with Capistrano 2 everything worked well) problem was solved using this link - https://help.github.com/articles/generating-a-new-ssh-key-and-adding-it-to-the-ssh-agent/#adding-your-ssh-key-to-the-ssh-agent – Michael Klishevich Aug 23 '17 at 06:07
  • This solution is not working for me after a restart on my machine. Anyone else? – Joel Grannas Jun 27 '18 at 01:27
56

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 :)

David Vezzani
  • 1,449
  • 16
  • 24
tobym
  • 1,354
  • 1
  • 10
  • 11
  • 3
    I didn't put my private key on the server. I just added the deployment server's public key to it's own list of `authorized_keys`. This is because the the deployment server is also my git server, and apparently it tries to ssh into itself due to how Capistrano works, causing a password login. So I basically just set up ssh keys between the server and itself. Much safer than putting my private key out there ;) I'll try the forward_agent thing though, looks like a cleaner solution. Thanks! :) – ehsanul Sep 04 '10 at 21:50
  • In case anyone else wonders why this works and where is it documented, these are options for Net:SSH, see "Options" in http://net-ssh.github.com/ssh/v1/chapter-2.html . – oseiskar Feb 16 '13 at 13:16
  • 1
    Btw if you still have problems, especially when using custom named keys, try this: `ssh_options[:keys] = [File.join(ENV["HOME"], ".ssh", "my_custom_id_rsa")]` – Mario Uher Apr 30 '13 at 18:29
18

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.

iconoclast
  • 21,213
  • 15
  • 102
  • 138
fetsh
  • 1,949
  • 1
  • 16
  • 17
  • 2
    That line by itself shouldn't work. It just enables agent forwarding. If you don't have one running in the first place it wouldn't be much of much help. – Sam Figueroa May 29 '12 at 14:21
  • 2
    You should add your private key, not public. – DaveStephens Oct 28 '13 at 15:35
  • I do this all the time but still asks for password. My config is `set :ssh_options, { forward_agent: true, user: fetch(:user), keys: %w(~/.ssh/id_rsa.pub) }` – Amit Patel Aug 08 '15 at 14:35
  • You might also want to add the fingerprint of the ssh private key added to your Project Settings to the config.yml... – Funso Popoola Apr 17 '17 at 17:36
3

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,  "git@jellly.com: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.

Winfield
  • 18,985
  • 3
  • 52
  • 65
  • 2
    Thanks, that fixed it! Looks like setting up another user would work too, but I just went with making the server's own ssh key authorized with itself - easy and no security risk. Used this: `cat ~/.ssh/id_rsa.pub | ssh ehsanul@jellly.com 'cat >> .ssh/authorized_keys'` – ehsanul Jul 17 '10 at 09:30
  • Hmmm, actually, wouldn't just specifying `set :repository, /home/ehsanul/git/jellly.git` work as well, without the ssh? Edit: nope, doesn't work. – ehsanul Jul 17 '10 at 09:41
  • I'm glad you got this working. It's a security risk to keep your private key on the server, you should only store the public key there. At least this confirms the problem. I would recommend using the anonymous or limited access account instead of publishing your private key on the app server. – Winfield Jul 17 '10 at 17:31
  • Just to clarify, I didn't put my private key on the server. See my comment to the other answer for what I did. – ehsanul Sep 05 '10 at 04:30
  • @ehsanul: I think `ssh-copy-id username@server` being executed on your local machine does exactly what your cat-pipe-stunt does =). – Besi Oct 06 '22 at 09:06
1

I copy and paste my local machie id_rsa.pub key to remote server authorized_key file and it worked

Sanjay Salunkhe
  • 2,665
  • 5
  • 28
  • 52
1

copying public key manually to authorized_keys did not work in my case but doing it via service worked, when I found service had simply added one more same key at the end

ssh-copy-id -i ~/.ssh/id_rsa.pub user@remote
Lorenz Meyer
  • 19,166
  • 22
  • 75
  • 121
Amol Pujari
  • 2,280
  • 20
  • 42
0

If you're using a Windows workstation (portable) that you sometimes dock directly into an internal corporate network and sometimes connect via VPN, you may find that you get inconsistent behavior in running cap remote tasks asking you for a password.

In my situation, our company has login scripts that execute when you logged in while already connected to the company LAN that set your HOME directory to a network share location. If you login from cached credentials and then VPN in, your home directory isn't set by the login script. The .ssh directory that stores your private key may be in only one of those locations.

An easy fix in that situation is to just copy the .ssh directory from the HOME that has it to the one that doesn't.

Joel Wilson
  • 169
  • 1
  • 1
  • 7