Хотя во многих случаях ошибка 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 upgrade и посмотреть, исправит ли это какие-либо неработающие пакеты, с которыми вы могли столкнуться.
Метод 2: исправление фрагментации памяти
Если это не помогло, то у вас может быть проблема на стороне хоста уравнения. Хосты, которые работают внутри виртуальной машины, не всегда имеют раздел подкачки, что может привести к фрагментации памяти. Получите доступ к хосту каким-либо другим способом, возможно, физически, если это возможно, а затем перезапустите все службы, у которых возникли проблемы. MySQL, Apache, nginx и другие подобные сервисы могут быть виноваты.
Хотя перезагрузка хоста не всегда возможна, это может исправить проблему и может быть хорошей идеей, если вы чередовали это сообщение об ошибке и сообщение, возвращающее IP-адрес. Имейте в виду, что если у вас есть какой-либо доступ к серверу, вы можете запустить команду vmstat -s и получить важную статистику использования памяти даже в качестве обычного пользователя во многих случаях.
Метод 3: проверьте наличие дополнительных экземпляров ssh
Запретив это, проверьте, не пытаются ли хосты подключиться к серверу. Возможно, вы превысили максимальное количество сеансов ssh, не зная об этом. Очистите старые сеансы и попробуйте снова подключиться. Один из простых способов сделать это - запустить команду who, чтобы увидеть, какие пользовательские процессы вошли в систему. Вы должны видеть только одного или двух пользователей, вошедших в систему. Если есть несколько параллельных, то завершите пользовательские процессы и попробуйте снова войти в систему. .
Это может произойти, если sshd не успевает за скриптом, который запускает много разных сеансов ssh в цикле. Если это когда-либо случалось с вами, добавьте в цикл команду sleep 0.3, чтобы демон sshd успел не отставать.
Метод 4: Найдите предел подключения sshd
Подобные проблемы с подключением особенно распространены при попытке использовать ssh для доступа к маршрутизатору или другому типу дискретного коммутатора в штучной упаковке, поскольку максимальное количество подключений по умолчанию очень мало. Хотя вы не хотите позволять себе перегрузить сервер, вы можете посмотреть, каковы настройки по умолчанию.
Попробуйте запустить 
сервер, чтобы узнать, сколько соединений может обрабатывать sshd. В большинстве случаев система должна по умолчанию использовать 10 одновременных подключений, которых должно быть достаточно для большинства серверных структур, которые большинству пользователей могут потребоваться для регулярного использования ssh.
