web-dev-qa-db-fra.com

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

Mes clés ssh sont définitivement 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 quand je configure avec cap deploy:setup cependant, assez étrangement. Cela rendrait le cycle de déploiement beaucoup plus fluide sans une 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 si longtemps, qui fonctionnait parfaitement à l'époque. Quelque chose a cassé depuis. J'utilise capistrano (2.5.9) et la version 1.6.1.1 de git. 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,  "[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"

Et voici le résultat de ce qui se passe lorsque je cap deploy, jusqu'au mot de passe Invite:

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

Que pourrait être brisé?

ruby-on-railsrubysinatracapistranossh-keys
47
ehsanul

L'invite de mot de passe est due au fait que le serveur sur lequel vous déployez se connecte au serveur git et a besoin d'une authentification. Puisque votre ordinateur local (où vous déployez de) a déjà une clé ssh valide, utilisez-la en activant le transfert dans votre fichier de configuration:

set :ssh_options, {:forward_agent => true}

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

Ceci est de loin préférable à l’utilisation de votre clé privée sur le serveur de déploiement!

Une autre façon de contourner le mot de passe Une invite lorsque le serveur revient sur lui-même est de dire à capistrano de ne pas le faire. Merci à la section 'readme' pour le repo github capistrano-site5 de Daniel Quimper, nous notons ce qui suit:

set :deploy_via, :copy

De toute évidence, cela fonctionne dans le cas où le référentiel de 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 :)

53
tobym

L'exécution de ssh-add ~/.ssh/id_rsa sur mon ordinateur local 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.

59
Pablo Torrecilla

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é mentionné sur Dreamhost wiki 

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

17
fetsh

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

Je pense que cela est dû au fait 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 devriez créer un compte git anonyme et changer votre ligne de repo comme ceci:

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

Vous pouvez également mettre votre clé SSH sur votre serveur de production, mais cela ne semble pas utile. Vous pourriez également être en mesure de configurer SSH pour renvoyer les demandes d'authentification via la connexion SSH initiale. Le contrôle de source anonyme en lecture seule pour le déploiement est toutefois probablement plus facile.

3
Winfield

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

1
Sanjay Salunkhe

la copie manuelle de la clé publique manuellement au paramètre allowed_keys ne fonctionnait pas dans mon cas, mais le faire via le service fonctionnait, alors que le service avait simplement ajouté une clé supplémentaire à la fin.

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

Si vous utilisez un poste de travail Windows (portable) que vous ancrez parfois directement dans un réseau d'entreprise interne et que vous vous connectez parfois via un réseau privé virtuel, vous constaterez peut-être un comportement incohérent lors de l'exécution de tâches distantes de cap qui vous demandent un mot de passe.

Dans ma situation, notre société a des 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 d'informations d'identification mises en cache, puis 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 ne se trouver qu’à l’un de ces emplacements.

Une solution facile dans cette situation consiste simplement à copier le répertoire .ssh du HOME qui le contient vers celui qui n'en a pas.

0
Joel Wilson