إصلاح: ssh_exchange_identification & lsquo ؛ الاتصال مغلق بواسطة مضيف بعيد & rsquo ؛

بينما في كثير من الحالات 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 Upgrade ومعرفة ما إذا كان ذلك يعمل على إصلاح أي حزم معطلة قد تكون قد تعرضت لها.

الطريقة الثانية: تصحيح تجزئة الذاكرة

إذا لم يساعد ذلك ، فقد تواجه مشكلة في الجانب المضيف من المعادلة. لا تحتوي الأجهزة المضيفة التي تعمل داخل جهاز افتراضي دائمًا على قسم تبديل ، مما قد يؤدي إلى تجزئة الذاكرة. قم بالوصول إلى المضيف من خلال بعض الوسائل الأخرى ، ربما ماديًا إن أمكن ، ثم أعد تشغيل أي خدمات تعاني من مشاكل. قد يكون الجاني هو MySQL و Apache و nginx وغيرها من الخدمات المماثلة.

على الرغم من أنه قد لا يكون من الممكن دائمًا إعادة تشغيل المضيف ، إلا أن هذا يمكن أن يصحح المشكلة وقد يكون فكرة جيدة إذا كنت تقوم بالتبديل بين رسالة الخطأ هذه والرسالة التي تعرض عنوان IP. ضع في اعتبارك أنه إذا كان لديك أي نوع من الوصول إلى الخادم ، فيمكنك تشغيل الأمر vmstat -s والحصول على بعض الإحصائيات المهمة حول كيفية استخدام الذاكرة حتى كمستخدم عادي في كثير من الحالات.

الطريقة الثالثة: تحقق من وجود مثيلات إضافية لـ ssh

باستثناء ذلك ، تحقق لمعرفة ما إذا كان المضيفون يحاولون الاتصال بالخادم. ربما تكون قد تجاوزت الحد الأقصى لعدد جلسات ssh دون معرفة ذلك. امسح الجلسات القديمة ثم حاول إعادة الاتصال. إحدى الطرق السهلة للقيام بذلك هي تشغيل الأمر who لمعرفة عمليات المستخدم التي تم تسجيل الدخول إليها. يجب أن ترى مستخدمًا واحدًا أو اثنين فقط قام بتسجيل الدخول. إذا كان هناك عدد من العمليات المتوازية ، فقم بإيقاف عمليات المستخدم وحاول تسجيل الدخول مرة أخرى .

قد يحدث هذا إذا لم يتمكن sshd من مواكبة البرنامج النصي الذي يبدأ العديد من جلسات ssh المختلفة في حلقة. إذا حدث هذا لك في أي وقت ، فقم بإضافة الأمر sleep 0.3 إلى الحلقة بحيث يكون لدى عفريت sshd الوقت لمواكبة ذلك.

الطريقة الرابعة: ابحث عن حد اتصال sshd

تنتشر مشكلات الاتصال مثل هذه بشكل خاص عند محاولة استخدام ssh للوصول إلى جهاز توجيه أو نوع آخر من المحولات المعبأة المنفصلة نظرًا لأن الحد الأقصى الافتراضي لعدد الاتصالات صغير جدًا. بينما لا تريد السماح لنفسك بزيادة التحميل على الخادم ، يمكنك إلقاء نظرة على الإعداد الافتراضي.

حاول التشغيل على الخادم للعثور على عدد الاتصالات التي يمكن لـ sshd التعامل معها. في معظم الحالات ، يجب أن يكون النظام افتراضيًا على 10 اتصالات متزامنة ، وهو ما يجب أن يكون كثيرًا لمعظم هياكل الخادم التي من المحتمل أن يحتاجها غالبية المستخدمين إلى استخدام ssh بانتظام.