În timp ce, în multe cazuri, ssh_exchange_identification: Conexiunea închisă de o eroare de gazdă la distanță poate fi cauzată de probleme legate de fișierele de configurare hosts.deny și hosts.allow, există alte lucruri care pot cauza problema. Dacă citiți acest lucru, este posibil să fi verificat deja pentru a vă asigura că aceste două fișiere nu au blocat adresa IP de la încercarea de a utiliza ssh pe un server la distanță.
Presupunând că acesta este cazul, atunci s-ar putea să vă uitați la o problemă de dependență, ceva legat de fragmentarea memoriei sau chiar un număr excesiv de sesiuni provenind de la clienți individuali. Vestea bună este că, odată ce ați rezolvat problema, nu ar trebui să mai vedeți eroarea.
Metoda 1: Remedierea dependențelor lipsă
Dacă ați obținut ssh_exchange_identification: conexiunea închisă prin eroare de gazdă la distanță numai după actualizarea OpenSSL sau glibc, atunci s-ar putea să vă uitați la o dependență lipsă. Alerga sudo lsof -n | grep ssh | grep DEL din linia de comandă în această situație. Acest lucru vă va oferi o listă de fișiere deschise, apoi căutați doar cele care au fost șterse recent legate de demonul ssh.
Dacă nu obțineți nimic înapoi, puteți încerca să reporniți daemonul sau sistemul în sine. Veți dori să încercați repornirea dacă s-au aruncat înapoi o serie de erori, deși le puteți ignora în siguranță pe cele legate de mesajele / run / user / 1000 / gvfs, deoarece acestea sunt cauzate de o problemă fără legătură care trebuie faceți cu un sistem de fișiere virtual.
Puteți încerca să utilizați apt-get, pacman sau yum pentru a vă actualiza pachetele, de asemenea, dacă bănuiți că dependențele sunt o problemă. Dacă utilizați un sistem Debian sau Ubuntu, atunci ați putea dori să încercați sudo apt-get -f upgrade și vedeți dacă acest lucru remediază pachete sparte de care s-ar putea să fiți afectat.
Metoda 2: Corectarea fragmentării memoriei
Dacă acest lucru nu a ajutat, atunci s-ar putea să aveți o problemă pe partea gazdă a ecuației. Gazdele care rulează în interiorul unei VM nu au întotdeauna o partiție swap, ceea ce poate duce la fragmentarea memoriei. Accesați gazda prin alte mijloace, poate fizic dacă este posibil, apoi reporniți orice servicii care suferă de probleme. MySQL, Apache, nginx și alte astfel de servicii ar putea fi vinovații.
Deși s-ar putea să nu fie întotdeauna posibil să reporniți gazda, acest lucru poate corecta problema și ar putea fi o idee bună dacă ați alternat între acest mesaj de eroare și unul care returnează o adresă IP. Rețineți că, dacă aveți orice fel de acces la server, atunci puteți rula vmstat -s comandați și obțineți câteva statistici importante despre modul în care memoria se folosește chiar și ca utilizator obișnuit în multe cazuri.
Metoda 3: Verificați instanțele ssh suplimentare
Cu excepția acestui lucru, verificați dacă gazdele încearcă să se conecteze la server. Este posibil să fi depășit numărul maxim de sesiuni ssh fără să știți. Ștergeți sesiunile vechi și apoi încercați să vă reconectați. O modalitate ușoară de a face acest lucru este rularea care comanda pentru a vedea ce procese de utilizator sunt conectate. Ar trebui să vedeți doar unul sau doi utilizatori conectați. Dacă există o serie de procese paralele, atunci ucideți procesele utilizatorului și încercați să vă conectați din nou.
Acest lucru se poate întâmpla dacă sshd nu poate ține pasul cu un script care începe multe sesiuni ssh diferite într-o buclă. Dacă ți s-a întâmplat asta vreodată, atunci adaugă dormi 0.3 comanda la buclă, astfel încât demonul sshd să aibă timp să țină pasul.
Metoda 4: Găsiți limita de conexiune sshd
Probleme de conexiune de acest gen sunt deosebit de răspândite atunci când se încearcă utilizarea ssh pentru a accesa un router sau un alt tip de comutator discret, deoarece numărul maxim implicit de conexiuni este atât de mic. Deși nu doriți să vă permiteți să supraîncărcați serverul, puteți arunca o privire la setarea implicită.
Încearcă să alergi 
pe server pentru a găsi câte conexiuni poate gestiona sshd. În cele mai multe cazuri, sistemul ar trebui să fie implicit la 10 conexiuni simultane, ceea ce ar trebui să fie suficient pentru majoritatea structurilor de server pe care este probabil ca majoritatea utilizatorilor să le folosească ssh în mod regulat.
