Lai gan daudzos gadījumos ssh_exchange_identification: savienojumu, kuru aizver attālā resursdatora kļūda, var izraisīt problēmas, kas saistītas ar konfigurācijas failiem hosts.deny un hosts.allow, problēmas var izraisīt arī citas lietas. Ja jūs to lasāt, iespējams, ka esat jau pārbaudījis, vai abi šie faili netraucēja jūsu IP adresei mēģināt izmantot ssh attālajā serverī.
Pieņemot, ka tas tā ir, tad jūs varētu aplūkot atkarības problēmu, kaut ko saistītu ar atmiņas sadrumstalotību vai pat pārmērīgu sesiju skaitu no atsevišķiem klientiem. Labā ziņa ir tā, ka pēc problēmas novēršanas kļūdu vairs nevajadzētu redzēt.
1. metode: trūkstošo atkarību novēršana
Ja ssh_exchange_identification: savienojumu ar attālās resursdatora kļūdu ir aizvēris tikai pēc OpenSSL vai glibc atjaunināšanas, iespējams, meklējat trūkstošo atkarību. Palaidiet sudo lsof -n | grep ssh | šajā situācijā satveriet DEL no komandrindas. Tas jums dos atvērto failu sarakstu, pēc tam meklējiet tikai tos, kas nesen tika izdzēsti, kas saistīti ar ssh dēmonu.
Ja neko neatgūsiet, joprojām varat mēģināt restartēt dēmonu vai pašu sistēmu. Jūs mēģināt atsākt, ja vairākas kļūdas patiešām tiek izmestas pie jums, lai gan jūs varat droši ignorēt tās, kas saistītas ar / run / user / 1000 / gvfs ziņojumiem, jo tos izraisa nesaistīta problēma, kurai ir darīt ar virtuālo failu sistēmu.
Varat arī mēģināt izmantot apt-get, pacman vai yum, lai atjauninātu paketes, ja jums ir aizdomas, ka atkarības ir problēma. Ja izmantojat Debian vai Ubuntu balstītu sistēmu, iespējams, vēlēsities izmēģināt sudo apt-get -f jaunināšanu un pārbaudiet, vai tas novērš bojātās paketes, kuras, iespējams, esat pakļāvušās.
2. metode: Atmiņas sadrumstalotības labošana
Ja tas nepalīdzēja, iespējams, ka problēma ir vienādojuma resursdatora pusē. Saimniekiem, kas darbojas VM iekšienē, ne vienmēr ir maiņas nodalījums, kas var izraisīt atmiņas sadrumstalotību. Piekļūstiet resursdatoram ar citiem līdzekļiem, iespējams, fiziski, ja iespējams, un pēc tam restartējiet visus pakalpojumus, kas cieš no problēmām. MySQL, Apache, nginx un citi šādi pakalpojumi var būt vainīgi.
Kaut arī resursdatora pārstartēšana ne vienmēr ir iespējama, tas var novērst problēmu un var būt laba ideja, ja esat mainījis šo kļūdas ziņojumu un tādu, kas atgriež IP adresi. Paturiet prātā, ka, ja jums ir jebkāda veida piekļuve serverim, varat palaist komandu vmstat -s un iegūt svarīgu statistiku par to, kā atmiņa daudzos gadījumos tiek izmantota pat kā parasts lietotājs.
3. metode: pārbaudiet, vai nav papildu ssh gadījumu
Ja tas nav atļauts, pārbaudiet, vai saimnieki mēģina izveidot savienojumu ar serveri. Iespējams, jūs nezinājāt, ka esat pārsniedzis maksimālo ssh sesiju skaitu. Notīriet vecās sesijas un pēc tam mēģiniet izveidot jaunu savienojumu. Viens vienkāršs veids, kā to izdarīt, ir palaist komandu who, lai redzētu, kuri lietotāja procesi ir pieteikušies. Jums vajadzētu redzēt tikai vienu vai divus lietotājus. Ja ir vairāki paralēli, nogaliniet lietotāja procesus un mēģiniet atkal pieteikties. .
Tas var notikt, ja sshd nespēj sekot līdzi skriptam, kas ciklā sāk daudzas dažādas ssh sesijas. Ja tas kādreiz noticis ar jums, pievienojiet komandai miega 0.3 komandu, lai sshd dēmonam būtu laiks sekot līdzi.
4. metode: atrodiet sshd savienojuma ierobežojumu
Šādas savienojuma problēmas ir īpaši izplatītas, mēģinot izmantot ssh, lai piekļūtu maršrutētājam vai cita veida diskrētajam slēdžam, jo noklusējuma maksimālais savienojumu skaits ir tik mazs. Lai gan jūs nevēlaties ļaut sev pārslogot serveri, varat apskatīt noklusējuma iestatījumu.
Mēģiniet palaist 
serverī, lai uzzinātu, cik daudz savienojumu var apstrādāt sshd. Vairumā gadījumu sistēmai pēc noklusējuma vajadzētu būt 10 vienlaicīgiem savienojumiem, kas būtu pietiekami daudzām lielākajai daļai serveru struktūru, kurās lielākajai daļai lietotāju, iespējams, regulāri jālieto ssh.