SSH: "ऐसी कोई पहचान नहीं"

4

मुझे अपने लिनक्स बॉक्स पर काम करने के लिए SSH की बहुत ही अजीब समस्या हो रही है। मेरे पास एक पासवर्ड रहित गिट उपयोगकर्ता है जिसे ओपनएसएसएच कुंजी द्वारा पहचाना जाता है। अगर मैं नेटवर्क पर एक ही या एक अलग लिनक्स VM से इसे ssh करने का प्रयास करता हूं, तो यह विफल हो जाता है (पूर्ण डेबिट कार्ड के लिए नीचे देखें)

लेकिन अब, यहाँ अजीब हिस्सा है: मैं अपने विंडोज 7 बॉक्स से बस ठीक करने में सक्षम हूँ, ठीक उसी कुंजी का उपयोग कर! इससे मुझे पता चलता है कि हम एक क्लाइंट-साइड समस्या को देख रहे होंगे। अगर सर्वर पर कीज़ किसी तरह से बोर हो गईं, तो मुझे कहीं से भी कनेक्ट करने में सक्षम नहीं होना चाहिए।

मैं दिनों से इस पर कीचड़ में अपने पहियों को पीस रहा हूं। इस विषय पर एक टन विषय है, लेकिन कोई भी समाधान या तो काम नहीं किया या लागू नहीं किया गया।

सामान्य उपाय जो मैंने पहले ही आजमा लिए हैं:

  1. ~ /। Ssh अनुमतियाँ सभी क्लाइंट और सर्वर पर ठीक से सेट की गई हैं।

    विशेष रूप से, ~ / .ssh / * 600 पर सेट किया गया था (एक सूत्र ने अधिकृत_कीप (सर्वर) को 644 में बदलने की सिफारिश की थी, लेकिन इसका कोई प्रभाव नहीं था)।

    ~ /। Ssh निर्देशिका को 700 पर सेट किया गया था।

    ~ में सब कुछ eponymous उपयोगकर्ता / समूह के स्वामित्व में है।

    ग्राहक (/home/kris/.ssh): 

    drwx------  2 kris kris 4096 Apr 11 01:17 .
drwx------ 38 kris kris 4096 Apr 11 01:29 ..
-rw-------  1 kris kris  458 Apr 11 16:22 config
-rw-------  1 kris kris 1675 Apr 10 22:29 id_rsa_kriscraig_git
-rw-------  1 kris kris 1675 Apr 11 01:08 id_rsa_kriscraig_git_CRAIGCOM-LINUX
-rw-------  1 kris kris  400 Apr 11 01:08 id_rsa_kriscraig_git_CRAIGCOM-LINUX.pub
-rw-------  1 kris kris 1675 Apr 11 01:09 id_rsa_kriscraig_git_CRAIGCOM-UT3
-rw-------  1 kris kris  400 Apr 11 01:09 id_rsa_kriscraig_git_CRAIGCOM-UT3.pub
-rw-------  1 kris kris  951 Apr 10 22:29 id_rsa_kriscraig_gitolite_Kris
-rw-------  1 kris kris  214 Apr 10 22:29 id_rsa_kriscraig_gitolite_Kris.pub
-rw-------  1 kris kris  381 Apr 10 22:29 id_rsa_kriscraig_git.pub
-rw-------  1 kris kris 1626 Apr 11 17:50 known_hosts

    सर्वर (/home/git/.ssh; यह सभी परीक्षण / त्रुटि जो मैं कर रहा हूं) के कारण अब थोड़ा अव्यवस्थित हो गया है: 

    drwx------ 2 git git 4096 Apr 11 01:36 .
