Capistrano demande de mot de passe lors du déploiement, en dépit de clés SSH
Mes clés ssh sont définitivement réglée correctement, comme je ne suis jamais invité pour 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 j'ai le programme d'installation avec cap deploy:setup mais, assez étrangement. Il serait le cycle de déploiement tellement lisse, sans une invite de mot de passe.
Détails: je suis le déploiement d'un Sinatra application à Dreamhost compte partagé (qui utilise des Passagers). J'avais suivi un tutoriel pour le faire longtemps en arrière, ce qui a parfaitement fonctionné alors. Quelque chose s'est cassé depuis. Je suis l'aide de capistrano (2.5.9) et de version git 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, "[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 la sortie de ce qui se passe quand 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 [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] ehsanul@jellly.com's password:
Password:
** [jellly.com :: out]
** [jellly.com :: out] remote: Counting objects: 7, done.
remote: Compressing objects: 100% (4/4), done.Ce qui pourrait être cassé?
Vous devez vous connecter pour publier un commentaire.
L'invite de mot de passe parce que le serveur de déploiement à l'est de la connexion au serveur git et les besoins d'authentification. Depuis votre machine locale (où vous déployez de) a déjà valable ssh-clé de l'utilisation que l'on en permettant le transfert dans votre Capfile:
Qui transmet l'authentification à partir de votre ordinateur local lorsque le serveur de déploiement tente de se connecter à votre serveur git.
C'est préférable 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 ssh avec retour sur lui-même est-à-dire capistrano de ne pas le faire. Merci pour le "readme" pour Daniel Quimper est capistrano-web5 dépôt github, on note les suivantes:
Évidemment, cela fonctionne pour le cas où à la fois 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 sont en train de faire ça 🙂
authorized_keys. C'est parce que le serveur de déploiement est aussi mon serveur git, et apparemment, il essaie de faire un ssh sur lui-même en raison de la façon dont Capistrano œuvres, provoquant un mot de passe de connexion. Donc en gros, je viens de mettre en place des clés ssh entre le serveur et de lui-même. Beaucoup plus sûr que de mettre ma clé privée là 😉 je vais essayer de forward_agent chose si, ressemble à une solution plus propre. Merci! 🙂ssh_options[:keys] = [File.join(ENV["HOME"], ".ssh", "my_custom_id_rsa")]L'exécution de
ssh-add ~/.ssh/id_rsadans ma machine locale fixe le problème pour moi. Il semblait que le ssh outil de ligne de commande n'était pas détecter mon identité lorsqu'elle est appelée avec Capistrano.J'ai eu le même problème.
Cette ligne ne marche pas:
Puis j'ai exécuté mentionné sur Dreamhost wiki
Et maintenant je peux déployer sans mot de passe.
set :ssh_options, { forward_agent: true, user: fetch(:user), keys: %w(~/.ssh/id_rsa.pub) }Les diagraphies il vous y êtes invité pour un mot de passe après la connexion via SSH à jellly.com, de sorte qu'il ressemble le réel git mise à jour à l'aide d'un mot de passe.
Je pense que c'est parce que votre référentiel paramètre spécifie les utilisateurs de git, même si vous pouvez y accéder de façon anonyme dans ce cas.
Vous devez créer un anonyme git compte et changer votre repo ligne comme ceci:
Sinon, vous pourriez mettre votre clé SSH SUR votre serveur de production, mais qui ne semble pas utile. Vous pourriez également être en mesure de configurer SSH pour transférer les demandes d'authentification en arrière lors de la première connexion SSH. L'anonyme en lecture seule source de contrôle pour déployer est probablement plus facile, cependant.
cat ~/.ssh/id_rsa.pub | ssh [email protected] 'cat >> .ssh/authorized_keys'set :repository, /home/ehsanul/git/jellly.gittravailler ainsi, sans le ssh? Edit: nope, ne fonctionne pas.Je fais un copier-coller de ma région machie id_rsa.pub la clé de serveur distant authorized_key fichier et il a travaillé
Si vous utilisez un poste de travail Windows (portable) que vous avez parfois dock directement dans un réseau interne de l'entreprise et, parfois, se connecter via un VPN, vous pouvez trouver que vous obtenez un comportement incohérent dans la pac en cours d'exécution à distance des tâches, vous demandant 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 qu'il est déjà connecté au réseau LAN de votre répertoire de base à un emplacement de partage réseau. Si vous vous connectez à partir de la mise en cache des informations d'identification et le VPN, votre répertoire d'accueil n'est pas défini par le script de connexion. L' .ssh répertoire qui contient votre clé privée peut être dans un de ces emplacements.
Une solution facile dans cette situation est de simplement copier le .ssh répertoire à partir de la MAISON qui, s'il est le seul qui n'a pas.
la copie de la clé publique manuellement à authorized_keys n'a pas fonctionné dans mon cas, mais le faire via le service a travaillé, quand j'ai trouvé le service avait simplement ajouté un plus de même à la fin