Labojums: ssh_exchange_identification ‘savienojumu slēdz attālais resursdators’

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, jūs jau pārbaudījāt, 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, tiklīdz esat nokārtojis problēmu, kļūda vairs nav jāredz.

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. Palaist sudo lsof -n | grep ssh | grep DEL no komandrindas šajā situācijā. 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. Ja vairākas kļūdas tomēr tiks atdotas jums, mēģiniet restartēt, lai gan jūs varat droši ignorēt tās, kas saistītas ar / run / user / 1000 / gvfs ziņojumiem, jo ​​tās 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 sistēmu, ieteicams izmēģināt sudo apt-get -f jauninājums un pārbaudiet, vai tas novērš bojātus iepakojumus, ar kuriem jūs, iespējams, esat saskāries.

2. metode: Atmiņas sadrumstalotības labošana

Ja tas nepalīdzēja, iespējams, jums ir problēma 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ētu 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 vmstat -s komandu un iegūstiet svarīgu statistiku par to, kā atmiņa tiek izmantota pat kā parasts lietotājs daudzos gadījumos.

3. metode: pārbaudiet, vai nav papildu ssh gadījumu

Ja tas nav atļauts, tad 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 PVO komandu, 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, tad pievienojiet gulēt 0,3 komandu cilpai, 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. Kaut arī jūs nevēlaties atļaut sev pārslogot serveri, varat apskatīt noklusējuma iestatījumu.

Mēģiniet skriet serverī, lai uzzinātu, cik daudz savienojumu var apstrādāt sshd. Vairumā gadījumu sistēmai pēc noklusējuma jā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.