بينما في كثير من الحالات ssh_exchange_identification: الاتصال مغلق بسبب خطأ في المضيف البعيد يمكن أن يكون ناتجًا عن مشكلات تتعلق بملفات التكوين hosts.deny و hosts.allow ، هناك أشياء أخرى يمكن أن تسبب المشكلة. إذا كنت تقرأ هذا ، فمن المحتمل أنك قد تحققت بالفعل للتأكد من أن كلا الملفين لم يحظر عنوان IP الخاص بك من محاولة استخدام ssh على خادم بعيد.
بافتراض أن هذا هو الحال ، فقد تبحث في مشكلة تبعية أو شيء متعلق بتجزئة الذاكرة أو حتى عدد كبير من الجلسات القادمة من عملاء فرديين. الخبر السار هو أنه بمجرد معالجة المشكلة ، يجب ألا ترى الخطأ مرة أخرى.
الطريقة الأولى: إصلاح التبعيات المفقودة
إذا كنت قد حصلت على ssh_exchange_identification: الاتصال مغلق بسبب خطأ في المضيف البعيد فقط بعد تحديث OpenSSL أو glibc ، فربما تبحث في تبعية مفقودة. يركض sudo lsof -n | grep ssh | grep DEL من سطر الأوامر في هذه الحالة. سيعطيك هذا قائمة بالملفات المفتوحة ، ثم ابحث فقط عن الملفات التي تم حذفها مؤخرًا المتعلقة ببرنامج ssh.
إذا لم تسترد أي شيء ، فلا يزال بإمكانك محاولة إعادة تشغيل البرنامج الخفي أو النظام نفسه. سترغب في إعادة المحاولة إذا تم إلقاء عدد من الأخطاء عليك مرة أخرى ، على الرغم من أنه يمكنك بأمان تجاهل تلك المتعلقة برسائل / تشغيل / مستخدم / 1000 / gvfs لأن هذه ناجمة عن مشكلة غير ذات صلة يجب أن تفعل مع نظام الملفات الظاهري.
يمكنك محاولة استخدام apt-get أو pacman أو yum لتحديث الحزم الخاصة بك أيضًا إذا كنت تشك في أن التبعيات تمثل مشكلة. إذا كنت تستخدم نظامًا قائمًا على Debian أو Ubuntu ، فقد ترغب في المحاولة sudo apt-get -f الترقية ومعرفة ما إذا كان ذلك يؤدي إلى إصلاح أي حزم مكسورة ربما تكون قد تعرضت لها.
الطريقة الثانية: تصحيح تجزئة الذاكرة
إذا لم يساعد ذلك ، فقد تواجه مشكلة في الجانب المضيف من المعادلة. لا تحتوي المضيفات التي تعمل داخل جهاز افتراضي دائمًا على قسم تبديل ، مما قد يؤدي إلى تجزئة الذاكرة. قم بالوصول إلى المضيف من خلال بعض الوسائل الأخرى ، ربما ماديًا إن أمكن ، ثم أعد تشغيل أي خدمات تعاني من مشاكل. قد يكون الجاني هو MySQL و Apache و nginx وغيرها من الخدمات المماثلة.
على الرغم من أنه قد لا يكون من الممكن دائمًا إعادة تشغيل المضيف ، فإن هذا يمكن أن يصحح المشكلة وقد يكون فكرة جيدة إذا كنت تقوم بالتبديل بين رسالة الخطأ هذه والرسالة التي تعرض عنوان IP. ضع في اعتبارك أنه إذا كان لديك أي نوع من الوصول إلى الخادم ، فيمكنك تشغيل ملف vmstat -s الأمر والحصول على بعض الإحصائيات المهمة حول كيفية استخدام الذاكرة حتى كمستخدم عادي في كثير من الحالات.
الطريقة الثالثة: تحقق من وجود مثيلات إضافية لـ ssh
باستثناء ذلك ، تحقق لمعرفة ما إذا كان المضيفون يحاولون الاتصال بالخادم. ربما تكون قد تجاوزت الحد الأقصى لعدد جلسات ssh دون معرفة ذلك. امسح الجلسات القديمة ثم حاول إعادة الاتصال. إحدى الطرق السهلة للقيام بذلك هي تشغيل ملف منظمة الصحة العالمية الأمر لمعرفة عمليات المستخدم التي تم تسجيل الدخول إليها. يجب أن ترى مستخدمًا واحدًا أو اثنين فقط قام بتسجيل الدخول. إذا كان هناك عدد من العمليات المتوازية ، فقم بإيقاف عمليات المستخدم وحاول تسجيل الدخول مرة أخرى.
قد يحدث هذا إذا تعذر على sshd مواكبة البرنامج النصي الذي يبدأ العديد من جلسات ssh المختلفة في حلقة. إذا حدث هذا لك من قبل ، فقم بإضافة النوم 0.3 الأمر إلى الحلقة بحيث يكون لدى عفريت sshd الوقت لمواكبة ذلك.
الطريقة الرابعة: ابحث عن حد اتصال sshd
تنتشر مشاكل الاتصال مثل هذه بشكل خاص عند محاولة استخدام ssh للوصول إلى جهاز توجيه أو نوع آخر من المحولات المعبأة المنفصلة لأن الحد الأقصى الافتراضي لعدد الاتصالات صغير جدًا. بينما لا تريد السماح لنفسك بزيادة التحميل على الخادم ، يمكنك إلقاء نظرة على الإعداد الافتراضي.
جرب الجري 
على الخادم للعثور على عدد الاتصالات التي يمكن لـ sshd التعامل معها. في معظم الحالات ، يجب أن يكون النظام افتراضيًا على 10 اتصالات متزامنة ، وهو ما يجب أن يكون كثيرًا لمعظم هياكل الخادم التي من المحتمل أن يحتاجها غالبية المستخدمين إلى استخدام ssh بانتظام.
