Mis claves ssh definitivamente están configuradas correctamente, ya que nunca se me pide la contraseña cuando uso ssh. Pero capistrano todavía pide una contraseña al implementar con cap deploy. Sin embargo, no me pide la contraseña cuando configuro con cap deploy:setup, por extraño que parezca. Haría que el ciclo de despliegue fuera mucho más fluido sin una solicitud de contraseña.Capistrano pide una contraseña al implementar, a pesar de las teclas SSH
Particularidades: Estoy implementando una aplicación Sinatra en una cuenta compartida de Dreamhost (que usa Passenger). Había seguido un tutorial por mucho tiempo atrás, que funcionó perfectamente en aquel entonces. Algo roto desde entonces. Estoy usando capistrano (2.5.9) y git versión 1.6.1.1. Aquí está mi 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"
Y aquí está la salida de lo que sucede cuando cap deploy, hasta la solicitud de contraseña:
$ 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.
Qué podría ser roto?
No puse mi clave privada en el servidor. Acabo de agregar la clave pública del servidor de implementación a su propia lista de 'authorized_keys'. Esto se debe a que el servidor de implementación también es mi servidor git, y aparentemente intenta introducirse en sí mismo debido a la forma en que funciona Capistrano, lo que provoca un inicio de sesión con contraseña. Así que, básicamente, configuré claves ssh entre el servidor y él mismo. Mucho más seguro que poner mi llave privada por ahí;) Aunque probaré el artículo forward_agent, parece una solución más limpia. ¡Gracias! :) – ehsanul
Funcionó maravillosamente para mí. – kain
En caso de que alguien más se pregunte por qué funciona esto y dónde está documentado, estas son opciones para Net: SSH, consulte "Opciones" en http://net-ssh.github.com/ssh/v1/chapter-2.html. – oseiskar