Ошибка SSH ssh_exchange_identification: прочитано: сброс соединения по пиру

Question

Я пытаюсь получить доступ к SSH к серверу, но получил " ssh_exchange_identification: read: Connection reset by peer ". Тот же клиент работает хорошо, когда я перемещаю компьютер к дому, но показываю ошибку, когда компьютер находится в рабочем офисе. Возможно ли, что некоторые настройки сети LAN в офисной сети вызывают проблему? Я пробовал другие компьютеры в офисной сети, та же проблема.

Могу ли я изменить настройки сервера, чтобы исправить эту проблему?

Клиент и сервер с тем же Debian «Linux debian 3.16.0-4-amd64 # 1 SMP Debian 3.16.7-2 (2014-11-06) x86_64 GNU/Linux»

На стороне клиента журнал показывает:

OpenSSH_6.7p1 Debian-3, OpenSSL 1.0.1j 15 Oct 2014
debug1: Reading configuration data /home/client/.ssh/config
debug1: /home/client/.ssh/config line 13: Applying options for navtk
debug1: Reading configuration data /etc/ssh/ssh_config
debug1: /etc/ssh/ssh_config line 19: Applying options for *
debug1: Hostname has changed; re-reading configuration
debug1: Reading configuration data /home/client/.ssh/config
debug1: Reading configuration data /etc/ssh/ssh_config
debug1: /etc/ssh/ssh_config line 19: Applying options for *
debug2: ssh_connect: needpriv 0
debug1: Connecting to www.host.com [xx.xx.xx.xx] port xx.
debug1: Connection established.
debug1: identity file /home/client/.ssh/user type 1
debug1: key_load_public: No such file or directory
debug1: identity file /home/client/.ssh/user-cert type -1
debug1: Enabling compatibility mode for protocol 2.0
debug1: Local version string SSH-2.0-OpenSSH_6.7p1 Debian-3
ssh_exchange_identification: read: Connection reset by peer

И логи на стороне сервера

Server listening on :: port 443.
debug3: fd 5 is not O_NONBLOCK
debug1: Server will not fork when running in debugging mode.
debug3: send_rexec_state: entering fd = 8 config len 735
debug3: ssh_msg_send: type 0
debug3: send_rexec_state: done
debug1: rexec start in 5 out 5 newsock 5 pipe -1 sock 8
debug1: inetd sockets after dupping: 3, 3
debug1: getpeername failed: Transport endpoint is not connected
debug1: get_remote_port failed

Answer 1

"Сброс соединения по пиру" означает, что поток TCP был аномально закрыт с другого конца. Я думаю, что наиболее вероятные объяснения состоят в том, что процесс удаленного сервера, обрабатывающий соединение, потерпел крах, или какое-то сетевое устройство (такое как межсетевой экран с сохранением состояния или балансировщик нагрузки) решило вмешаться в соединение.

Вы должны отладить это на удаленном сервере, если можете. sshd ведет журнал через syslog , и в типичной системе Unix записи журнала будут находиться в одном из файлов в каталоге /var/log . Если вам повезет, sshd будет регистрировать что-то каждый раз, когда прерывает сеанс.

Если у вас есть root-доступ на сервере, вы можете запустить отладочный экземпляр sshd . Стать пользователем root и затем запустить:

/path/to/sshd -ddd -p 1022

Это запустит экземпляр SSH-сервера, который прослушивает порт 1022, принимает одно соединение и распечатывает информацию об отладке на вашем терминале. Запустите ваш клиент как обычно, за исключением того, что укажите порт 1022 в качестве порта:

ssh -p 1022 user@host

Надеемся, что отладочная информация, напечатанная сервером, прояснит, что происходит.

Изменить: Выходные данные сервера указывают, что сервер не падает или намеренно закрывает TCP-соединение. Что-то еще вызывает его закрытие. Я хотел бы взглянуть на любое программное обеспечение безопасности, установленное на сервере, которое может отслеживать сеансы TCP, а также на любые брандмауэры, балансировщики нагрузки или аналогичное сетевое оборудование, которое может быть частью локальной сети.

Answer 2

У меня та же проблема. Прямо сейчас, похоже, проблема в моем провайдере. Попробуйте сделать трассировку на ваш сервер. Для меня это не удается до достижения сервера.

Мой сервер является сервером общего хостинга. Моя хостинговая компания сказала мне, что у них была такая же проблема с другими клиентами, использующими AT & T или Comcast.

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

Answer 3

Причин может быть много, но одной из наиболее вероятных причин может быть (в моем случае это было) то, что ssh / port 22 не разрешен брандмауэром.

Вы можете разрешить ssh-соединение через пользовательский интерфейс (некоторые провайдеры разрешают это) или если у вас есть какой-либо альтернативный способ входа (например, digitalocean предоставляет кнопку консоли), вы можете запустить команду ниже

sudo ufw allow ssh
sudo ufw allow 22

Answer 4

«ssh_exchange_identification: read: сброс соединения по пиру» также произойдет, когда вы попадете в черный список (например, потому что вы слишком часто вводите неправильный пароль). Случилось у меня с моим Synology-NAS. Поэтому убедитесь, что IP-адрес, с которого вы подключаетесь, отсутствует в этом списке.

В случае синологии проверьте в "Панель управления" / "Безопасность" / "Учетная запись".

Answer 5

Здесь уже слишком поздно, но, может быть, кто-то просто прыгает в это и находит это полезным.

1. Перезагрузите (остановите и запустите) сервер.
2. Доступ к серверу по ssh снова с публичного ip. (Вы можете перейти к следующему шагу, если он прошел успешно.)
3. Перезагрузите веб-сервер.

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

Мои окружения - AWS и NGINX.