ssh_exchange_identification: соединение закрыто удаленным хостом (без использования hosts.deny)

Я не использую hosts.allowили hosts.deny, более того, SSH работает с моей Windows-машины (тот же ноутбук, другой жесткий диск), но не с моей Linux-машины.

ssh -vvv root@host -p port дает:

OpenSSH_6.6, OpenSSL 1.0.1f 6 Jan 2014
debug1: Reading configuration data /etc/ssh/ssh_config
debug1: /etc/ssh/ssh_config line 20: Applying options for *
debug2: ssh_connect: needpriv 0
debug1: Connecting to host [host] port <port>.
debug1: Connection established.
debug1: identity file /home/torxed/.ssh/id_dsa type -1
debug1: identity file /home/torxed/.ssh/id_dsa-cert type -1
debug1: Enabling compatibility mode for protocol 2.0
debug1: Local version string SSH-2.0-OpenSSH_6.6
ssh_exchange_identification: read: Connection reset by peer

На машине с Windows все работает нормально, поэтому я проверил журналы безопасности, и строки в них идентичны, сервер обрабатывает две разные «машины» одинаково, и они оба разрешены через аутентификацию с открытым ключом.

Так что это приводит к выводу, что это должно быть проблемой с моим локальным ноутбуком ArchLinux ... но что?

[torxed@archie ~]$ cat .ssh/known_hosts 
[torxed@archie ~]$ 

Так что это не проблема ..

[torxed@archie ~]$ sudo iptables -L
Chain INPUT (policy ACCEPT)
target     prot opt source               destination         

Chain FORWARD (policy ACCEPT)
target     prot opt source               destination         

Chain OUTPUT (policy ACCEPT)
target     prot opt source               destination 

Нет конфликтов с настройками брандмауэра (пока).

[torxed@archie ~]$ ls -la .ssh/
total 20
drwx------  2 torxed users 4096 Sep  3  2013 .
drwx------ 51 torxed users 4096 May 11 11:11 ..
-rw-------  1 torxed users 1679 Sep  3  2013 id_rsa
-rw-r--r--  1 torxed users  403 Sep  3  2013 id_rsa.pub
-rw-r--r--  1 torxed users  170 May 11 11:21 known_hosts

Разрешения, кажется, в порядке (то же самое на сервере). Также пытались без настройки /etc/ssh/ssh_configс тем же результатом, за исключением большого количества автоматической конфигурации, выполняемой на клиенте, которая заканчивается той же ошибкой.

Если вы исключили какие-либо «внешние» факторы, следующий набор шагов обычно помогает сузить их. Таким образом, хотя это не дает прямого ответа на ваш вопрос, оно может помочь отследить причину ошибки.

Поиск неисправностей sshd

Что я нахожу в целом очень полезным в любых таких случаях, так это начать, sshdне позволяя этому демонизироваться. Проблема в моем случае заключалась в том, что ни то, ни другое syslogне auth.logпоказало ничего значимого.

Когда я запустил его из терминала, я получил:

# $(which sshd) -Ddp 10222
/etc/ssh/sshd_config line 8: address family must be specified before ListenAddress.

Намного лучше! Это сообщение об ошибке позволило мне увидеть, что не так, и исправить это. Ни один из файлов журнала не содержал этот вывод.

NB: по крайней мере в Ubuntu $(which sshd)это лучший способ удовлетворить sshdтребования абсолютного пути. В противном случае вы получите следующее сообщение об ошибке: sshd re-exec requires execution with an absolute path. Программа -p 10222заставляет sshdпрослушивать этот альтернативный порт, переопределяя файл конфигурации - это так, чтобы он не конфликтовал с потенциально работающими sshdэкземплярами. Убедитесь, что выбрали свободный порт здесь.

Наконец: подключитесь к альтернативному порту ( ssh -p 10222 user@server).

Этот метод много раз помог мне в поиске проблем, будь то проблемы с аутентификацией или другие типы. Чтобы получить действительно подробный вывод stdout, используйте $(which sshd) -Ddddp 10222(обратите внимание на добавленное ddдля увеличения многословия). Для дополнительной проверки отладки man sshd.

У вас также может быть хост, чья память настолько сильно фрагментирована, что он не может выделить странице непрерывную память для разветвления процесса для размещения сеанса SSH.

В таком случае вы можете получить одно из сообщений:

ssh_exchange_identification: read: Connection reset by peer

или же:

Connection closed by aaa.bbb.ccc.ddd

