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