Remediere: ssh_exchange_identification & lsquo; conexiune închisă de gazdă la distanță & rsquo;

Î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 probabil că ați verificat deja pentru a vă asigura că ambele 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 ai avut grijă de problemă, nu ar trebui să mai vezi 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ă. Rulați 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 bazat pe Debian sau Ubuntu, atunci poate doriți să încercați sudo apt-get -f upgrade și să vedeți dacă acest lucru remediază pachetele defecte de care s-ar putea să fi căzut.

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 fezabil 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 un fel de acces la server, atunci puteți rula comanda vmstat -s și puteți obține câteva statistici importante despre modul în care memoria este folosită 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 comenzii who pentru a vedea ce procese de utilizator sunt conectate. Ar trebui să vedeți doar unul sau doi utilizatori conectați. Dacă există mai multe 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ă comanda sleep 0.3 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ă suprasolicitați serverul, puteți arunca o privire la setarea implicită.

Încercați să rulați 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.