GitLab SSH 密钥停止工作 [英] GitLab SSH keys stopped working

查看:18
本文介绍了GitLab SSH 密钥停止工作的处理方法,对大家解决问题具有一定的参考价值,需要的朋友们下面随着小编来一起学习吧!

问题描述

好的,我多次偶然发现这个话题,但这是第一次没有一个常规解决方案起作用.

OK, I've stumbled on this topic many times, but this is the first time that none of the regular solutions worked.

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

I have a CentOS 6.4 server running GitLab. It's been working great with 20+ users and 60+ projects, but about 5 hours ago, my main staging server was unable to connect to the GitLab machine for the first time using key authentication and it prompted for password. I regenerated the RSA key and added it to my deploy keys, but that failed as well.

接下来,我尝试在临时服务器上创建一个新用户,为其创建一个密钥,并将其添加到 GitLab,但仍然失败.

Next, I tried to create a new user on the staging server, create a key for it, and add it to GitLab but it still fails.

权限:

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 机器时:

When I try to connect to the git machine:

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.

When I add SSH keys through the web interface, they aren't added to .ssh/authorized_keys.

我真的不知道接下来该尝试什么:(

I don't really know what to try next :(

推荐答案

如果您添加到 GitLab 的密钥没有进入 .ssh/authorized_keys:

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

  1. 确保 sidekiq 正在运行.密钥被添加到 Sidekiq 工作程序中的 gitlab-shell,因此如果 Sidekiq 关闭或积压,它们将无法进入.您可以在 ps -fu git 的输出中检查这一点,并通过检查管理页面上的后台作业"选项卡.
  2. 确保 GitLab 可以正常执行 gitlab-shell. Sidekiq worker 通过 执行一个 gitlab-shell 进程.特别是,如果 gitlab.yml,或者如果 gitlab-shell 安装到该用户的 ~/gitlab-shell 以外的位置.
  3. 验证服务器的/home 分区是否未满.如果存储 authorized_keys 文件的磁盘已满,则 key 会附加失败!这个已经让我好几次了.使用 df -h/home 查看是否还有空间.
  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.

检查您的日志中是否有来自 gitlab-shell 的错误消息:根据问题,错误消息可能会出现在 unicorn 或 sidekiq 的日志中.

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

这篇关于GitLab SSH 密钥停止工作的文章就介绍到这了,希望我们推荐的答案对大家有所帮助,也希望大家多多支持IT屋!

查看全文
登录 关闭
扫码关注1秒登录
发送“验证码”获取 | 15天全站免登陆