Kui paljudel juhtudel võivad kaughosti tõrgetega suletud ühenduse põhjustada sünkroonimisveaga suletud ühenduse probleemid, mis on seotud konfiguratsioonifailidega hosts.deny ja hosts.allow, võivad probleemi põhjustada ka muud asjad. Kui loete seda, siis on tõenäoline, et olete juba kontrollinud, kas mõlemad failid ei blokeerinud teie IP-aadressi proovimast kasutada serveris ssh.
Eeldades, et see on nii, siis võite 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 peaks te seda viga enam nägema.
1. meetod: puuduvate sõltuvuste parandamine
Kui olete saidi ssh_exchange_identification: ühendus kaughosti tõrke tõttu sulgenud alles pärast OpenSSL-i või glibc-i värskendamist, võite vaadata puuduvat sõltuvust. Käivitage sudo lsof -n | grep ssh | grep DEL selles olukorras käsurealt. 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 seoseta probleemist, mis peab 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 upgrade'i ja vaadata, kas see parandab rikkis pakette, millega olete vastupidi sattunud.
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 on hea mõte, kui olete selle veateate ja IP-aadressi tagastanud vaheldumisi. Pidage meeles, et kui teil on serverile mingisugune juurdepääs, saate käivitada käsu vmstat -s ja saada mõned olulised statistikad selle kohta, kuidas mälu paljudel juhtudel isegi tavakasutajana harjub .
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. Selle lihtsaks viisiks on käsu kes käivitamine, 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, lisage silmusse käsk sleep 0.3 , 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. Ehkki te ei soovi lubada serveril ülekoormust, võite vaadata, mis on vaikeseade.
Proovige käivitada 
serveris, et leida, mitu ühendust sshd suudab hallata. Enamasti peaks süsteem vaikimisi kasutama 10 üheaegset ühendust, mis peaks olema piisav enamiku serveristruktuuride jaoks, mida tõenäoliselt vajab enamik kasutajaid ssh-d regulaarselt kasutama.