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

Mes clés ssh sont configurées correctement, car je ne suis jamais invité à saisir le mot de passe lors de l’utilisation de 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 quoique assez étrangement. Cela faciliterait considérablement le cycle de déploiement sans invite de mot de passe.

Particularités: Je déploie une application Sinatra sur un compte partagé Dreamhost (qui utilise Passenger). J’avais suivi un tutoriel depuis longtemps, qui fonctionnait parfaitement à l’époque. Quelque chose a 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 lorsque je cap deploy , jusqu’à l’invite de 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é?

L’invite 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. Comme votre ordinateur local (à partir duquel vous effectuez le déploiement) possède déjà une clé ssh valide, utilisez-la en activant le transfert dans votre fichier de configuration:

 set :ssh_options, {:forward_agent => true} 

Cela transfère l’authentification de votre ordinateur local lorsque le serveur de déploiement tente de se connecter à votre serveur git.

Ceci est bien plus préférable 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 remet à fonctionner est de dire à capistrano de ne pas le faire. Grâce à la section ‘readme’ du repository github de capistrano-site5 de Daniel Quimper, nous notons:

 set :deploy_via, :copy 

Évidemment, cela fonctionne dans le cas où l’application et le référentiel git sont hébergés sur le même hôte. Mais je suppose que certains d’entre nous le font 🙂

L’exécution de ssh-add ~/.ssh/id_rsa dans ma machine locale a résolu 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.

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

Cette ligne ne fonctionnait pas:

 set :ssh_options, {:forward_agent => true} 

Puis j’ai exécuté mentionné sur le wiki 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.

Les journaux indiquent qu’il est invité à entrer un mot de passe après s’être connecté via SSH à jellly.com. Il semble donc que la mise à jour actuelle de git demande un mot de passe.

Je pense que c’est parce que votre paramètre de référentiel spécifie votre utilisateur git, même si vous pouvez y accéder anonymement dans ce cas.

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

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

Vous pouvez également placer votre clé SSH sur votre serveur de production, mais cela ne semble pas utile. Vous pouvez également configurer SSH pour transférer 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.

Je copie et colle ma clé machie id_rsa.pub locale dans le fichier authorized_key du serveur distant et cela a fonctionné

Si vous utilisez un poste de travail Windows (portable) que vous connectez parfois directement à un réseau d’entreprise interne et que vous vous connectez parfois via VPN, vous pouvez constater un comportement incohérent lors de l’exécution de tâches à distance vous demandant un mot de passe.

Dans ma situation, notre société dispose de scripts de connexion qui s’exécutent lorsque vous vous êtes connecté alors que vous êtes déjà connecté au réseau local de la société qui définit votre répertoire HOME sur un emplacement de partage réseau. Si vous vous connectez à partir des informations d’identification mises en cache et que vous utilisez VPN, votre répertoire de base n’est pas défini par le script de connexion. Le répertoire .ssh qui stocke votre clé privée peut se trouver dans un seul de ces emplacements.

Une solution simple dans cette situation consiste à copier le répertoire .ssh de la page d’accueil vers celui qui ne le contient pas.

copier manuellement la clé publique à authorized_keys ne fonctionnait pas dans mon cas mais le faire via le service après-vente, quand j’ai trouvé que le service avait simplement ajouté une autre clé à la fin

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