в зависимости от того, как далеко заходит хост до того, как он выручит.

Если фрагментация памяти является очевидной причиной, решение состоит в том, чтобы получить доступ к серверу с помощью других средств и перезапустить некоторые из соответствующих служб. Я обнаружил, что Apache и MySQL являются виновниками виртуальных машин, поскольку у виртуальных машин нет раздела подкачки. В противном случае перезагрузите хост.

На всякий случай, потому что это случилось со мной. Убедитесь, что у вас запущен sshd!

Это глупый провал, но, возможно, это действительно твоя проблема.

Я обнаружил, что эта ошибка произошла из-за превышения сеансов SSH на сервере. Я обнаружил, что хосты пытаются подключиться, и убил все сеансы со всех клиентов. Проблема решена после прояснения всех сессий.

Я столкнулся с ssh_exchange_identification: read: Connection reset by peerпроблемой в сценарии, который запускает 16 или более сессий ssh ​​в цикле. sshd очевидно не может идти в ногу; добавление короткого сна решило мою проблему:

for i in $(seq 32)
do
    ssh -f root@$HOST "./test_server -p $(expr $BASE_PORT + $i)" > svr${i}.out
    # for > 8 connections, ssh has ssh_exchange_identification issues
    sleep 0.1
done

Или вы, возможно, сделали то, что я сделал прошлой ночью, и удалили / var / empty. Очевидно, что этот каталог и его разрешения важны для функционирования sshd, и он не будет перезаписывать каталог при перезапуске /etc/init.d/sshd, не будет перезагружаться, и никто из systemd не скажет вам, почему.

Я нашел проблему, запустив sshd на переднем плане:

# /usr/sbin/sshd -Dd
  Missing privilege separation directory: /var/empty/sshd

Восстановление директорий решило проблему в моем случае:

drwxr-xr-x. root root  /var/empty
drwx--x--x. root root  /var/empty/sshd

Примечание для программистов Linux: критически важные вещи в /var/empty... действительно ???

Я получил ошибку ssh_exchange_identification: Connection closed by remote hostпри попытке подключиться к SSH: я сделал переадресацию удаленного порта для порта 22 SSH моего локального компьютера, чтобы я мог временно получить к нему доступ с удаленного сервера в Интернете.

На самом деле ошибка была только отображается , потому что я не помню , что я отключил службу SSH при запуске , так что я должен был запустить службу SSH на моем локальном компьютере sudo service ssh start.

Первое первым; telnet на IP-адрес хоста, чтобы проверить, действительно ли порт 22 прослушивает (открыт) на этом хосте:

telnet x.x.x.x 22

(если нет, то вы можете подключить консольный кабель для входа)

В моем случае это не работало, и я подключил консольный кабель для входа в систему. После входа в систему я обнаружил, что все 5 линий VTY были заняты на этом хосте (маршрутизатор Cisco).

Я очистил старые соединения, которые там висели, чтобы освободить линии VTY, это сработало. Я добавил команду "exec-timeout 15" под строками VTY. Затем я снял консольный кабель.

Урок:

Обязательно установите время ожидания 5-10 минут на всех ваших устройствах - (если активность не обнаружена).

В моем случае был ошибочно установлен сокет прокси (который не работает). Я получил точно такой же вывод ssh -vvv и пустой лог sshd.

Ошибка ssh_exchange_identification: Connection closed by remote hostможет произойти по неизвестным причинам. Когда я использовал код Visual Studio . Та же ошибка произошла, когда я попытался вытащить из удаленного репо с помощью git pullкоманды.

Я просто закрыл встроенный терминал и открыл терминал Ubuntu и снова потянул. И это было успешно

Из с CentOS Linux release 7.4.1708 (Core)с OpenSSH_7.4p1, OpenSSL 1.0.2k-fips 26 Jan 2017за соединение не фильтрации портов у меня были:

ssh_exchange_identification: соединение закрыто удаленным хостом

И оказалось, что мой Raspberry Pi был выключен!

Я думал, что хост, не включенный, выдает ошибку «Нет маршрута к хосту». Raspberry Pi находится позади моего маршрутизатора ISP, так что, вероятно, именно он закрывал соединение.

Затем я повторил эксперимент (пытаясь подключиться к выключенному Raspberry Pi) с другого интернет-соединения, также не фильтрующего порты с помощью Debian Stretch, OpenSSH_7.4p1 Debian-10+deb9u3, OpenSSL 1.0.2l 25 May 2017и на этот раз я ожидал:

Нет маршрута к хосту