Capistrano запрашивает пароль при развертывании, несмотря на SSH-ключи

Мои ключи ssh определенно настроены правильно, так как я никогда не запрашивал пароль при использовании ssh. Но capistrano все еще запрашивает пароль при развертывании с помощью cap deploy. Он не запрашивает пароль при настройке cap deploy:setup, хотя, как ни странно. Это сделало бы цикл развертывания более плавным без подсказки пароля.

Особенности: Я развертываю приложение Sinatra для общей учетной записи Dreamhost (которая использует Passenger). Я следил за учебником, который так долго работал, и тогда он отлично работал. С тех пор что-то сломалось. Я использую capistrano (2.5.9) и git версию 1.6.1.1. Здесь мой 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"

И вот вывод того, что происходит, когда я cap deploy, до подсказки пароля:

$ 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] password:
Password:
 ** [jellly.com :: out]
 ** [jellly.com :: out] remote: Counting objects: 7, done.
remote: Compressing objects: 100% (4/4), done.

Что можно сломать?

Ответ 1

Запрос пароля - это то, что сервер, к которому вы развертываетесь, подключается к серверу git и нуждается в аутентификации. Поскольку ваш локальный компьютер (где вы развертываете) уже имеет действительный ssh-ключ, используйте его, включив пересылку в своем Capfile:

set :ssh_options, {:forward_agent => true}

Это перенаправляет аутентификацию с вашего локального компьютера, когда сервер развертывания пытается подключиться к вашему серверу git.

Это гораздо предпочтительнее, если вы отключаете свой секретный ключ на сервере развертывания!

Другой способ обойти подсказку пароля, когда сервер ssh'ing возвращается сам по себе, - это сказать, что capistrano не делает этого. Благодаря разделу "readme" для Daniel Quimper capistrano-site5 github repo отметим следующее:

set :deploy_via, :copy

Очевидно, что это работает для случая, когда и приложение, и репозиторий git размещаются на одном хосте. Но я думаю, что некоторые из нас это делают:)

Ответ 2

Выполнение ssh-add ~/.ssh/id_rsa в моей локальной машине исправило проблему для меня. Казалось, что инструмент командной строки ssh не обнаруживал мою личность при вызове с Capistrano.

Ответ 3

У меня была такая же проблема.

Эта строка не работает:

set :ssh_options, {:forward_agent => true}

Затем я выполнил упомянутое на Dreamhost wiki

[local ~]$ eval `ssh-agent`
[local ~]$ ssh-add ~/.ssh/yourpublickey  # omit path if using default keyname

И теперь я могу развернуть без пароля.

Ответ 4

Журналы показывают, что он запрашивает пароль после входа в систему через SSH на jellly.com, поэтому похоже, что фактическое обновление git запрашивает пароль.

Я думаю, это связано с тем, что ваш параметр репозитория указывает вашего пользователя git, хотя вы можете получить доступ к нему анонимно в этом случае.

Вы должны создать анонимную учетную запись git и изменить свою линию репо, как это:

set :repository,  "[email protected]:git/jellly.git"

В качестве альтернативы вы можете поместить свой SSH-ключ на ваш производственный сервер, но это не кажется полезным. Вы также можете настроить SSH для пересылки запросов проверки подлинности обратно через начальное соединение SSH. Однако анонимный источник для чтения для развертывания, скорее всего, будет проще.

Ответ 5

Я копирую и вставляю свой локальный ключ id_rsa.pub в файл удаленного авторизационного сервера, и он работал

Ответ 6

Если вы используете рабочую станцию Windows (переносную), которую вы иногда подключаете непосредственно во внутреннюю корпоративную сеть, а иногда подключаетесь через VPN, вы можете обнаружить, что у вас возникло непоследовательное поведение при запуске закрытых удаленных задач с запросом пароля.

В моей ситуации у нашей компании есть сценарии входа в систему, которые выполняются при входе в систему, когда они уже подключены к локальной сети компании, которые устанавливают ваш каталог HOME в папку общего доступа к сети. Если вы входите в систему из кэшированных учетных данных и затем подключаетесь к сети VPN, ваш домашний каталог не задается при входе в систему script. Каталог .ssh, в котором хранится ваш закрытый ключ, может находиться только в одном из этих мест.

Легкое исправление в этой ситуации состоит в том, чтобы просто скопировать каталог .ssh из HOME, который имеет его, который не имеет.

Ответ 7

копирование открытого ключа вручную в authorized_keys не работало в моем случае, но выполнялось это с помощью службы, когда я обнаружил, что служба просто добавила еще один ключ в конце

ssh-copy-id ~/.ssh/id_rsa.pub [email protected]