SSH कनेक्शन: ssh_exchange

9

मैं अपने मैक के माध्यम से दूरस्थ सर्वर से लगभग एक महीने से जुड़ रहा हूं। हालांकि हाल ही में, मैंने ssh dylan @ MY_IP का उपयोग करके कनेक्ट करने का प्रयास किया और मुझे यह संदेश मिला।

ssh_exchange_identification: read: Connection reset by peer

मुझे कुछ नैदानिक जानकारी भी मिली ...

debug1: Reading configuration data /etc/ssh_config
debug1: /etc/ssh_config line 20: Applying options for *
debug1: /etc/ssh_config line 53: Applying options for *
debug2: ssh_connect: needpriv 0
debug1: Connecting to {MY IP{ [MY IP] port 22.
debug1: Connection established.
debug1: identity file /Users/watson/.ssh/id_rsa type -1
debug1: identity file /Users/watson/.ssh/id_rsa-cert type -1
debug3: Incorrect RSA1 identifier
debug3: Could not load "/Users/watson/.ssh/id_dsa" as a RSA1 public key
debug1: identity file /Users/watson/.ssh/id_dsa type 2
debug1: identity file /Users/watson/.ssh/id_dsa-cert type -1
debug1: Enabling compatibility mode for protocol 2.0
debug1: Local version string SSH-2.0-OpenSSH_6.2

कुछ शोध करने के बाद, मैंने निम्नलिखित कोशिश की ...

मेरे राउटर को फिर से शुरू किया
मेरी "ज्ञात_होस्ट" फ़ाइल साफ़ की
मेरी "ज्ञात_होस्ट" फ़ाइल हटा दी गई
मेरे डीएचसीपी का विमोचन और नवीनीकरण किया
मैंने एक अन्य डिवाइस (विंडोज) से पुट्टी का उपयोग करके एक त्रुटि के साथ भी प्रयास किया है

ध्यान दें कि मैंने इस संचार को बाधित करने के लिए सर्वर में कोई बदलाव नहीं किया है।

इसके अलावा, मुझे यकीन नहीं है कि यह समस्या पैदा करेगा, लेकिन मैंने इसे डोमेन नाम के साथ-साथ आईपी से जोड़ा है।

इसके अलावा, मैं दूसरे आईपी पते से सफलतापूर्वक जुड़ने में सक्षम था।

मुझे पता है कि यह कई संसाधनों के साथ एक बड़ा मुद्दा है, लेकिन बहुत सारे समाधान काम नहीं किए और न ही मैंने वास्तव में किसी के लिए किसी भी प्रकार का संकल्प देखा है।

अपडेट करें

मैंने इसे प्रोटोकॉल 1 के लिए मजबूर किया। इसके बजाय "कनेक्शन रीसर्च बाय पीयर", मुझे अब "रिमोट होस्ट द्वारा कनेक्शन बंद कर दिया गया है"। डिबग जानकारी के साथ इसे चलाने से पता चला:

debug1: Reading configuration data /etc/ssh_config
debug1: /etc/ssh_config line 20: Applying options for *
debug1: /etc/ssh_config line 53: Applying options for *
debug2: ssh_connect: needpriv 0
debug1: Connecting to MY_IP [MY_IP] port 22.
debug1: Connection established.
debug1: identity file /Users/watson/.ssh/identity type -1
debug1: identity file /Users/watson/.ssh/identity-cert type -1
ssh_exchange_identification: Connection closed by remote host

macos ssh

— डायलन
स्रोत

क्या आप सार्वजनिक-कुंजी प्रमाणीकरण का उपयोग करते हैं? क्या आपके पास कोई चाबी है /Users/watson/.ssh/id_dsa? फ़ाइल का बैकअप लेने और उसे निकालने का प्रयास करें।

— पाबौक

मैं सार्वजनिक-कुंजी प्रमाणीकरण का उपयोग नहीं करता हूं; हालाँकि, फ़ाइल में एक ही कुंजी है। मैंने फ़ाइल को निकालने की कोशिश की, लेकिन कोई बदलाव नहीं हुआ और कमांड चला रहा है।

— डायलन

अगर यह प्रोटोकॉल संस्करण के साथ एक समस्या है, तो आप प्रोटोकॉल संस्करण 1 के साथ जुड़ने के लिए मजबूर कर सकते हैंssh -1 ...

— wkaha

पोस्ट पर नए संपादन देखें।

— डायलन

4

SSH सर्वर से कनेक्ट होने पर मैंने "ssh_exchange_identification: दूरस्थ होस्ट द्वारा बंद किया गया कनेक्शन" त्रुटि को हल किया है।

जब एक पैकेज को रूट करने के लिए एक एम्बेडेड लिनक्स मशीन से कनेक्ट करने की कोशिश कर रहा था, तो मुझे यह त्रुटि मिली। लाइब्रेरी की बहुत सारी फाइलों को बदल दिया गया, जिसमें लिबासएलएल भी शामिल है।

कनेक्ट करने का प्रयास कर रहा है:

chetic@ubuntu:~$ ssh -v root@192.168.1.100
OpenSSH_6.2p2 Ubuntu-6ubuntu0.3, OpenSSL 1.0.1e 11 Feb 2013
debug1: Reading configuration data /etc/ssh/ssh_config
debug1: /etc/ssh/ssh_config line 19: Applying options for *
debug1: Connecting to SC [192.168.1.100] port 22.
debug1: Connection established.
debug1: identity file /home/delaval/.ssh/id_rsa type 1
debug1: Checking blacklist file /usr/share/ssh/blacklist.RSA-2048
debug1: Checking blacklist file /etc/ssh/blacklist.RSA-2048
debug1: identity file /home/delaval/.ssh/id_rsa-cert type -1
debug1: identity file /home/delaval/.ssh/id_dsa type -1
debug1: identity file /home/delaval/.ssh/id_dsa-cert type -1
debug1: identity file /home/delaval/.ssh/id_ecdsa type -1
debug1: identity file /home/delaval/.ssh/id_ecdsa-cert type -1
debug1: Enabling compatibility mode for protocol 2.0
debug1: Local version string SSH-2.0-OpenSSH_6.2p2 Ubuntu-6ubuntu0.3
ssh_exchange_identification: read: Connection reset by peer

Googling केवल hosts.deny और hosts.allow की जाँच करने का सुझाव देता था, लेकिन मेरी लक्ष्य मशीन में ऐसी कोई फ़ाइल नहीं थी।

रिबूट के बाद (कार्तिक के सुझाव के अनुसार) sshd नहीं चल रहा था। मैंने लक्ष्य पर मैन्युअल रूप से sshd शुरू करने की कोशिश की:

# sshd
OpenSSL version mismatch. Built against 1000002f, you have 1000105f

मैंने /usr/lib/libssl.a को मूल संस्करण से बदल दिया और sshd शुरू कर दिया और चीजें वापस सामान्य हो गईं। समस्या मेरे मामले में मूल रूप से रूट करने के लिए पैकेज में पैकेज में गलत संस्करण के कारण थी।

— Chetic
स्रोत

3

मुझे वही त्रुटि मिल रही थी (लेकिन किसी भी मशीन से, परेशानी वाली मशीन सहित ssh localhost)।

यह तब शुरू हुआ जब मैंने एक उपयोगकर्ता प्रोफ़ाइल को माइग्रेट किया; यानी फ़ाइलों को रूट के रूप में कॉपी करने के बाद, फिर जैसे कमांड कियाchown -R username /Users/username/Destop

वैसे भी, पूरी तरह से अनिश्चित क्यों / var / खाली मालिक को उपयोगकर्ता नाम में बदल दिया गया था, लेकिन sshनिश्चित रूप /var/emptyसे रूट द्वारा स्वामित्व की आवश्यकता है (अन्यथा आपको मिलता है ssh_exchange_identification: read: Connection reset by peer):

    sudo chown root /var/empty

— hunter3740
स्रोत

धन्यवाद! /var/emptyमेरे लिए फिक्स्ड मुद्दे के मालिक को बदलना ।

— येवैन पावलुक

1

यह आपके स्थानीय मशीन के साथ समस्या नहीं है, लेकिन सर्वर साइड में एक समस्या है। इस समस्या के कारण कई कारक हो सकते हैं :

दूरस्थ सर्वर पर /etc/hosts.allow या /etc/hosts.deny कॉन्फ़िगरेशन में परिवर्तन।
भारी सर्वर लोड।

अतीत में, जब मुझे ये समस्याएँ हुई हैं, तो मैंने निम्नलिखित क्रम में दो चीजों में से एक किया है:

उपरोक्त लेख में संदर्भित के रूप में /etc/hosts.allow को संशोधित करें। (और SSH सर्वर को पुनरारंभ करें)
यदि /etc/hosts.allow पहले से ही ऐसा करने की आवश्यकता है, तो बस SSH सर्वर को पुनरारंभ करें (और सावधान रहें कि आप ऐसा कर रहे हैं!)
यदि पुनरारंभ काम नहीं करता है, तो सर्वर कुंजियों को फिर से बनाएं और SSH सर्वर को पुनरारंभ करें (यह जोखिम भरा है, क्योंकि इस मशीन में लॉग इन करने वाले प्रत्येक उपयोगकर्ता को सर्वर के बारे में एक त्रुटि मिलेगी जिसमें चाबियाँ बदल गई हैं)

अधिक बार नहीं, 1 समस्या को हल करता है, लेकिन मुझे कुछ मामलों में 2 करना है .. मैं यह पता लगाने में सक्षम नहीं हूं कि ऐसा क्यों है, केवल यह काम किया है। शायद यह कुंजी प्रस्तुत करने के तरीके के साथ कुछ करना है, या शायद यह किसी तरह से भ्रष्ट हो गया है - मुझे यकीन नहीं है। लेकिन मुझे क्या पता है कि त्रुटि सर्वर के साथ करने के लिए पूरी तरह से कुछ है, और जिस तरह से हैंडशेक होता है जब एसएसएच कनेक्शन यूओ सेट किया जा रहा है।

— कार्तिक रंगराजन
स्रोत

1

मैंने एसएसएच को सिग्विन के साथ स्थापित किया था और मेरे मामले में यह विंडोज फ़ायरवॉल था जो वास्तव में इस त्रुटि का कारण था, इसलिए कनेक्शन को 22 पोर्ट के लिए अनुमति देना सुनिश्चित करें।

— गुमनाम
स्रोत

0

मैं इस मुद्दे को वास्तव में आसानी से हल करने में कामयाब रहा।

सामान्य OS X में आप सिस्टम प्रेफरेंस / शेयरिंग में "रिमोट लॉगिन" को टॉगल करके इसे हल कर सकते हैं।

हालाँकि, अगर यह एक हेडलेस सर्वर है (जैसे कि मेरे मामले में) तो आप (आप सर्वर का नाम) / सेटिंग्स में जाने के लिए OSX सर्वर ऐप का उपयोग कर सकते हैं और "फिर से और फिर से सिक्योर शेल कनेक्शन" टॉगल कर सकते हैं।

— सायरन
स्रोत

1

मैंने यह भी नोट किया कि आप समस्या के आसपास कैसे काम कर सकते हैं, लेकिन यह इसे ठीक नहीं करता है: दूरस्थ लॉगिन को अक्षम करना सिस्टम को गंभीर रूप से प्रभावित करता है, और हर बार किसी विशिष्ट स्थान पर ssh करने के लिए दूरस्थ लॉगिन को टॉगल करना एक व्यवहार्य समाधान नहीं है ।

— Ant6n

हाँ, यह अभी भी एक भयानक मुद्दा है मेरे पास है। मैंने अभी एक रूट क्रोन स्क्रिप्ट बनाई है जो हर आधी रात को सेवा को फिर से शुरू करती है।

— सायरन

0

यदि आप अपने सर्वर पर लॉगिन करने के लिए एक निजी कुंजी या सुरक्षा कुंजी का उपयोग कर रहे हैं तो आपको कमांड का उपयोग करके कुंजी फ़ाइल की अनुमति को 660 में बदलना होगा।

सुडो चामोड 660 File_Name

— श्रीजन चौधरी
स्रोत

1

(१) जबकि यह sshकाम न करने का कारण हो सकता है , यह स्पष्ट नहीं है कि यह समस्या कैसे काम प्रणाली को बेतरतीब ढंग से प्रभावित करेगी। (2) यह उत्तर, जैसे कि यह है, यह अधिक उपयोगी होगा कि आप उस फ़ाइल की पहचान करें जिसके बारे में आप बात कर रहे हैं, या किसी उपयोगकर्ता को इसकी पहचान करने की अनुमति देने के निर्देश दिए हैं। (3) मुझे लगता है कि आप उपयोगकर्ता के होम डायरेक्टरी में (अंडर) एक फाइल के बारे में बात कर रहे हैं। यदि ऐसा है, sudoतो आवश्यक नहीं होना चाहिए।

— स्कॉट

SSH कनेक्शन: ssh_exchange_identifcation

अपडेट करें