drwx------ 8 git git 4096 Apr  9 17:55 ..
-rw-r--r-- 1 git git 2174 Apr 11 01:40 authorized_keys
-rw------- 1 git git  904 Aug  4  2012 authorized_keys_bak
-rw------- 1 git git  354 Aug  4  2012 authorized_keys_bak2
-rw------- 1 git git 2174 Apr 11 01:13 authorized_keys_bak3
-rw------- 1 git git  160 Apr 10 00:32 config
-rw------- 1 git git 1675 Aug  3  2012 id_rsa
-rw------- 1 git git 1675 Apr 11 01:08 id_rsa_kriscraig_git_CRAIGCOM-LINUX
-rw------- 1 git git  400 Apr 11 01:08 id_rsa_kriscraig_git_CRAIGCOM-LINUX.pub
-rw------- 1 git git 1675 Apr 11 01:09 id_rsa_kriscraig_git_CRAIGCOM-UT3
-rw------- 1 git git  400 Apr 11 01:09 id_rsa_kriscraig_git_CRAIGCOM-UT3.pub
-rw------- 1 git git  951 Apr 10 00:32 id_rsa_kriscraig_gitolite_Kris
-rw------- 1 git git  214 Apr 10 00:33 id_rsa_kriscraig_gitolite_Kris.pub
-rw------- 1 git git  381 Aug  3  2012 id_rsa.pub
-rw------- 1 git git  414 Aug  4  2012 known_hosts

  2. हालांकि यह शायद स्पष्ट है, मेरे पास, वास्तव में, सत्यापित है कि कॉन्फ़िगरेशन में फ़ाइल पथ सही हैं।

  3. मैंने कई बार नई कुंजी बनाने / वितरित करने की कोशिश की है।

    मैंने पहले से ही विंडोज पर काम करने वाले लोगों को कॉपी / पेस्ट करने की कोशिश की, यहां तक ​​कि यह सुनिश्चित करने के लिए कि हम किसी भी एन्कोडिंग मुद्दों (CRLF / LF, आदि) के साथ काम नहीं कर रहे थे dos2unix का उपयोग करने के लिए जा रहे हैं।

    मैंने मानक दृष्टिकोण का उपयोग करके चाबियाँ तैयार कीं: 

    ssh-keygen -t rsa

  4. मैंने पैरेंट होम डाइरेक्टरीज़ की अनुमतियों के साथ खेलने का प्रयास किया है।

  5. मैंने स्थानीय कॉन्फिग्स के साथ-साथ / etc / ssh / * _ कॉन्फिगर के साथ टिंकर किया

    और हाँ, मैंने हर बार sshd को पुनः आरंभ किया। मैं भी बस के मामले में यादृच्छिक अंतराल पर सर्वर रिबूट।

  6. मुझे यकीन है कि मैं कम से कम कुछ चीजें याद कर रहा हूं। मैं हाल ही में नहीं सोया है ...।

    मैं इस बिंदु पर कोई सुझाव लूंगा। अगर यह पता चल जाए तो मैं आपको निराश नहीं करूंगा। =)

मूल ग्राहक / सर्वर जानकारी

सर्वर

  • CentOS 5.9 64-बिट (वर्चुअलबॉक्स)
  • 4 जीबी रैम
  • 200 जीबी एचडीडी (गतिशील आवंटन)
  • 4 सीपीयू
  • ब्रिजिंग नेटवर्किंग (वे सभी एक ही राउटर से कनेक्ट होती हैं)
  • टेस्ट: एन / ए

लिनक्स क्लाइंट # 1

  • CentOS 5.9 64-बिट (वर्चुअलबॉक्स)
  • 1 जीबी रैम
  • 15 जीबी एचडीडी (गतिशील आवंटन)
  • 1 सीपीयू
  • ब्रिजिंग नेटवर्किंग
  • टेस्ट: विफल

लिनक्स क्लाइंट # 2

  • सर्वर ही। कुछ संभावनाओं को नियंत्रित करने का एक अच्छा तरीका है
  • टेस्ट: विफल

विंडोज क्लाइंट

  • विंडोज 7 अल्टीमेट 64-बिट (वर्चुअलबॉक्स के लिए होस्ट)
  • 32 जीबी रैम
  • 200 जीबी एचडीडी
  • 731 जीबी एचडीडी
  • 232 जीबी एचडीडी
  • 465 जीबी एचडीडी
  • 2.72 टीबी एचडीडी
  • 16 सीपीयू
  • टेस्ट: सफलता

डीबग जानकारी (संवेदनशील डेटा redacted)

सर्वर

दो विफल ssh प्रयासों के लिए परिणामी प्रविष्टियाँ / var / log / सुरक्षित: 

    Apr 11 22:21:45 CRAIGCOM-LINUX sshd[14738]: Connection from (WAN IP) port 35326
    Apr 11 22:21:45 CRAIGCOM-LINUX sshd[14739]: Connection closed by (WAN IP)
    Apr 11 22:21:52 CRAIGCOM-LINUX sshd[14741]: Connection from (WAN IP) port 35328
    Apr 11 22:21:52 CRAIGCOM-LINUX sshd[14742]: Connection closed by (WAN IP)

