2013-10-28 60 views
8

好的,我很多次都偶然發現了這個話題,但這是第一次沒有常規解決方案工作。GitLab SSH密鑰停止工作

我有一臺運行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 
[email protected]'s password: 

當我通過Web界面添加SSH密鑰時,它們不會被添加到.ssh/authorized_keys

我真的不知道下一步該怎麼嘗試:(

+0

你看到你的公鑰在'git.mygitlab.com:〜git/.ssh/authorized_keys'嗎? – VonC

+0

居然沒有!我在gitlab服務器上的授權密鑰文件中有49個密鑰,當我添加其他密鑰時,他們不會出現 – SlipY

+0

所以這就是問題所在。 gitlab中是否有任何會留下線索的日誌? – VonC

回答

5

如果您添加到GitLab鍵不使它成爲.ssh/authorized_keys

  1. 確保sidekiq運行。密鑰被添加到Sidekiq工作人員的gitlab-shell中,所以如果Sidekiq關閉或積壓,他們將無法進入。您可以在ps -fu git的輸出中檢查該密碼,並通過檢查管理頁面上的「後臺作業」選項卡。
  2. 確保GitLab可以正確執行gitlab-shell。 Sidekiq工作人員通過exec'ing a gitlab-shell process添加密鑰。尤其是,如果設置在gitlab.yml中不正確,或者如果gitlab-shell安裝到該用戶的~/gitlab-shell以外的其他位置,則這不起作用。
  3. 確認服務器的/ home分區未滿。如果authorized_keys文件存儲的磁盤已滿,密鑰添加失敗!這一次得到了我幾次。使用df -h /home看看你是否還有空間。

檢查您的日誌中是否存在來自gitlab-shell的錯誤消息:根據問題,錯誤消息可能出現在獨角獸或sidekiq的日誌中。

+0

嗨灰, 你是100%正確的,但正如我所說的即時通訊使用舊版本的Gitlab(4.1),我沒有gitlab外殼..即時嘗試升級版本的版本,直到它將是最新的 – SlipY

+0

哦,對,我錯過了那一點。是的,4.1回到了gitolite的日子。如果你直接把gitolite配置回購,你的密鑰是否成爲gitolite的設置?如果沒有,則有一個Rake任務來重新同步所有內容:'rake gitlab:gitolite:update_keys' –

+0

您的gitolite安裝可能存在某些問題,例如缺少或不可執行的post-receive鉤子。仔細檢查你的gitolite安裝:https://github.com/sitaramc/gitolite –

3

好了,現在我在5.1 我也一步一步 4.1> 4.2 4.2> 4.3 最後一切都正常運行。

僅供4.1用戶瞭解 - >其中一位開發人員添加了一個錯誤密鑰,包括$#root ... ,這是什麼打破了同步。

感謝您幫助

+0

有趣的知道。 +1 – VonC

0

我只是碰到了這個問題,當我從切換的HTTP服務器GitLab到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服務,並且一切正常。

0

必須刪除主機的所有以前的密鑰。問題是gitlab需要更老的鍵,如果匹配不存在,它會在那裏失敗。您的工作密鑰可能會在晚些時候按順序列出並從未被選中。