Vaikka monissa tapauksissa ssh_exchange_identification: Etäkoneen virheen sulkema yhteys voi johtua hosts.deny- ja hosts.allow-määritystiedostoista, ongelman voi aiheuttaa myös muita asioita. Jos luet tätä, olet todennäköisesti jo tarkistanut, että molemmat näistä tiedostoista eivät estäneet IP-osoitettasi yrittämästä käyttää ssh: ää etäpalvelimessa.
Olettaen, että näin on, saatat tarkastella riippuvuusongelmaa, jotain, joka liittyy muistin pirstoutumiseen, tai jopa liiallista istuntojen määrää yksittäisiltä asiakkailta. Hyvä uutinen on, että kun olet hoitanut ongelman, sinun ei pitäisi nähdä virhettä uudelleen.
Tapa 1: Puuttuvien riippuvuuksien korjaaminen
Jos olet saanut ssh_exchange_identification: yhteys suljettu etäisäntävirheellä vasta OpenSSL: n tai glibc: n päivittämisen jälkeen, saatat etsiä puuttuvaa riippuvuutta. Suorita sudo lsof -n | grep ssh | grep DEL komentoriviltä tässä tilanteessa. Tämä antaa sinulle luettelon avoimista tiedostoista ja etsi sitten vain äskettäin poistetut tiedostot, jotka liittyvät ssh-daemoniin.
Jos et saa mitään takaisin, voit silti yrittää käynnistää daemon tai itse järjestelmä uudelleen. Sinun kannattaa kokeilla uudelleenkäynnistystä, jos joukko virheitä heitettiin takaisin sinulle, vaikka voitkin ohittaa / run / user / 1000 / gvfs -viesteihin liittyvät virheet, koska ne johtuvat etuyhteydettömästä ongelmasta, joka on tehdä virtuaalisen tiedostojärjestelmän kanssa.
Voit yrittää päivittää pakettisi myös apt-get-, pacman- tai yum-tiedostoilla, jos epäilet riippuvuuksien olevan ongelma. Jos käytät Debian- tai Ubuntu-pohjaista järjestelmää, sinun kannattaa kokeilla sudo apt-get -f -päivitystä ja tarkistaa, korjaako se kaikki rikkinäiset paketit, joihin olet saattanut törmätä.
Tapa 2: Muistin sirpaloitumisen korjaaminen
Jos tämä ei auta, sinulla voi olla ongelma yhtälön isäntäpuolella. Virtuaalikoneen sisällä toimivilla isännöillä ei aina ole vaihto-osiota, mikä voi johtaa muistin pirstoutumiseen. Käytä isäntää jollakin muulla tavalla, ehkä fyysisesti, jos mahdollista, ja käynnistä sitten kaikki ongelmista kärsivät palvelut uudelleen. MySQL, Apache, nginx ja muut vastaavat palvelut saattavat olla syyllisiä.
Vaikka isännän uudelleenkäynnistäminen ei aina ole mahdollista, se voi korjata ongelman ja saattaa olla hyvä idea, jos olet vaihtanut tätä virheilmoitusta ja IP-osoitteen palauttavaa viestiä. Muista, että jos sinulla on minkäänlainen pääsy palvelimelle, voit suorittaa komennon vmstat -s ja saada tärkeitä tilastoja siitä, kuinka muisti on tottunut tavallisena käyttäjänä monissa tapauksissa.
Tapa 3: Tarkista ylimääräiset ssh-esiintymät
Estä tämä ja tarkista sitten, yrittävätkö isännät muodostaa yhteyden palvelimeen. Olet saattanut ylittää ssh-istuntojen enimmäismäärän tietämättä sitä. Tyhjennä vanhat istunnot ja yritä muodostaa yhteys uudelleen. Yksi helppo tapa tehdä tämä on suorittaa who- komento nähdäksesi mitkä käyttäjäprosessit ovat kirjautuneet sisään. Sinun pitäisi nähdä vain yksi tai kaksi käyttäjää kirjautuneena sisään. Jos on olemassa useita rinnakkaisia, tappaa käyttäjäprosessit ja yritä kirjautua takaisin sisään .
Näin voi käydä, jos sshd ei pysty seuraamaan komentosarjaa, joka aloittaa useita erilaisia ssh-istuntoja silmukassa. Jos näin kävi koskaan sinulle, lisää uni 0.3 -komento silmukkaan, jotta sshd-demonilla on aikaa pysyä mukana.
Tapa 4: Etsi sshd-yhteysraja
Tämänkaltaiset yhteysongelmat ovat erityisen yleisiä, kun yritetään käyttää ssh: tä reitittimen tai muun tyyppisen erillisen koteloidun kytkimen käyttämiseen, koska oletusyhteyksien enimmäismäärä on niin pieni. Vaikka et halua sallia itsesi ylikuormittaa palvelinta, voit katsoa, mikä oletusasetus on.
Yritä suorittaa 
palvelimella selvittääksesi, kuinka monta yhteyttä sshd pystyy käsittelemään. Useimmissa tapauksissa järjestelmän pitäisi oletusarvoisesti olla 10 samanaikaista yhteyttä, minkä pitäisi olla runsaasti useimmille palvelinrakenteille, joissa suurin osa käyttäjistä todennäköisesti tarvitsee käyttää ssh: tä säännöllisesti.