ruby-on-rails - deploy - capistrano rails

Capistrano pide una contraseña al implementar, a pesar de las claves SSH

Question

Mis claves ssh definitivamente están configuradas correctamente, ya que nunca se me pide la contraseña cuando uso ssh. Pero capistrano aún pide una contraseña al implementar con la cap deploy . No solicita la contraseña cuando configuré con la cap deploy:setup sin embargo, la cap deploy:setup bastante extraña. Haría que el ciclo de despliegue fuera mucho más fluido sin una solicitud de contraseña.

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á el resultado 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 estar roto?

Answer 1

Copié y pegué mi clave machie id_rsa.pub local en el archivo remote_key_key del servidor remoto y funcionó

Answer 2

He tenido el mismo problema.

Esta línea no funcionó:

set :ssh_options, {:forward_agent => true}

Luego ejecuté mencionado en la wiki de Dreamhost

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

Y ahora puedo implementar sin contraseña.

Answer 3

La ejecución de ssh-add ~/.ssh/id_rsa en mi máquina local me solucionó el problema. Parecía que la herramienta de línea de comandos de ssh no detectaba mi identidad cuando se llamaba con Capistrano.

Answer 4

La solicitud de contraseña se debe a que el servidor al que se está implementando se está conectando al servidor de git y necesita autenticación. Como su máquina local (desde donde está implementando) ya tiene una clave ssh válida, utilícela habilitando el reenvío en su Capfile:

set :ssh_options, {:forward_agent => true}

Eso reenvía la autenticación desde su máquina local cuando el servidor de implementación intenta conectarse a su servidor git.

¡Esto es preferible a poner su clave privada en el servidor de implementación!

Otra forma de evitar el aviso de contraseña cuando el servidor se está recuperando es decirle a capistrano que no lo haga. Gracias a la sección ''Léame'' de capistrano-site5 site5 github repo de Daniel Quimper, observamos lo siguiente:

set :deploy_via, :copy

Obviamente, esto funciona para el caso donde tanto la aplicación como el repositorio de git se alojan en el mismo host. Pero creo que algunos de nosotros lo estamos haciendo :)

Answer 5

Los registros muestran que solicitó una contraseña después de iniciar sesión a través de SSH a jellly.com, por lo que parece que la actualización actual de git está solicitando una contraseña.

Creo que esto se debe a que la configuración de su repositorio especifica su usuario de git, aunque en este caso puede acceder de forma anónima.

Debe crear una cuenta de git anónima y cambiar su línea de reserva de esta manera:

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

Alternativamente, podría poner su clave SSH en su servidor de producción, pero eso no parece útil. También es posible que pueda configurar SSH para reenviar las solicitudes de autenticación a través de la conexión SSH inicial. Sin embargo, el control de fuente de solo lectura anónimo para implementación es probablemente más fácil.

Answer 6

Si usa una estación de trabajo de Windows (portátil) que a veces se conecta directamente a una red corporativa interna y, en ocasiones, se conecta a través de VPN, es posible que observe un comportamiento incoherente en la ejecución de tareas remotas que le piden una contraseña.

En mi situación, nuestra empresa tiene scripts de inicio de sesión que se ejecutan cuando usted inició sesión mientras estaba conectado a la LAN de la compañía que configura su directorio HOME en una ubicación compartida de red. Si inicia sesión desde las credenciales en caché y luego ingresa VPN, el script de inicio no configurará su directorio de inicio. El directorio .ssh que almacena su clave privada puede estar en solo una de esas ubicaciones.

Una solución fácil en esa situación es copiar el directorio .ssh del HOME que lo tiene al que no lo tiene.

Answer 7

copiar la clave pública manualmente en authorized_keys no funcionó en mi caso, pero hacerlo a través del servicio funcionó, cuando descubrí que el servicio simplemente había agregado una misma clave al final

ssh-copy-id ~/.ssh/id_rsa.pub user@remote