Во многих случаях ошибка `ssh_exchange_identification: Connection closed by remote host` может быть вызвана проблемами с конфигурационными файлами `hosts.deny` и `hosts.allow`, но возможны и другие причины. Если вы читаете это, вы, вероятно, уже убедились, что ни один из этих файлов не блокирует попытки использования `ssh` на удаленном сервере с вашего IP-адреса.
Если это так, проблема может быть связана с зависимостями, фрагментацией памяти или даже чрезмерным количеством входящих сессий от отдельных клиентов. Хорошая новость в том, что после устранения проблемы ошибка больше не появится.
Метод 1: Исправить отсутствующие зависимости
Если ошибка `ssh_exchange_identification: connection closed by remote host` возникает только после обновления `OpenSSL` или `glibc`, проблема может быть связана с отсутствующей зависимостью. В этом случае выполните команду ` sudo lsof -n | grep ssh | grep DEL` из командной строки. Это покажет вам список открытых файлов; затем найдите те, которые были недавно удалены и связаны со службой (демоном) `ssh`.
Если это не принесет результатов, вы все равно можете попробовать перезапустить службу (демон) или саму систему. Перезапуск потребуется, если возникнет несколько ошибок, хотя сообщения, связанные с `/run/user/1000/gvfs`, можно смело игнорировать, поскольку они вызваны несвязанной проблемой с виртуальной файловой системой.
Вы также можете попробовать использовать `apt-get`, `pacman` или `yum` для обновления пакетов, если подозреваете, что проблема связана с зависимостями. Если вы используете систему на основе Debian или Ubuntu, вы можете попробовать `sudo apt-get -f upgrade`, чтобы проверить, исправит ли это какие-либо поврежденные пакеты, с которыми вы могли столкнуться.
Метод 2: Коррекция фрагментации памяти
Если это не поможет, возможно, проблема на стороне хоста. На хостах, работающих внутри виртуальной машины (ВМ), не всегда есть раздел подкачки, что может привести к фрагментации памяти. Попробуйте получить доступ к хосту другими способами, возможно, физически, если это возможно, а затем перезапустите все службы, испытывающие проблемы. Причиной могут быть MySQL, Apache, nginx и другие подобные службы.
Хотя перезапуск хоста не всегда возможен, он может решить проблему и может быть хорошей идеей, если вы периодически получаете это сообщение об ошибке, а затем другое, возвращающее IP-адрес. Имейте в виду, что если у вас есть доступ к серверу, вы можете запустить команду ` vmstat -s` и получить полезную статистику об использовании памяти, даже если вы обычный пользователь.
Третий метод: проверка наличия дополнительных копий SSH.
Если это не причина, проверьте, пытаются ли хосты подключиться к серверу. Возможно, вы неосознанно превысили максимальное количество SSH-сессий. Завершите старые сессии и попробуйте подключиться снова. Простой способ сделать это — выполнить команду ` who` , чтобы увидеть, какие пользовательские процессы вошли в систему. Вы должны увидеть только одного или двух пользователей, вошедших в систему. Если есть несколько параллельных сессий, завершите пользовательские процессы и попробуйте войти снова.
Это может произойти, если sshd не справляется со скриптом, который запускает несколько разных SSH-сессий в цикле. Если у вас такое уже случалось, добавьте команду ` sleep 0.3` в цикл, чтобы дать демону sshd время на синхронизацию.
Метод 4: Определение лимита подключений sshd
Подобные проблемы с подключением особенно часто возникают при попытке доступа к маршрутизатору или другому встроенному адаптеру через SSH, поскольку максимальное количество подключений по умолчанию очень мало. Хотя перегружать сервер нежелательно, можно проверить настройки по умолчанию.
Попробуйте побегать 
Сервер должен быть настроен на обработку определенного количества подключений. В большинстве случаев настройка системы по умолчанию должна составлять 10 одновременных подключений, чего достаточно для большинства серверных архитектур, где большинству пользователей регулярно требуется использовать SSH.
Комментарии закрыты.