যদিও অনেক ক্ষেত্রে ssh_exchange_identification:দূরবর্তী হোস্ট এরর দ্বারা সংযোগ বন্ধ হয়ে যাওয়া hosts.deny এবং hosts.allow কনফিগারেশন ফাইলগুলির সাথে সম্পর্কিত সমস্যার কারণে হতে পারে, অন্যান্য বিষয় রয়েছে যা সমস্যার কারণ হতে পারে। আপনি যদি এটি পড়ে থাকেন, তাহলে সম্ভাবনা রয়েছে যে আপনি ইতিমধ্যেই পরীক্ষা করে দেখেছেন যে এই দুটি ফাইলই আপনার আইপি ঠিকানাটিকে দূরবর্তী সার্ভারে ssh ব্যবহার করার চেষ্টা থেকে ব্লক করছে না।
ধরে নিই যে এই ঘটনাটি, তাহলে আপনি একটি নির্ভরতা সমস্যা, মেমরি ফ্র্যাগমেন্টেশন সম্পর্কিত কিছু বা এমনকি স্বতন্ত্র ক্লায়েন্টদের কাছ থেকে আসা অতিরিক্ত সংখ্যক সেশনের দিকে তাকিয়ে থাকতে পারেন। ভাল খবর হল যে আপনি একবার সমস্যাটির যত্ন নেওয়ার পরে আপনি আর ত্রুটিটি দেখতে পাবেন না৷
পদ্ধতি 1:অনুপস্থিত নির্ভরতা ঠিক করা
আপনি যদি ssh_exchange_identification পেয়ে থাকেন:শুধুমাত্র OpenSSL বা glibc আপডেট করার পরে দূরবর্তী হোস্ট ত্রুটির দ্বারা সংযোগ বন্ধ হয়ে যায়, তাহলে আপনি হয়তো একটি অনুপস্থিত নির্ভরতা দেখছেন। চালান sudo lsof -n | grep ssh | grep DEL এই পরিস্থিতিতে কমান্ড লাইন থেকে। এটি আপনাকে খোলা ফাইলগুলির একটি তালিকা দেবে, তারপর শুধুমাত্র ssh ডেমনের সাথে সম্পর্কিত যেগুলি সম্প্রতি মুছে ফেলা হয়েছে সেগুলি দেখুন৷
আপনি যদি কিছু ফিরে না পান তবে আপনি এখনও ডেমন বা সিস্টেমটি পুনরায় চালু করার চেষ্টা করতে পারেন। যদি কিছু ত্রুটি আপনার দিকে ফিরে আসে তবে আপনি পুনরায় চালু করার চেষ্টা করতে চাইবেন, যদিও আপনি নিরাপদে /run/user/1000/gvfs বার্তাগুলির সাথে সম্পর্কিত সেগুলিকে উপেক্ষা করতে পারেন কারণ এইগুলি একটি সম্পর্কহীন সমস্যার কারণে হয় একটি ভার্চুয়াল ফাইল সিস্টেম দিয়ে করুন।
আপনি আপনার প্যাকেজ আপডেট করার জন্য apt-get, pacman বা yum ব্যবহার করার চেষ্টা করতে পারেন যদি আপনি সন্দেহ করেন যে নির্ভরতা একটি সমস্যা। আপনি যদি ডেবিয়ান বা উবুন্টু ভিত্তিক সিস্টেমে থাকেন, তাহলে আপনি sudo apt-get -f আপগ্রেড চেষ্টা করতে চাইতে পারেন এবং দেখুন যে এটি কোনো ভাঙা প্যাকেজ ঠিক করে কিনা যা আপনি হয়তো পড়ে গেছেন।
পদ্ধতি 2:মেমরি ফ্র্যাগমেন্টেশন সংশোধন করা
যদি এটি সাহায্য না করে, তাহলে সমীকরণের হোস্ট সাইডে আপনার সমস্যা হতে পারে। VM-এর অভ্যন্তরে চলা হোস্টগুলির সবসময় একটি সোয়াপ পার্টিশন থাকে না, যা মেমরি ফ্র্যাগমেন্টেশনের দিকে নিয়ে যেতে পারে। অন্য কোনো উপায়ে হোস্ট অ্যাক্সেস করুন, সম্ভবত শারীরিকভাবে সম্ভব হলে, এবং তারপর সমস্যায় ভুগছেন এমন কোনো পরিষেবা পুনরায় চালু করুন। MySQL, Apache, nginx এবং অন্যান্য এই ধরনের পরিষেবাগুলি অপরাধী হতে পারে৷
যদিও হোস্টটি রিবুট করা সবসময় সম্ভব নাও হতে পারে, এটি সমস্যাটি সংশোধন করতে পারে এবং আপনি যদি এই ত্রুটি বার্তা এবং একটি আইপি ঠিকানা ফেরত দেয় এমন একটির মধ্যে পরিবর্তন করে থাকেন তবে এটি একটি ভাল ধারণা হতে পারে। মনে রাখবেন যে সার্ভারে আপনার যদি কোনো ধরনের অ্যাক্সেস থাকে, তাহলে আপনি vmstat -s চালাতে পারেন কমান্ড করুন এবং অনেক ক্ষেত্রে নিয়মিত ব্যবহারকারী হিসাবেও কীভাবে মেমরি ব্যবহার করা হচ্ছে তার কিছু গুরুত্বপূর্ণ পরিসংখ্যান পান।
পদ্ধতি 3:অতিরিক্ত ssh দৃষ্টান্তগুলি পরীক্ষা করুন৷
এটি বাদ দিয়ে, তারপর হোস্ট সার্ভারের সাথে সংযোগ করার চেষ্টা করছে কিনা তা পরীক্ষা করে দেখুন। আপনি না জেনেই ssh সেশনের সর্বোচ্চ সংখ্যা অতিক্রম করতে পারেন। পুরানো সেশনগুলি সাফ করুন এবং তারপরে পুনরায় সংযোগ করার চেষ্টা করুন। এটি করার একটি সহজ উপায় হল who চালান৷ কোন ব্যবহারকারীর প্রসেসগুলি লগ ইন করা হয়েছে তা দেখার জন্য কমান্ড৷ আপনার শুধুমাত্র এক বা দুইজন ব্যবহারকারীকে লগ ইন করা দেখতে হবে৷ যদি সমান্তরাল কিছু থাকে, তাহলে ব্যবহারকারীর প্রক্রিয়াগুলিকে মেরে ফেলুন এবং আবার লগ ইন করার চেষ্টা করুন৷
এটি ঘটতে পারে যদি sshd একটি স্ক্রিপ্টের সাথে তাল মিলিয়ে চলতে না পারে যা একটি লুপে বিভিন্ন ssh সেশন শুরু করে। যদি কখনও এটি আপনার সাথে ঘটে থাকে, তাহলে sleep 0.3 যোগ করুন লুপে কমান্ড দিন যাতে sshd ডেমনের সময় থাকে।
পদ্ধতি 4:sshd সংযোগ সীমা খুঁজুন
এই ধরনের সংযোগ সমস্যাগুলি বিশেষভাবে প্রচলিত হয় যখন একটি রাউটার বা অন্য ধরনের বিচ্ছিন্ন বক্সযুক্ত সুইচ অ্যাক্সেস করতে ssh ব্যবহার করার চেষ্টা করা হয় কারণ ডিফল্ট সর্বাধিক সংখ্যক সংযোগ খুবই কম। আপনি যখন সার্ভারকে ওভারলোড করার অনুমতি দিতে চান না, আপনি ডিফল্ট সেটিংস কী তা দেখতে পারেন৷
দৌড়ানোর চেষ্টা করুন সার্ভারে 
sshd কতগুলি সংযোগ পরিচালনা করতে পারে তা খুঁজে বের করতে। বেশিরভাগ ক্ষেত্রে, সিস্টেমটি 10টি একযোগে সংযোগে ডিফল্ট হওয়া উচিত, যা বেশিরভাগ সার্ভারের কাঠামোর জন্য প্রচুর হওয়া উচিত যাতে বেশিরভাগ ব্যবহারকারীর নিয়মিত ssh ব্যবহার করার প্রয়োজন হয়৷
