Zatiaľ čo v mnohých prípadoch môže byť chyba ssh_exchange_identification: Pripojenie ukončené vzdialeným hostiteľom spôsobené problémami súvisiacimi s konfiguračnými súbormi hosts.deny a hosts.allow, problém môžu spôsobiť aj iné veci. Ak toto čítate, je pravdepodobné, že ste už skontrolovali, či oba tieto súbory neblokujú vašu adresu IP v pokusoch o použitie protokolu ssh na vzdialenom serveri.
Za predpokladu, že je to váš prípad, potom sa možno budete zaoberať problémom závislosti, niečím súvisiacim s fragmentáciou pamäte alebo dokonca nadmerným počtom relácií pochádzajúcich od jednotlivých klientov. Dobrou správou je, že akonáhle sa o problém postaráte, už by sa chyba nemala viac zobrazovať.
Metóda 1: Oprava chýbajúcich závislostí
Ak sa vám chyba ssh_exchange_identification: pripojenie ukončila chybou vzdialeného hostiteľa až po aktualizácii OpenSSL alebo glibc, možno hľadáte chýbajúcu závislosť. Bež sudo lsof -n | grep ssh | grep DEL z príkazového riadku v tejto situácii. Takto získate zoznam otvorených súborov. Potom vyhľadajte iba tie, ktoré boli nedávno odstránené a ktoré súvisia s démonom ssh.
Pokiaľ by ste nič nedostali späť, môžete skúsiť reštartovať démona alebo samotný systém. Skúste reštartovať, ak sa na vás vrhne niekoľko chýb, aj keď tie, ktoré súvisia so správami / run / user / 1000 / gvfs, môžete bezpečne ignorovať, pretože sú spôsobené nesúvisiacim problémom, ktorý musí byť robiť s virtuálnym súborovým systémom.
Môžete sa pokúsiť použiť na aktualizáciu svojich balíkov aj apt-get, pacman alebo yum, ak máte podozrenie, že sú závislé problémy. Ak používate systém založený na Debiane alebo Ubuntu, možno budete chcieť vyskúšať aktualizácia sudo apt-get -f a uvidíme, či to napraví všetky rozbité balíčky, na ktoré by si mohol spadnúť.
Metóda 2: Oprava fragmentácie pamäte
Ak to nepomohlo, môžete mať problém na strane hostiteľa rovnice. Hostitelia, ktorí bežia vo vnútri VM, nemajú vždy odkladací oddiel, čo môže viesť k fragmentácii pamäte. Pristupujte k hostiteľovi inými prostriedkami, možno fyzicky, ak je to možné, a potom reštartujte všetky služby trpiace problémami. Vinníkmi môžu byť MySQL, Apache, nginx a ďalšie podobné služby.
Aj keď reštartovanie hostiteľa nemusí byť vždy možné, môže to problém vyriešiť a môže to byť dobrý nápad, ak ste striedali toto chybové hlásenie a chybové hlásenie, ktoré vracia adresu IP. Majte na pamäti, že ak máte akýkoľvek prístup na server, môžete spustiť vmstat -s príkaz a získajte niektoré dôležité štatistiky o tom, ako sa pamäť v mnohých prípadoch využíva aj ako bežný používateľ.
Metóda 3: Skontrolujte ďalšie inštancie ssh
Blokujte to a potom skontrolujte, či sa hostitelia pokúšajú pripojiť k serveru. Možno ste prekročili maximálny počet relácií ssh bez toho, aby ste to vedeli. Vyčistite staré relácie a potom sa skúste znova pripojiť. Jedným z jednoduchých spôsobov, ako to dosiahnuť, je spustiť SZO Príkaz na zistenie, ktoré používateľské procesy sú prihlásené. Mali by ste vidieť iba jedného alebo dvoch prihlásených používateľov. Ak existuje viac paralelných, potom zabite používateľské procesy a skúste sa znova prihlásiť.
To sa môže stať, ak sshd nedokáže držať krok so skriptom, ktorý spúšťa mnoho rôznych relácií ssh v cykle. Ak sa vám to niekedy stalo, pridajte spať 0,3 príkaz do slučky, aby mal démon sshd čas držať krok.
Metóda 4: Vyhľadajte limit pripojenia sshd
Problémy s pripojením, ako je tento, sú obzvlášť rozšírené pri pokuse o použitie protokolu ssh na prístup k smerovaču alebo inému typu samostatného prepínača v krabici, pretože predvolený maximálny počet pripojení je taký malý. Aj keď si nechcete dovoliť preťažiť server, môžete sa pozrieť na to, čo je predvolené nastavenie.
Skúste behať 
na serveri a zistiť, koľko pripojení dokáže sshd zvládnuť. Vo väčšine prípadov by mal systém predvoliť 10 simultánnych pripojení, čo by malo stačiť pre väčšinu serverových štruktúr, ktoré väčšina používateľov pravdepodobne bude musieť pravidelne používať ssh.