लिनक्स ग्राहक (अनिवार्य रूप से दोनों के लिए समान हैं) 

    [kris@CRAIGCOM-LINUX .ssh]$ ssh git@CRAIGCOM-LINUX -vvv
    OpenSSH_4.3p2, OpenSSL 0.9.8e-fips-rhel5 01 Jul 2008
    debug1: Reading configuration data /home/kris/.ssh/config
    debug1: Applying options for CRAIGCOM-LINUX
    debug1: Reading configuration data /etc/ssh/ssh_config
    debug1: Applying options for *
    debug2: ssh_connect: needpriv 0
    debug1: Connecting to (SERVER HOST) [(SERVER IP)] port 22.
    debug1: Connection established.
    debug1: identity file "/home/kris/.ssh/id_rsa_kriscraig_git_CRAIGCOM-LINUX" type -1
    debug1: loaded 1 keys
    debug1: Remote protocol version 2.0, remote software version OpenSSH_4.3
    debug1: match: OpenSSH_4.3 pat OpenSSH*
    debug1: Enabling compatibility mode for protocol 2.0
    debug1: Local version string SSH-2.0-OpenSSH_4.3
    debug2: fd 3 setting O_NONBLOCK
    debug1: SSH2_MSG_KEXINIT sent
    debug1: SSH2_MSG_KEXINIT received
    debug2: kex_parse_kexinit: diffie-hellman-group-exchange-sha1,diffie-hellman-group14-sha1,diffie-hellman-group1-sha1
    debug2: kex_parse_kexinit: ssh-rsa,ssh-dss
    debug2: kex_parse_kexinit: aes128-ctr,aes192-ctr,aes256-ctr,arcfour256,arcfour128,aes128-cbc,3des-cbc,blowfish-cbc,cast128-cbc,aes192-cbc,aes256-cbc,arcfour,rijndael-cbc@lysator.liu.se
    debug2: kex_parse_kexinit: aes128-ctr,aes192-ctr,aes256-ctr,arcfour256,arcfour128,aes128-cbc,3des-cbc,blowfish-cbc,cast128-cbc,aes192-cbc,aes256-cbc,arcfour,rijndael-cbc@lysator.liu.se
    debug2: kex_parse_kexinit: hmac-md5,hmac-sha1,hmac-ripemd160,hmac-ripemd160@openssh.com,hmac-sha1-96,hmac-md5-96
    debug2: kex_parse_kexinit: hmac-md5,hmac-sha1,hmac-ripemd160,hmac-ripemd160@openssh.com,hmac-sha1-96,hmac-md5-96
    debug2: kex_parse_kexinit: none,zlib@openssh.com,zlib
    debug2: kex_parse_kexinit: none,zlib@openssh.com,zlib
    debug2: kex_parse_kexinit: 
    debug2: kex_parse_kexinit: 
    debug2: kex_parse_kexinit: first_kex_follows 0 
    debug2: kex_parse_kexinit: reserved 0 
    debug2: kex_parse_kexinit: diffie-hellman-group-exchange-sha1,diffie-hellman-group14-sha1,diffie-hellman-group1-sha1
    debug2: kex_parse_kexinit: ssh-rsa,ssh-dss
    debug2: kex_parse_kexinit: aes128-ctr,aes192-ctr,aes256-ctr,arcfour256,arcfour128,aes128-cbc,3des-cbc,blowfish-cbc,cast128-cbc,aes192-cbc,aes256-cbc,arcfour,rijndael-cbc@lysator.liu.se
    debug2: kex_parse_kexinit: aes128-ctr,aes192-ctr,aes256-ctr,arcfour256,arcfour128,aes128-cbc,3des-cbc,blowfish-cbc,cast128-cbc,aes192-cbc,aes256-cbc,arcfour,rijndael-cbc@lysator.liu.se
    debug2: kex_parse_kexinit: hmac-md5,hmac-sha1,hmac-ripemd160,hmac-ripemd160@openssh.com,hmac-sha1-96,hmac-md5-96
    debug2: kex_parse_kexinit: hmac-md5,hmac-sha1,hmac-ripemd160,hmac-ripemd160@openssh.com,hmac-sha1-96,hmac-md5-96
    debug2: kex_parse_kexinit: none,zlib@openssh.com
    debug2: kex_parse_kexinit: none,zlib@openssh.com
    debug2: kex_parse_kexinit: 
    debug2: kex_parse_kexinit: 
    debug2: kex_parse_kexinit: first_kex_follows 0 
    debug2: kex_parse_kexinit: reserved 0 
    debug2: mac_init: found hmac-md5
    debug1: kex: server->client aes128-ctr hmac-md5 none
    debug2: mac_init: found hmac-md5
    debug1: kex: client->server aes128-ctr hmac-md5 none
    debug1: SSH2_MSG_KEX_DH_GEX_REQUEST(1024<1024<8192) sent
    debug1: expecting SSH2_MSG_KEX_DH_GEX_GROUP
    debug2: dh_gen_key: priv key bits set: 118/256
    debug2: bits set: 484/1024
    debug1: SSH2_MSG_KEX_DH_GEX_INIT sent
    debug1: expecting SSH2_MSG_KEX_DH_GEX_REPLY
    debug3: check_host_in_hostfile: filename /home/kris/.ssh/known_hosts
    debug3: check_host_in_hostfile: match line 1
    debug3: check_host_in_hostfile: filename /home/kris/.ssh/known_hosts
    debug3: check_host_in_hostfile: match line 1
    debug1: Host '(SERVER HOST)' is known and matches the RSA host key.
    debug1: Found key in /home/kris/.ssh/known_hosts:1
    debug2: bits set: 522/1024
    debug1: ssh_rsa_verify: signature correct
    debug2: kex_derive_keys
    debug2: set_newkeys: mode 1
    debug1: SSH2_MSG_NEWKEYS sent
    debug1: expecting SSH2_MSG_NEWKEYS
    debug2: set_newkeys: mode 0
    debug1: SSH2_MSG_NEWKEYS received
    debug1: SSH2_MSG_SERVICE_REQUEST sent
    debug2: service_accept: ssh-userauth
    debug1: SSH2_MSG_SERVICE_ACCEPT received
    debug2: key: "/home/kris/.ssh/id_rsa_kriscraig_git_CRAIGCOM-LINUX" ((nil))
    debug1: Authentications that can continue: publickey,gssapi-with-mic,password
    debug3: start over, passed a different list publickey,gssapi-with-mic,password
    debug3: preferred publickey
    debug3: authmethod_lookup publickey
    debug3: remaining preferred: 
    debug3: authmethod_is_enabled publickey
    debug1: Next authentication method: publickey
    debug1: Trying private key: "/home/kris/.ssh/id_rsa_kriscraig_git_CRAIGCOM-LINUX"
    debug3: no such identity: "/home/kris/.ssh/id_rsa_kriscraig_git_CRAIGCOM-LINUX"
    debug2: we did not send a packet, disable method
    debug1: No more authentication methods to try.
    Permission denied (publickey,gssapi-with-mic,password).

