Докато в много случаи грешката ssh_exchange_identification: Връзката, затворена от отдалечен хост, може да бъде причинена от проблеми, свързани с конфигурационните файлове hosts.deny и hosts.allow, има и други неща, които могат да причинят проблема. Ако четете това, тогава вероятно сте проверили дали и двата файла не са блокирали вашия IP адрес да се опитва да използва ssh на отдалечен сървър.
Ако приемем, че това е така, тогава може да разглеждате проблем със зависимостта, нещо, свързано с фрагментация на паметта или дори прекомерен брой сесии, идващи от отделни клиенти. Добрата новина е, че след като се погрижите за проблема, не трябва да виждате грешката отново.
Метод 1: Поправяне на липсващи зависимости
Ако сте получили ssh_exchange_identification: връзката е затворена от грешка на отдалечен хост само след актуализиране на OpenSSL или glibc, тогава може да търсите липсваща зависимост. Изпълнете sudo lsof -n | grep ssh | grep DEL от командния ред в тази ситуация. Това ще ви даде списък с отворени файлове, след което търсете само тези, които наскоро бяха изтрити, свързани с демона ssh.
Ако не получите нищо обратно, пак можете да опитате да рестартирате демона или самата система. Ще искате да опитате рестартиране, ако редица грешки са ви върнати, въпреки че можете безопасно да игнорирате свързаните с / run / user / 1000 / gvfs съобщения, тъй като те са причинени от несвързан проблем, който трябва да направете с виртуална файлова система.
Можете да опитате да използвате apt-get, pacman или yum, за да актуализирате и своите пакети, ако подозирате, че зависимостите са проблем. Ако сте на система, базирана на Debian или Ubuntu, може да опитате надстройка на sudo apt-get -f и да видите дали това коригира счупени пакети, от които може да сте се разпаднали.
Метод 2: Коригиране на фрагментацията на паметта
Ако това не помогне, може да имате проблем от страната на хоста на уравнението. Хостовете, които се изпълняват във виртуална машина, не винаги имат суап дял, което може да доведе до фрагментация на паметта. Достъп до хоста по някакъв друг начин, може би физически, ако е възможно, и след това рестартирайте всички услуги, страдащи от проблеми. Виновниците може да са MySQL, Apache, nginx и други подобни услуги.
Въпреки че не винаги е възможно рестартирането на хоста, това може да коригира проблема и може да е добра идея, ако сте редували това съобщение за грешка и такова, което връща IP адрес. Имайте предвид, че ако имате някакъв достъп до сървъра, тогава можете да изпълните командата vmstat -s и да получите някои важни статистически данни за това как паметта се използва дори като редовен потребител в много случаи.
Метод 3: Проверете за допълнителни ssh екземпляри
Като изключите това, след това проверете дали хостовете се опитват да се свържат със сървъра. Може да сте надвишили максималния брой ssh сесии, без да го знаете. Изчистете старите сесии и опитайте да се свържете отново. Един лесен начин да направите това е да стартирате командата who, за да видите кои потребителски процеси са влезли в системата. Трябва да видите само един или двама потребители, влезли в системата. Ако има няколко паралелни, убийте потребителските процеси и опитайте да влезете отново .
Това може да се случи, ако sshd не може да се справи със скрипт, който стартира много различни ssh сесии в цикъл. Ако това някога се е случило с вас, добавете командата sleep 0.3 към цикъла, така че демонът sshd да има време да се справи.
Метод 4: Намерете sshd Connection Limit
Проблеми с връзките като този са особено разпространени, когато се опитвате да използвате ssh за достъп до рутер или друг тип дискретни превключватели, тъй като максималният брой връзки по подразбиране е толкова малък. Въпреки че не искате да си позволите да претоварвате сървъра, можете да разгледате каква е настройката по подразбиране.
Опитайте да стартирате 
на сървъра, за да намерите колко връзки може да обработи sshd. В повечето случаи системата трябва да зададе по подразбиране 10 едновременни връзки, което би трябвало да е достатъчно за повечето сървърни структури, за които повечето потребители вероятно ще трябва да използват ssh редовно.
