10

好的，我多次偶然发现这个话题，但这是第一次没有一个常规解决方案有效。

我有一个运行GitLab的 CentOS 6.4 服务器。它在 20 多个用户和 60 多个项目中运行良好，但大约 5 小时前，我的主登台服务器第一次无法使用密钥身份验证连接到 GitLab 机器，并提示输入密码。我重新生成了 RSA 密钥并将其添加到我的部署密钥中，但这也失败了。

接下来，我尝试在登台服务器上创建一个新用户，为其创建一个密钥，并将其添加到 GitLab，但它仍然失败。

权限：

drwxr-x---  22 root root 4.0K Oct 28 13:20 root

内根：

drwx------   2 root root     4096 Oct 28 11:49 .ssh

.ssh 内部：

-rw-------  1 root root  227 Oct 28 11:48 authorized_keys
-rw-------  1 root root 1675 Oct 28 13:09 id_rsa
-rw-------  1 root root  398 Oct 28 13:09 id_rsa.pub
-rw-r--r--  1 root root  413 Oct 28 11:49 known_hosts

当我尝试连接到 git 机器时：

OpenSSH_4.3p2, OpenSSL 0.9.8e-fips-rhel5 01 Jul 2008
debug1: Reading configuration data /etc/ssh/ssh_config
debug1: Applying options for *
debug1: Connecting to git.mygitlab.com [212.29.122.24] port 22.
debug1: Connection established.
debug1: permanently_set_uid: 0/0
debug1: identity file /root/.ssh/identity type -1
debug1: identity file /root/.ssh/id_rsa type 1
debug1: identity file /root/.ssh/id_dsa type -1
debug1: loaded 3 keys
debug1: Remote protocol version 2.0, remote software version OpenSSH_5.3
debug1: match: OpenSSH_5.3 pat OpenSSH*
debug1: Enabling compatibility mode for protocol 2.0
debug1: Local version string SSH-2.0-OpenSSH_4.3
debug1: SSH2_MSG_KEXINIT sent
debug1: SSH2_MSG_KEXINIT received
debug1: kex: server->client aes128-cbc hmac-md5 none
debug1: kex: client->server aes128-cbc hmac-md5 none
debug1: SSH2_MSG_KEX_DH_GEX_REQUEST(1024<1024<8192) sent
debug1: expecting SSH2_MSG_KEX_DH_GEX_GROUP
debug1: SSH2_MSG_KEX_DH_GEX_INIT sent
debug1: expecting SSH2_MSG_KEX_DH_GEX_REPLY
debug1: Host 'git.mygitlab.com' is known and matches the RSA host key.
debug1: Found key in /root/.ssh/known_hosts:1
debug1: ssh_rsa_verify: signature correct
debug1: SSH2_MSG_NEWKEYS sent
debug1: expecting SSH2_MSG_NEWKEYS
debug1: SSH2_MSG_NEWKEYS received
debug1: SSH2_MSG_SERVICE_REQUEST sent
debug1: SSH2_MSG_SERVICE_ACCEPT received
debug1: Authentications that can continue: publickey,gssapi-keyex,gssapi-with-    mic,password
debug1: Next authentication method: gssapi-with-mic
debug1: Unspecified GSS failure.  Minor code may provide more information
No credentials cache found

debug1: Unspecified GSS failure.  Minor code may provide more information
No credentials cache found

debug1: Unspecified GSS failure.  Minor code may provide more information
No credentials cache found

debug1: Next authentication method: publickey
debug1: Offering public key: /root/.ssh/id_rsa
debug1: Authentications that can continue: publickey,gssapi-keyex,gssapi-with-    mic,password
debug1: Trying private key: /root/.ssh/identity
debug1: Trying private key: /root/.ssh/id_dsa
debug1: Next authentication method: password
git@git.mygitlab.com's password:

当我通过 Web 界面添加 SSH 密钥时，它们不会添加到.ssh/authorized_keys.

我真的不知道下一步该尝试什么:(

4

4 回答 4

5

If keys that you add to GitLab aren't making it into .ssh/authorized_keys:

  1. Make sure that sidekiq is running. Keys are added to gitlab-shell in a Sidekiq worker, so if Sidekiq is down or backlogged, they won't make it in. You can check this in the output of ps -fu git and by checking the "background jobs" tab on the admin page.
  2. Ensure that GitLab can execute gitlab-shell properly. The Sidekiq worker adds keys by exec'ing a gitlab-shell process. In particular, this won't work if the ssh_user setting is incorrect in gitlab.yml, or if gitlab-shell is installed to a location other than ~/gitlab-shell for that user.
  3. Verify that the server's /home partition isn't full. If the disk that the authorized_keys file is stored on fills up, key appends with fail! This one has gotten me a few times. Use df -h /home to see if you still have room.

Check your logs for error messages from gitlab-shell: depending on the problem, error messages could appear in unicorn's or sidekiq's logs.

于 2013-10-28T14:11:34.900 回答
3

好吧，现在我在 5.1 下，我逐步完成了 4.1 > 4.2 4.2 > 4.3，最后一切正常运行。

只是为了让 4.1 用户知道 - > 其中一位开发人员添加了一个坏密钥，包括 $#root... 这就是破坏同步的原因。

谢谢你的帮助

于 2013-10-30T09:31:26.480 回答
0

必须删除主机的所有先前密钥。问题是 gitlab 采用任何较旧的密钥，如果匹配项不存在，则在那里失败。您的工作密钥可能会在稍后按顺序列出，并且永远不会被选中。

于 2014-04-23T10:47:37.083 回答
0

当我将 GitLab 服务器从 HTTP 切换到 HTTPS 时，我刚刚遇到了这个问题。Web 服务器上的一切看起来都很好——登录等都正常工作，但 git@gitlab SSH 连接失败。

在查看https://stackoverflow.com/a/19637026/2162639（上图）中的 #2 后，我发现我需要修改gitlab_url设置/home/git/gitlab-shell/config.yaml以使用https://gitlab.server.fqdn而不是http://gitlab.server.fqdn. 我更改了该设置，重新启动了 gitlab 服务，一切正常。

于 2014-02-27T23:42:33.090 回答