Capistrano demande un mot de passe lors du déploiement, malgré les clés SSH

Question

Mes clés ssh sont certainement configurées correctement, car le mot de passe ne m'est jamais demandé lorsque j'utilise ssh. Mais capistrano demande toujours un mot de passe lors du déploiement avec cap deploy . Il ne demande pas le mot de passe lorsque je configure avec cap deploy:setup pourtant, étrangement. Le cycle de déploiement serait tellement plus fluide sans demande de mot de passe.

Spécificités : Je déploie une application Sinatra sur un compte partagé Dreamhost (qui utilise Passenger). J'avais suivi un tutoriel pour le faire il y a longtemps, qui fonctionnait parfaitement à l'époque. Quelque chose s'est cassé depuis. J'utilise capistrano (2.5.9) et git version 1.6.1.1. Voici mon 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"

Et voici le résultat de ce qui se passe quand je cap deploy jusqu'à l'invite du mot de passe :

$ 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.

Qu'est-ce qui pourrait être cassé ?

Answer 1

Exécuter ssh-add ~/.ssh/id_rsa dans ma machine locale a réglé le problème pour moi. Il semblait que l'outil de ligne de commande ssh ne détectait pas mon identité lorsqu'il était appelé avec Capistrano.

Answer 2

La demande de mot de passe est due au fait que le serveur sur lequel vous effectuez le déploiement se connecte au serveur git et nécessite une authentification. Puisque votre machine locale (où vous déployez l'application de ) a déjà une clé ssh valide, utilisez-la en activant la redirection dans votre Capfile :

set :ssh_options, {:forward_agent => true}

Cela transmet l'authentification de votre machine locale lorsque le serveur de déploiement tente de se connecter à votre serveur git.

C'est bien mieux que de mettre votre clé privée sur le serveur de déploiement !

Une autre façon de contourner l'invite de mot de passe lorsque le serveur se reconnecte par ssh est de dire à capistrano de ne pas le faire. Grâce à la section 'readme' de l'application de Daniel Quimper, Capistrano peut être utilisé comme un outil d'aide à la décision. capistrano-site5 github repo, nous notons ce qui suit :

set :deploy_via, :copy

Évidemment, cela fonctionne dans le cas où l'application et le dépôt git sont hébergés sur le même hôte. Mais je suppose que certains d'entre nous le font :)

Answer 3

J'ai eu le même problème.

Cette ligne n'a pas fonctionné :

set :ssh_options, {:forward_agent => true}

Puis j'ai exécuté ce qui est mentionné sur le wiki de Dreamhost.

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

Et maintenant je peux déployer sans mot de passe.

Answer 4

Les journaux montrent qu'un mot de passe a été demandé après la connexion via SSH à jellly.com, il semble donc que la mise à jour git actuelle demande un mot de passe.

Je pense que c'est parce que la configuration de votre dépôt spécifie votre utilisateur git, même si vous pouvez y accéder de manière anonyme dans ce cas.

Vous devez créer un compte git anonyme et changer votre ligne de repo comme ceci :

set :repository,  "git@jellly.com:git/jellly.git"

Vous pourriez également placer votre clé SSH SUR votre serveur de production, mais cela ne semble pas utile. Vous pouvez également configurer SSH de manière à renvoyer les demandes d'authentification via la connexion SSH initiale. Le contrôle de source anonyme en lecture seule pour le déploiement est probablement plus facile, cependant.

Answer 5

Si vous utilisez un poste de travail Windows (portable) que vous connectez parfois directement à un réseau d'entreprise interne et parfois via un VPN, il se peut que vous obteniez un comportement incohérent lors de l'exécution de tâches distantes à capuchon vous demandant un mot de passe.

Dans ma situation, notre entreprise a des scripts de connexion qui s'exécutent lorsque vous vous connectez alors que vous êtes déjà connecté au LAN de l'entreprise et qui définissent votre répertoire HOME à un emplacement de partage de réseau. Si vous vous connectez à partir d'informations d'identification mises en cache et que vous vous connectez ensuite par VPN, votre répertoire d'origine n'est pas défini par le scripts de connexion. Le répertoire .ssh qui stocke votre clé privée peut se trouver dans un seul de ces emplacements.

Une solution facile dans cette situation est de copier le répertoire .ssh de l'ordinateur HOME qui en dispose vers celui qui n'en dispose pas.