जबकि कई मामलों में ssh_exchange_identification: रिमोट होस्ट द्वारा कनेक्शन बंद त्रुटि hosts.deny और hosts.allow कॉन्फ़िगरेशन फ़ाइलों से संबंधित मुद्दों के कारण हो सकती है, अन्य चीजें भी हैं जो समस्या पैदा कर सकती हैं। यदि आप इसे पढ़ रहे हैं, तो संभावना है कि आपने पहले ही जांच कर ली है कि ये दोनों फ़ाइलें आपके IP पते को रिमोट सर्वर पर ssh का उपयोग करने का प्रयास करने से ब्लॉक नहीं कर रही हैं।
यह मानते हुए कि यह मामला है, तो आप एक निर्भरता समस्या, मेमोरी फ्रैगमेंटेशन से संबंधित कुछ, या व्यक्तिगत क्लाइंट से आने वाले अत्यधिक संख्या में सत्रों को देख रहे होंगे। अच्छी खबर यह है कि एक बार जब आप समस्या का समाधान कर लेते हैं, तो आपको त्रुटि फिर से नहीं दिखाई देनी चाहिए।
विधि 1: लापता निर्भरताओं को ठीक करना
यदि आपको ssh_exchange_identification: रिमोट होस्ट द्वारा कनेक्शन बंद त्रुटि केवल OpenSSL या glibc को अपडेट करने के बाद मिली है, तो आप एक लापता निर्भरता को देख रहे होंगे। इस स्थिति में कमांड लाइन से sudo lsof -n | grep ssh | grep DEL चलाएं। यह खुली फ़ाइलों की एक सूची देगा, फिर केवल उन्हीं को देखें जो हाल ही में ssh डिमन से संबंधित हटाई गई थीं।
यदि आपको कुछ भी वापस नहीं मिलता है, तो आप अभी भी डिमन या सिस्टम को पुनरारंभ करने का प्रयास कर सकते हैं। यदि कई त्रुटियां वापस फेंकी गईं तो आप पुनरारंभ करना चाहेंगे, हालांकि आप /run/user/1000/gvfs संदेशों से संबंधित उन लोगों को सुरक्षित रूप से अनदेखा कर सकते हैं क्योंकि ये एक असंबंधित मुद्दे के कारण होते हैं जो वर्चुअल फ़ाइल सिस्टम से संबंधित है।
यदि आपको संदेह है कि निर्भरताएं एक समस्या हैं, तो आप apt-get, pacman या yum का उपयोग करके अपने पैकेजों को अपडेट करने का प्रयास भी कर सकते हैं। यदि आप Debian या Ubuntu आधारित सिस्टम पर हैं, तो आप sudo apt-get -f upgrade आज़माना चाह सकते हैं और देख सकते हैं कि क्या यह आपके द्वारा सामना किए गए किसी भी टूटे हुए पैकेज को ठीक करता है।
विधि 2: मेमोरी फ्रैगमेंटेशन को ठीक करना
यदि इससे मदद नहीं मिली, तो आपके पास समीकरण के होस्ट पक्ष पर एक समस्या हो सकती है। VM के अंदर चलने वाले होस्ट्स में हमेशा स्वैप पार्टीशन नहीं होता, जिससे मेमोरी फ्रैगमेंटेशन हो सकता है। किसी अन्य माध्यम से होस्ट तक पहुंचें, यदि संभव हो तो भौतिक रूप से, और फिर समस्याओं से पीड़ित किसी भी सेवा को पुनरारंभ करें। MySQL, Apache, nginx और अन्य ऐसी सेवाएं अपराधी हो सकती हैं।
हालांकि होस्ट को रीबूट करना हमेशा संभव नहीं हो सकता, यह समस्या को ठीक कर सकता है और एक अच्छा विचार हो सकता है यदि आप इस त्रुटि संदेश और एक IP पते को लौटाने वाले के बीच बारी-बारी से आ रहे हैं। ध्यान रखें कि यदि आपके पास सर्वर तक किसी भी प्रकार की पहुंच है, तो आप vmstat -s कमांड चला सकते हैं और मेमोरी का उपयोग कैसे किया जा रहा है, इस पर कुछ महत्वपूर्ण आंकड़े प्राप्त कर सकते हैं, यहां तक कि कई उदाहरणों में एक नियमित उपयोगकर्ता के रूप में भी।
विधि 3: अतिरिक्त ssh इंस्टेंस की जांच करना
इसके अलावा, जांचें कि क्या होस्ट सर्वर से कनेक्ट करने का प्रयास कर रहे हैं। हो सकता है कि आप इसे जाने बिना ssh सत्रों की अधिकतम संख्या को पार कर चुके हों। पुराने सत्रों को साफ़ करें और फिर से कनेक्ट करने का प्रयास करें। ऐसा करने का एक आसान तरीका who कमांड चलाना है यह देखने के लिए कि कौन सी उपयोगकर्ता प्रक्रियाएं लॉग इन हैं। आपको केवल एक या दो उपयोगकर्ता लॉग इन दिखाई देने चाहिए। यदि कई समानांतर हैं, तो उपयोगकर्ता प्रक्रियाओं को मारें और फिर से लॉग इन करने का प्रयास करें।
यह तब हो सकता है जब sshd एक लूप में कई अलग-अलग ssh सत्र शुरू करने वाली स्क्रिप्ट के साथ तालमेल नहीं रख पाता। यदि आपके साथ ऐसा कभी हुआ है, तो लूप में sleep 0.3 कमांड जोड़ें ताकि sshd डिमन को तालमेल रखने का समय मिल सके।
विधि 4: sshd कनेक्शन सीमा ढूंढना
इस तरह की कनेक्शन समस्याएं विशेष रूप से तब प्रचलित होती हैं जब राउटर या किसी अन्य प्रकार के डिस्क्रीट बॉक्स्ड स्विच तक पहुंचने के लिए ssh का उपयोग करने का प्रयास किया जाता है क्योंकि डिफ़ॉल्ट अधिकतम कनेक्शन संख्या बहुत कम होती है। जबकि आप खुद को सर्वर को ओवरलोड करने की अनुमति नहीं देना चाहते, आप देख सकते हैं कि डिफ़ॉल्ट सेटिंग क्या है।
सर्वर पर चलाकर यह पता लगाने का प्रयास करें कि sshd कितने कनेक्शन संभाल सकता है। ज्यादातर मामलों में, सिस्टम को 10 एक साथ कनेक्शन पर डिफ़ॉल्ट होना चाहिए, जो अधिकांश सर्वर संरचनाओं के लिए पर्याप्त होना चाहिए जिनका अधिकांश उपयोगकर्ता नियमित रूप से ssh पर उपयोग करने की संभावना रखते हैं।
