尽管有 SSH 密钥,Capistrano 在部署时仍要求输入密码
我的 ssh 密钥绝对设置正确,因为在使用 ssh 时从未提示我输入密码。但 capistrano 在使用 cap deploy
进行部署时仍然要求输入密码。不过,奇怪的是,当我使用 cap deploy:setup 进行设置时,它并没有要求输入密码。没有密码提示,这将使部署周期变得更加顺利。
具体说明:我正在将 Sinatra 应用程序部署到 Dreamhost 共享帐户(使用 Passenger)。我很久以前就遵循了一个教程,当时效果非常好。从那时起,有什么东西坏了。我正在使用 capistrano (2.5.9) 和 git 版本 1.6.1.1。这是我的 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"
这是我 cap 部署
时发生的输出,直到出现密码提示:
$ 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.
什么可能会被破坏?
My ssh keys are definitely set up correctly, as I'm never prompted for the password when using ssh. But capistrano still asks for a password when deploying with cap deploy
. It doesn't ask for the password when I setup with cap deploy:setup
though, strangely enough. It would make the deployment cycle so much smoother without a password prompt.
Specifics: I'm deploying a Sinatra app to a Dreamhost shared account (which uses Passenger). I had followed a tutorial for doing so long back, which worked perfectly back then. Something broke since. I'm using capistrano (2.5.9) and git version 1.6.1.1. Here's my 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"
And here's the output of what happens when I cap deploy
, upto the password prompt:
$ 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.
What could be broken?
如果你对这篇内容有疑问,欢迎到本站社区发帖提问 参与讨论,获取更多帮助,或者扫码二维码加入 Web 技术交流群。
绑定邮箱获取回复消息
由于您还没有绑定你的真实邮箱,如果其他用户或者作者回复了您的评论,将不能在第一时间通知您!
发布评论
评论(7)
在我的本地计算机中执行 ssh-add ~/.ssh/id_rsa 解决了我的问题。当使用 Capistrano 调用时,ssh 命令行工具似乎没有检测到我的身份。
Executing
ssh-add ~/.ssh/id_rsa
in my local machine fixed the issue for me. It seemed that the ssh command line tool wasn't detecting my identity when called with Capistrano.提示密码是因为你部署到的服务器正在连接git服务器,需要身份验证。由于您的本地计算机(您要部署的地方)已经具有有效的 ssh 密钥,因此请通过在 Capfile 中启用转发来使用该密钥:
当部署服务器尝试时,它将从您的本地计算机转发身份验证连接到你的 git 服务器。
这比将私钥放在部署服务器上要好得多!
当服务器重新连接时绕过密码提示的另一种方法是告诉 capistrano 不要这样做。感谢 Daniel Quimper 的 capistrano-site5 github 存储库的“自述文件”部分,我们注意到以下:
显然,这适用于应用程序和 git 存储库托管在同一主机上的情况。但我想我们中的一些人正在这样做:)
The password prompt is because the server you are deploying to is connecting to the git server and needs authentication. Since your local machine (where you are deploying from) already has a valid ssh-key, use that one by enabling forwarding in your Capfile:
That forwards the authentication from your local machine through when the deployment server tries to connect to your git server.
This is much preferred to putting your private key out on the deployment server!
Another way of getting around the password prompt when the server is ssh'ing back on itself is to tell capistrano not to do so. Thanks to the 'readme' section for Daniel Quimper's capistrano-site5 github repo, we note the following:
Obviously, this works for the case where both the app and git repository are being hosted on the same host. But I guess some of us are doing that :)
我也遇到过同样的问题。
此行不起作用:
然后我执行了 Dreamhost wiki 上提到的内容
,现在我可以在没有密码的情况下进行部署。
I've had the same problem.
This line did'nt work:
Then I executed mentioned on Dreamhost wiki
And now I can deploy without password.
日志显示通过 SSH 登录 jellly.com 后提示输入密码,因此看起来实际的 git 更新正在提示输入密码。
我认为这是因为您的存储库设置指定了您的 git 用户,即使在这种情况下您可以匿名访问它。
您应该创建一个匿名 git 帐户并像这样更改您的存储库行:
或者,您可以将 SSH 密钥放在生产服务器上,但这听起来没什么用。您还可以将 SSH 配置为通过初始 SSH 连接转发回身份验证请求。不过,用于部署的匿名只读源代码控制可能更容易。
The logs show it prompted for a password after logging in via SSH to jellly.com, so it looks like the actual git update is prompting for a password.
I think this is because your repository setting specifies your git user, even though you can access it anonymously in this case.
You should create an anonymous git account and change your repo line like this:
Alternatively, you could put your SSH key ON your production server, but that doesn't sound useful. You also might be able to configure SSH to forward authentication requests back through the initial SSH connection. The anonymous read-only source control for deploy is likely easier, though.
我将本地机器 id_rsa.pub 密钥复制并粘贴到远程服务器authorized_key 文件中,它起作用了
I copy and paste my local machie id_rsa.pub key to remote server authorized_key file and it worked
在我的情况下,将公钥手动复制到authorized_keys不起作用,但通过服务执行此操作是有效的,当我发现服务只是在最后添加了一个相同的密钥时
copying public key manually to authorized_keys did not work in my case but doing it via service worked, when I found service had simply added one more same key at the end
如果您使用的是 Windows 工作站(便携式),有时直接连接到内部公司网络,有时通过 VPN 连接,您可能会发现在运行要求您输入密码的 cap 远程任务时出现不一致的行为。
在我的情况下,我们公司有登录脚本,当您登录时执行,同时已经连接到公司 LAN,将您的主目录设置为网络共享位置。如果您从缓存的凭据登录,然后通过 VPN 登录,则登录脚本不会设置您的主目录。存储您的私钥的 .ssh 目录可能仅位于这些位置之一。
在这种情况下,一个简单的解决方法是将 .ssh 目录从有 .ssh 目录的主目录复制到没有该目录的主目录。
If you're using a Windows workstation (portable) that you sometimes dock directly into an internal corporate network and sometimes connect via VPN, you may find that you get inconsistent behavior in running cap remote tasks asking you for a password.
In my situation, our company has login scripts that execute when you logged in while already connected to the company LAN that set your HOME directory to a network share location. If you login from cached credentials and then VPN in, your home directory isn't set by the login script. The .ssh directory that stores your private key may be in only one of those locations.
An easy fix in that situation is to just copy the .ssh directory from the HOME that has it to the one that doesn't.