यह वह जगह है जहां मैं फंस गया हूं

जैसा कि आप लॉग से देख सकते हैं, यह निजी कुंजी फ़ाइल खोलने का प्रयास करने के बाद "ऐसी कोई पहचान नहीं" लौटा रहा है। मुझे लगता है कि यह अस्वीकृति क्लाइंट-साइड पर हो रही है। जहाँ तक मैं बता सकता हूँ, यह सर्वर को कुछ भी नहीं भेज रहा है, जो भी; सिर्फ कनेक्शन खोलना और अचानक बंद करना।

मेरे जीवन के लिए, मैं यह पता नहीं लगा सकता कि यह दोनों CentOS बॉक्सों की मुख्य फाइलों पर बारफिंग क्यों है! अनुमतियाँ पूरी तरह से सेट हैं, फाइलें पढ़ने योग्य हैं, न तो सर्वर SELinux का उपयोग कर रहा है, वही चाबियाँ विंडोज क्लाइंट आदि से पूरी तरह से ठीक काम कर रही हैं

मैं अच्छा पहन रहा हूँ sysadmin टोपी; लेकिन दिन के अंत में, मैं एक डेवलपर हूं, आईटी व्यक्ति नहीं। SSH डिबगिंग के इस स्तर ने मुझे अपनी विशेषज्ञता के क्षेत्र से बाहर कर दिया है। मुझे यह कहने से नफरत है, लेकिन मैंने केवल विचारों से बाहर भाग लिया है। हर एक चीज़ के अनुसार जो मुझे इंटर्नेट पर मिल रहा है, यह काम करना चाहिए। लेकिन ऐसा नहीं है। मैं क्या खो रहा हूँ?

आपकी सहायताके लिए धन्यवाद! उम्मीद है, आप में से एक इस मुद्दे को पहचानेगा और मेरी गांड को सही दिशा में बूट करेगा। यदि आपको किसी और विवरण की आवश्यकता है, तो कृपया बेझिझक पूछें।

--Kris

