Popravek: ssh_exchange_identification 'povezava zaprta z oddaljenim gostiteljem'

Medtem ko lahko v mnogih primerih napako ssh_exchange_identification: Povezava, zaprta z oddaljenim gostiteljem, povzročijo težave, povezane s konfiguracijskima datotekama hosts.deny in hosts.allow, težave lahko povzročijo še druge stvari. Če berete to, potem ste verjetno že preverili, ali obe datoteki vašemu naslovu IP ne preprečujeta uporabe ssh na oddaljenem strežniku.

Če predpostavimo, da je temu tako, potem morda preučujete težavo z odvisnostjo, nekaj, kar je povezano z razdrobljenostjo spomina ali celo prevelikim številom sej posameznih strank. Dobra novica je, da ko ste rešili težavo, napake ne smete več videti.

1. način: Odpravljanje manjkajočih odvisnosti

Če ste ssh_exchange_identification: povezavo zaprli z napako oddaljenega gostitelja šele po posodobitvi OpenSSL ali glibc, potem morda iščete manjkajočo odvisnost. Teči sudo lsof -n | grep ssh | grep DEL iz ukazne vrstice v tej situaciji. Tako boste dobili seznam odprtih datotek, nato pa poiščite samo tiste, ki so bile nedavno izbrisane v povezavi z demonom ssh.

Če ne dobite ničesar nazaj, lahko poskusite znova zagnati demon ali sam sistem. Poskusite znova zagnati, če vam je vrnilo številne napake, čeprav lahko varno prezrete sporočila, povezana s / run / user / 1000 / gvfs, saj jih povzroča nepovezana težava, ki mora storiti z navideznim datotečnim sistemom.

Če sumite, da so odvisnosti težava, lahko poskusite uporabiti tudi apt-get, pacman ali yum za posodobitev paketov. Če uporabljate sistem, ki temelji na Debianu ali Ubuntuju, boste morda želeli poskusiti nadgradnja sudo apt-get -f in preverite, ali je s tem odpravljen kakšen pokvarjen paket, na katerega ste morda padli.

2. metoda: Popravljanje fragmentacije spomina

Če to ni pomagalo, imate morda težavo na gostiteljski strani enačbe. Gostitelji, ki se izvajajo znotraj VM, nimajo vedno swap particije, kar lahko vodi do fragmentacije pomnilnika. Do gostitelja dostopajte na kakšen drug način, morda fizično, če je mogoče, in nato znova zaženite storitve, ki imajo težave. Krivci so lahko MySQL, Apache, nginx in druge take storitve.

Čeprav vnovični zagon gostitelja ni vedno izvedljiv, lahko težavo odpravite in je morda dobra ideja, če ste zamenjali to sporočilo o napaki in sporočilo, ki vrne naslov IP. Upoštevajte, da če imate kakršen koli dostop do strežnika, lahko zaženete vmstat -s ukaz in pridobite nekaj pomembnih statističnih podatkov o tem, kako se pomnilnik v mnogih primerih uporablja tudi kot običajen uporabnik.

3. način: Preverite, ali obstajajo dodatni primeri ssh

Če tega ne izberete, preverite, ali se gostitelji poskušajo povezati s strežnikom. Morda ste presegli največje število sej ssh, ne da bi to vedeli. Počistite stare seje in nato poskusite znova vzpostaviti povezavo. Enostaven način za to je zagon WHO ukaz, da vidite, kateri uporabniški procesi so prijavljeni. Prijavljeni bi morali biti le en ali dva uporabnika. Če je več vzporednih, ubijete uporabniške procese in se poskusite znova prijaviti.

To se lahko zgodi, če sshd ne more slediti skriptu, ki v zanki zažene veliko različnih sej ssh. Če se vam je to kdaj zgodilo, dodajte spanje 0,3 ukaz zanki, tako da ima demon sshd čas, da sledi.

4. način: Poiščite omejitev povezave sshd

Takšne težave s povezavo so še posebej razširjene pri poskusu uporabe ssh za dostop do usmerjevalnika ali druge vrste diskretnega stikalnega stikala, saj je privzeto največje število povezav tako majhno. Čeprav si ne želite dovoliti preobremenitve strežnika, si lahko ogledate, katera privzeta nastavitev je.

Poskusite teči na strežniku, da poiščete, koliko povezav lahko prenaša sshd. V večini primerov bi moral sistem privzeto določiti 10 hkratnih povezav, kar bi moralo biti dovolj za večino strežniških struktur, za katere bo verjetno večina uporabnikov morala redno uporabljati ssh.