Kui paljudel juhtudel võivad serveri hostiveaga suletud ühenduse põhjustada shsh.exy ja hosts.allow konfiguratsioonifailidega seotud probleemid, võivad probleemi põhjustada ka muud asjad. Kui loete seda, siis on tõenäoline, et olete juba kontrollinud, kas mõlemad need failid ei blokeerinud teie IP-aadressi proovimast kasutada serveris ssh.
Eeldades, et see on nii, siis võiksite uurida sõltuvuse probleemi, midagi, mis on seotud mälu killustumisega, või isegi üksikute klientide liiga palju seansse. Hea uudis on see, et kui olete probleemi lahendanud, ei tohiks te viga enam näha.
1. meetod: puuduvate sõltuvuste parandamine
Kui olete ssh_exchange_identification: ühenduse kaughosti tõrke tõttu sulgenud alles pärast OpenSSL-i või glibc-i värskendamist, siis võib-olla uurite puuduvat sõltuvust. Jookse sudo lsof -n | grep ssh | haara DEL käsurealt selles olukorras. See annab teile avatud failide loendi ja otsige siis ainult neid faile, mis on hiljuti ssh-deemoniga seotud.
Kui te midagi tagasi ei saa, võite siiski proovida deemonit või süsteemi ennast taaskäivitada. Kui arvukaid vigu teile tagasi visatakse, peate proovima taaskäivitamist, kuigi võite ohutult ignoreerida neid, mis on seotud sõnumitega / run / user / 1000 / gvfs, kuna need on põhjustatud mitteseotud probleemist teha virtuaalse failisüsteemiga.
Kui kahtlustate, et sõltuvus on probleem, võite proovida kasutada pakette värskendamiseks ka apt-get, pacman või yum. Kui kasutate Debiani või Ubuntu põhist süsteemi, võiksite proovida sudo apt-get -f uuendus ja vaadake, kas see parandab rikkis pakke, millega olete vastuolus olnud.
2. meetod: mälu killustumise parandamine
Kui see ei aidanud, võib teil olla probleem võrrandi hosti poolel. VM-is töötavatel hostidel pole alati vahetuspartitsiooni, mis võib viia mälu killustumiseni. Juurdepääs hostile mõnel muul viisil, võimalusel füüsiliselt, ja taaskäivitage probleemide käes olevad teenused. Süüdlasteks võivad olla MySQL, Apache, nginx ja muud sellised teenused.
Ehkki hosti taaskäivitamine ei pruugi alati olla võimalik, võib see probleemi lahendada ja võib olla hea mõte, kui olete selle veateate ja IP-aadressi tagastanud vaheldumisi. Pidage meeles, et kui teil on serverile mingisugune juurdepääs, saate selle käivitada vmstat -s käsk ja hankige mõned olulised statistikad selle kohta, kuidas mälu harjub paljudel juhtudel isegi tavakasutajana.
3. meetod: kontrollige, kas pole ekstra ssh-eksemplare
Kui see pole lubatud, siis kontrollige, kas hostid üritavad serveriga ühendust luua. Võib-olla olete ületanud ssh-seansside maksimaalse arvu seda teadmata. Kustutage vanad seansid ja proovige siis uuesti ühendust luua. Üks lihtne viis seda teha on WHO käsk, et näha, millised kasutajaprotsessid on sisse logitud. Peaksite sisse logima ainult ühte või kahte kasutajat. Kui neid on mitu paralleelset, siis tapke kasutajaprotsessid ja proovige uuesti sisse logida.
See võib juhtuda, kui sshd ei suuda sammu pidada skriptiga, mis käivitab tsüklis palju erinevaid ssh-seansse. Kui see kunagi teiega juhtus, siis lisage magama 0,3 käsk silmuse juurde, nii et sshd deemonil oleks aega sammu pidada.
4. meetod: leidke sshd ühenduse piirang
Sellised ühendusprobleemid on eriti levinud, kui proovite kasutada ruuterit või muud tüüpi diskreetsete lülititega ühenduse saamiseks ssh-d, kuna vaikimisi maksimaalne ühenduste arv on nii väike. Kuigi te ei soovi lubada serveril ülekoormust, saate vaadata, mis on vaikeseade.
Proovige joosta 
serveris, et leida, mitu ühendust sshd suudab käsitseda. Enamasti peaks süsteem vaikimisi kasutama 10 üheaegset ühendust, mis peaks olema piisav enamiku serveristruktuuride jaoks, mida enamik kasutajaid peab tõenäoliselt ssh-d regulaarselt kasutama.