linux  git  ssh  centos  openssh 
— Kris Craig
स्रोत
ओह और हाँ, उचित सार्वजनिक कुंजी स्ट्रिंग को अधिकृत_की में जोड़ा गया है। लेकिन जैसा मैंने कहा, मुझे नहीं लगता कि यह अब तक हो रहा है।
एक बात जो मैं बताऊंगा कि सर्वर (क्लाइंट # 2) और क्लाइंट # 1 सही मशीन पर बात कर रहे हैं। आपने उल्लेख किया है कि क्या आप कनेक्ट करने के लिए DNS या IP का उपयोग कर रहे हैं (हालाँकि आपका एग्जाम CRAIGCOM-LINUX नाम का उपयोग करता है)
— tink
मैंने सर्वर पर जाँच / var / log / safe करके इसे सत्यापित किया। यह हर बार कनेक्शन प्राप्त कर रहा था; हालाँकि, लिनक्स क्लाइंट ने बिना कोई डेटा भेजे वास्तव में उन्हें खोलने के तुरंत बाद कनेक्शन बंद कर दिया।
1
@calspring क्या आपने पूरी पोस्ट पढ़ी है? अनुमतियों को सत्यापित करना मेरी पहली कोशिश थी। इसके अलावा, यह कुछ भी नहीं है, जो भी Gitolite के साथ क्या करना है। गीटलाइट क्रेडेंशियल्स वे नहीं हैं जिन्हें अस्वीकार किया जा रहा है। अस्वीकार किए जा रहे क्रेडेंशियल सर्वर से कनेक्ट करने के लिए उपयोग किए जाने वाले हैं। लॉग मैं इसे बहुत स्पष्ट रूप से विस्तार से प्रदान करता हूं, इसलिए मुझे यह धारणा मिल रही है कि आपने वास्तव में मेरी पोस्ट को नहीं पढ़ा है।
— Kris Craig
1
जहाँ तक हार्डवेयर स्पेक्स चलते हैं, एक अच्छा QA इंजीनियर कभी भी वैरिएबल को वैरिएबल डिस्काउंट नहीं देता है, भले ही वे फैक्टर होने की संभावना न हो। इस तरह की समस्या का निवारण करने का सबसे अच्छा तरीका वैज्ञानिक पद्धति का उपयोग करना है, जो मांग करता है कि परीक्षण परिणामों की विश्वसनीयता सुनिश्चित करने के लिए अज्ञात चर को कम से कम रखा जाए। मैंने बहुत स्पष्ट रूप से हार्डवेयर स्पेक्स को अलग कर दिया है ताकि वे अधिक प्रासंगिक डेटा को मसल न सकें।
— Kris Craig

जवाबों:

2

कृपया ssh- एजेंट का उपयोग करें।

  • पहले एजेंट को अपनी कुंजी जोड़ें: ssh-add ~/.ssh/$keyfile।
  • फिर सत्यापित करें कि कुंजी सफलतापूर्वक लोड की गई है: ssh-add -l
  • फिर अपने दूरस्थ बॉक्स में ssh करने का प्रयास करें। (एजेंट को प्रमाणीकरण करना चाहिए।)

यदि वास्तव में आपकी कुंजी के साथ कोई समस्या है, तो आपको इसे जोड़ने का प्रयास करते समय एक बार ध्यान देना चाहिए।

— michas
स्रोत
यह अनिवार्य रूप से केवल उन चरणों को स्वचालित करेगा जो पहले से ही मैन्युअल रूप से उठाए गए थे। Ssh- एजेंट उपयोगिता, कम से कम जहाँ तक मैं बता सकता हूँ, वास्तव में ऐसा कुछ भी नहीं करेगा जो पहले से नहीं किया गया है।
— Kris Craig
Ssh-agent का बिंदु मुख्य प्रबंधन को वास्तविक कनेक्शन से अलग कर रहा है और इसलिए आपकी स्थिति को डीबग करने का सही उपकरण है। परिणाम के आधार पर आप जानते हैं कि समस्या के लिए कहाँ देखना है। - इसलिए फिर सवाल: क्या ssh-add आपकी समस्याओं के बिना आयात करने में सक्षम है?
— michas
ऐसा लगता है कि आप ~ / .shsh निर्देशिका को नहीं तोड़ सकते हैं, sudo ssh -i id_rsa_kriscraig_git_CRAIGCOM-LINUX उपयोगकर्ता @ ip का प्रयास करें, अगर यह काम करता है, तो आपको chmod + x ~ / .ssh / * और chmod 700 ~ / .ssh chmod 600 की आवश्यकता है। ~ / .ssh / *
— linuxdev2013
हमारी साइट का प्रयोग करके, आप स्वीकार करते हैं कि आपने हमारी Cookie Policy और निजता नीति को पढ़ और समझा लिया है।
Licensed under cc by-sa 3.0 with attribution required.