2013-10-28 10 views
8

ठीक है, मैंने इस विषय पर कई बार ठोकर खाई है, लेकिन यह पहली बार है कि नियमित समाधानों में से कोई भी काम नहीं करता है।गिटलैब एसएसएच कुंजी ने काम करना बंद कर दिया

मेरे पास एक CentOS 6.4 सर्वर GitLab चल रहा है। यह 20+ उपयोगकर्ताओं और 60+ परियोजनाओं के साथ बहुत अच्छा काम कर रहा है, लेकिन लगभग 5 घंटे पहले, मेरा मुख्य स्टेजिंग सर्वर मुख्य प्रमाणीकरण का उपयोग करके पहली बार गिटलैब मशीन से कनेक्ट करने में असमर्थ था और यह पासवर्ड के लिए संकेत दिया गया था। मैंने आरएसए कुंजी को पुन: उत्पन्न किया और इसे अपनी तैनाती कुंजी में जोड़ा, लेकिन यह भी असफल रहा।

अगला, मैंने स्टेजिंग सर्वर पर एक नया उपयोगकर्ता बनाने की कोशिश की, इसके लिए एक कुंजी बनाएं, और इसे गिटलैब में जोड़ें लेकिन यह अभी भी विफल हो गया है।

अनुमतियां:

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: 

जब मैं वेब इंटरफेस के माध्यम से एसएसएच कुंजी जोड़ता हूं, तो उन्हें .ssh/authorized_keys में जोड़ा नहीं जाता है।

मैं वास्तव में आगे क्या करने की कोशिश करना नहीं जानते :(

+0

क्या आप अपनी सार्वजनिक कुंजी 'git.mygitlab.com: ~ git/.ssh/valid_keys' में देखते हैं? – VonC

+0

वास्तव में नहीं! मेरे पास gitlab सर्वर पर अधिकृत कुंजी फ़ाइलों में 49 कुंजी हैं, जब मैं अतिरिक्त कुंजी जोड़ता हूं तो वे – SlipY

+0

दिखाई नहीं देंगे, तो यह वही समस्या है। क्या गिटलैब में कोई लॉग है जो एक सुराग छोड़ देगा? – VonC

उत्तर

5

कुंजी है कि आप GitLab में जोड़ने के लिए यह नहीं कर रहे हैं, तो .ssh/authorized_keys में:

  1. सुनिश्चित करें कि sidekiq चल रहा है। कुंजी को साइडकीक वर्कर में गिटलैब-खोल में जोड़ा जाता है, इसलिए यदि साइडकीक डाउन हो गया है या बैकलॉग किया गया है, तो वे इसे नहीं बनाएंगे। आप इसे ps -fu git के आउटपुट में देख सकते हैं और व्यवस्थापक पृष्ठ पर "पृष्ठभूमि नौकरियां" टैब देखकर देख सकते हैं
  2. सुनिश्चित करें कि गिटलैब गिटलैब-खोल को सही तरीके से निष्पादित कर सकता है। साइडकीक कर्मचारी exec'ing a gitlab-shell process द्वारा चाबियाँ जोड़ता है। विशेष रूप से, यह ssh_user सेटिंग gitlab.yml में गलत है, या यदि उस उपयोगकर्ता के लिए ~/gitlab-shell के अलावा किसी अन्य स्थान पर gitlab-shell स्थापित है, तो यह काम नहीं करेगा।
  3. सत्यापित करें कि सर्वर के/घर विभाजन पूर्ण नहीं है। यदि डिस्क authorized_keys फ़ाइल भरने पर संग्रहीत है, तो कुंजी असफल हो जाती है! यह मुझे कुछ बार मिला है। यह देखने के लिए कि क्या आपके पास अभी भी कमरा है, df -h /home का उपयोग करें।

गिटलैब-खोल से त्रुटि संदेशों के लिए अपने लॉग जांचें: समस्या के आधार पर, त्रुटि संदेश यूनिकॉर्न या साइडकीक के लॉग में दिखाई दे सकते हैं।

+0

हाय ऐश, आप 100% सही हैं, लेकिन जैसा कि मैंने गिटलाब (4.1) के पुराने संस्करण का उपयोग करके कहा है और मेरे पास gitlab-shell नहीं है .. मैं संस्करण द्वारा संस्करण को अपग्रेड करने का प्रयास कर रहा हूं, जब तक यह – SlipY

+0

ओह, ठीक है, मैं उस बिट को याद किया। हाँ, 4.1 गिटोलाइट दिनों में वापस आ गया था। यदि आप सीधे गिटोलाइट कॉन्फ़िगरेशन रेपो खींचते हैं, तो क्या आपकी चाबियां गिटोलाइट की सेटिंग्स में बन रही हैं? यदि नहीं, तो सब कुछ पुन: सिंक्रनाइज़ करने के लिए एक रेक कार्य है: 'रेक gitlab: gitolite: update_keys' –

+0

यह भी संभव है कि आपके गिटोलाइट इंस्टॉलेशन के साथ कुछ गड़बड़ हो, जैसे लापता या गैर-निष्पादन योग्य पोस्ट-प्राप्त हुक। अपने गिटोलाइट इंस्टॉल को दोबारा जांचें: https://github.com/sitaramc/gitolite –

3

खैर, अब मैं कर रहा हूँ 5.1 के तहत मैं इसे कदम 4.1> 4.2 4.2> 4.3 से कदम था और अंत में सब कुछ और चल रहा है।

बस 4.1 उपयोगकर्ताओं के बारे में जानने के लिए -> डेवलपर्स में से एक ने $ # रूट ... सहित एक खराब कुंजी जोड़ा और यह सिंक तोड़ दिया।

धन्यवाद के लिए आपकी मदद

+0

जानना दिलचस्प है। +1 – VonC

0

मैं बस जब मैं HTTPS करने के लिए HTTP से GitLab सर्वर बंद कर इस समस्या में पड़ गए। सबकुछ वेब सर्वर पर ठीक दिखता था - लॉग इन इत्यादि सामान्य रूप से काम कर रहे थे लेकिन गिट @ गीटलैब एसएसएच कनेक्शन असफल हो रहे थे।

https://stackoverflow.com/a/19637026/2162639 (ऊपर) में # 2 को देखने के बाद मुझे पता चला कि मैं https://gitlab.server.fqdn बजाय http://gitlab.server.fqdn उपयोग करने के लिए /home/git/gitlab-shell/config.yaml में gitlab_url सेटिंग को संशोधित करने की जरूरत। मैंने उस सेटिंग को बदल दिया, गिटलैब सेवा को पुनरारंभ किया और सब कुछ सामान्य रूप से काम कर रहा था।

0

होस्ट के लिए सभी पिछली कुंजी हटाएं। समस्या यह है कि gitlab किसी भी पुरानी कुंजी लेता है और यदि मैच मौजूद नहीं है, तो यह वहां विफल रहता है। आपकी कामकाजी कुंजी बाद में सूचीबद्ध हो सकती है और कभी नहीं चुनी जाती है।

संबंधित मुद्दे