Poprawka: ssh_exchange_identification & lsquo; połączenie zamknięte przez zdalny host & rsquo;

Chociaż w wielu przypadkach błąd ssh_exchange_identification: Connection zamknięte przez błąd zdalnego hosta może być spowodowany problemami z plikami konfiguracyjnymi hosts.deny i hosts.allow, istnieją inne rzeczy, które mogą powodować problem. Jeśli to czytasz, prawdopodobnie sprawdziłeś już, czy oba te pliki nie blokują twojego adresu IP przed próbą użycia ssh na zdalnym serwerze.

Zakładając, że tak jest, możesz mieć do czynienia z problemem zależności, czymś związanym z fragmentacją pamięci lub nawet nadmierną liczbą sesji pochodzących od indywidualnych klientów. Dobra wiadomość jest taka, że ​​po rozwiązaniu problemu błąd nie powinien się więcej pojawiać.

Metoda 1: Naprawianie brakujących zależności

Jeśli otrzymałeś ssh_exchange_identification: połączenie zamknięte przez błąd zdalnego hosta tylko po aktualizacji OpenSSL lub glibc, być może patrzysz na brakującą zależność. Uruchom sudo lsof -n | grep ssh | grep DEL z wiersza poleceń w tej sytuacji. Spowoduje to wyświetlenie listy otwartych plików, a następnie poszukaj tylko tych, które zostały ostatnio usunięte w związku z demonem ssh.

Jeśli nic nie odzyskasz, nadal możesz spróbować ponownie uruchomić demona lub sam system. Będziesz chciał spróbować ponownie uruchomić, jeśli zostanie wyrzuconych wiele błędów, ale możesz bezpiecznie zignorować te związane z wiadomościami / run / user / 1000 / gvfs, ponieważ są one spowodowane przez niepowiązany problem, który musi zrobić z wirtualnym systemem plików.

Możesz spróbować użyć apt-get, pacman lub yum, aby zaktualizować swoje pakiety, jeśli podejrzewasz, że zależności stanowią problem. Jeśli korzystasz z systemu opartego na Debianie lub Ubuntu, możesz wypróbować sudo apt-get -f upgrade i sprawdzić, czy to naprawi uszkodzone pakiety, z którymi mógłbyś się narazić.

Metoda 2: korygowanie fragmentacji pamięci

Jeśli to nie pomogło, możesz mieć problem po stronie hosta równania. Hosty działające wewnątrz maszyny wirtualnej nie zawsze mają partycję wymiany, co może prowadzić do fragmentacji pamięci. Uzyskaj dostęp do hosta w inny sposób, na przykład fizycznie, jeśli to możliwe, a następnie uruchom ponownie wszystkie usługi, w których występują problemy. Winowajcami mogą być MySQL, Apache, nginx i inne tego typu usługi.

Chociaż ponowne uruchomienie hosta może nie zawsze być wykonalne, może to rozwiązać problem i może być dobrym pomysłem, jeśli naprzemiennie wyświetlasz ten komunikat o błędzie i ten, który zwraca adres IP. Pamiętaj, że jeśli masz jakikolwiek dostęp do serwera, możesz uruchomić polecenie vmstat -s i uzyskać ważne statystyki dotyczące wykorzystania pamięci nawet jako zwykły użytkownik w wielu przypadkach.

Metoda 3: Sprawdź, czy istnieją dodatkowe wystąpienia ssh

Zablokuj to, a następnie sprawdź, czy hosty próbują połączyć się z serwerem. Mogłeś przekroczyć maksymalną liczbę sesji ssh, nie wiedząc o tym. Wyczyść stare sesje, a następnie spróbuj połączyć się ponownie. Jednym prostym sposobem na to jest uruchomienie polecenia who, aby sprawdzić, które procesy użytkowników są zalogowane. Powinieneś zobaczyć tylko jednego lub dwóch zalogowanych użytkowników. Jeśli jest kilka równoległych, zakończ procesy użytkownika i spróbuj zalogować się ponownie .

Może się tak zdarzyć, jeśli sshd nie nadąża za skryptem, który uruchamia wiele różnych sesji ssh w pętli. Jeśli kiedykolwiek ci się to przydarzyło, dodaj polecenie sleep 0.3 do pętli, aby demon sshd miał czas na nadążanie.

Metoda 4: Znajdź limit połączenia sshd

Takie problemy z połączeniami są szczególnie powszechne podczas próby użycia ssh do uzyskania dostępu do routera lub innego typu dyskretnego przełącznika pudełkowego, ponieważ domyślna maksymalna liczba połączeń jest tak mała. Chociaż nie chcesz sobie pozwolić na przeciążenie serwera, możesz sprawdzić, jakie jest domyślne ustawienie.

Spróbuj uruchomić na serwerze, aby dowiedzieć się, ile połączeń może obsłużyć sshd. W większości przypadków system powinien domyślnie obsługiwać 10 jednoczesnych połączeń, co powinno wystarczyć dla większości struktur serwerowych, na których większość użytkowników prawdopodobnie będzie musiała regularnie korzystać z ssh.