Соединение SSH: ssh_exchange_identifcation

Question

Я подключаюсь к удаленному серверу через мой Mac уже около месяца. Однако в последнее время я пытался подключиться с помощью ssh dylan @ MY_IP и получил это сообщение.

ssh_exchange_identification: read: Connection reset by peer

Я также получил некоторую диагностическую информацию ...

debug1: Reading configuration data /etc/ssh_config
debug1: /etc/ssh_config line 20: Applying options for *
debug1: /etc/ssh_config line 53: Applying options for *
debug2: ssh_connect: needpriv 0
debug1: Connecting to {MY IP{ [MY IP] port 22.
debug1: Connection established.
debug1: identity file /Users/watson/.ssh/id_rsa type -1
debug1: identity file /Users/watson/.ssh/id_rsa-cert type -1
debug3: Incorrect RSA1 identifier
debug3: Could not load "/Users/watson/.ssh/id_dsa" as a RSA1 public key
debug1: identity file /Users/watson/.ssh/id_dsa type 2
debug1: identity file /Users/watson/.ssh/id_dsa-cert type -1
debug1: Enabling compatibility mode for protocol 2.0
debug1: Local version string SSH-2.0-OpenSSH_6.2

После некоторых исследований я попробовал следующее ...

1. Перезапустил мой роутер
2. Очистил мой файл "known_hosts"
3. Удалил мой файл "known_hosts"
4. Выпущен и обновлен мой DHCP
5. Я также пытался с другого устройства (Windows), используя Putty, а также с ошибкой

Обратите внимание, что я не внес никаких изменений в сервер, чтобы запретить это общение.

Кроме того, я не уверен, что это вызовет проблемы, но я подключился к нему по его доменному имени, а также по IP.

Кроме того, мне удалось успешно подключиться с другого IP-адреса.

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

Обновить

Я заставил это протокол 1. Вместо "Сброс соединения по пиру" я теперь получаю "Соединение закрыто удаленным хостом". Запуск с отладочной информацией показал:

debug1: Reading configuration data /etc/ssh_config
debug1: /etc/ssh_config line 20: Applying options for *
debug1: /etc/ssh_config line 53: Applying options for *
debug2: ssh_connect: needpriv 0
debug1: Connecting to MY_IP [MY_IP] port 22.
debug1: Connection established.
debug1: identity file /Users/watson/.ssh/identity type -1
debug1: identity file /Users/watson/.ssh/identity-cert type -1
ssh_exchange_identification: Connection closed by remote host

Answer 1

Так я решил ошибку «ssh_exchange_identification: Соединение закрыто удаленным хостом» при подключении к серверу SSH.

Я получил эту ошибку при попытке подключиться к машине со встроенным Linux, после распаковки пакета в root. Многие библиотечные файлы были заменены, в том числе libssl.

Пытаюсь подключиться:

chetic@ubuntu:~$ ssh -v root@192.168.1.100
OpenSSH_6.2p2 Ubuntu-6ubuntu0.3, OpenSSL 1.0.1e 11 Feb 2013
debug1: Reading configuration data /etc/ssh/ssh_config
debug1: /etc/ssh/ssh_config line 19: Applying options for *
debug1: Connecting to SC [192.168.1.100] port 22.
debug1: Connection established.
debug1: identity file /home/delaval/.ssh/id_rsa type 1
debug1: Checking blacklist file /usr/share/ssh/blacklist.RSA-2048
debug1: Checking blacklist file /etc/ssh/blacklist.RSA-2048
debug1: identity file /home/delaval/.ssh/id_rsa-cert type -1
debug1: identity file /home/delaval/.ssh/id_dsa type -1
debug1: identity file /home/delaval/.ssh/id_dsa-cert type -1
debug1: identity file /home/delaval/.ssh/id_ecdsa type -1
debug1: identity file /home/delaval/.ssh/id_ecdsa-cert type -1
debug1: Enabling compatibility mode for protocol 2.0
debug1: Local version string SSH-2.0-OpenSSH_6.2p2 Ubuntu-6ubuntu0.3
ssh_exchange_identification: read: Connection reset by peer

Похоже, что поиск в Google предлагал проверить hosts.deny и hosts.allow, но на моей целевой машине таких файлов не было.

После перезагрузки (согласно предложению Картика) sshd не работал. Я попытался вручную запустить sshd для цели:

# sshd
OpenSSL version mismatch. Built against 1000002f, you have 1000105f

Я заменил /usr/lib/libssl.a на оригинальную версию и запустил sshd, и все вернулось к норме. В моем случае проблема была вызвана неправильной версией пакета, который я первоначально распаковал в root.

Answer 2

Я получал ту же ошибку (но с любой машины, включая проблемную машину через ssh localhost).

Это началось, когда я перенес профиль пользователя; то есть после копирования файлов от имени пользователя root выполнялись такие команды, как chown -R username /Users/username/Destop

в любом случае, совершенно неуверенно, почему владелец /var /empty был изменен на имя пользователя, но ssh определенно нужно, чтобы /var/empty принадлежал пользователю root (в противном случае вы получите ssh_exchange_identification: read: Connection reset by peer):

    sudo chown root /var/empty

Answer 3

Это не проблема вашего локального компьютера, а проблема на стороне сервера. Может быть несколько факторов, вызывающих эту проблему:

1. Изменения в конфигурации /etc/hosts.allow или /etc/hosts.deny на удаленном сервере.
2. Большая нагрузка на сервер.

В прошлом, когда у меня были эти проблемы, я делал одну из двух вещей в следующем порядке:

1. Измените /etc/hosts.allow, как указано в приведенной выше статье. (и перезапустите сервер SSH)
2. Если /etc/hosts.allow уже так, как требуется, просто перезапустите сервер SSH (и будьте осторожны, когда вы делаете это!)
3. Если перезапуск не работает, заново сгенерируйте ключи сервера и перезапустите сервер SSH (это рискованно, так как каждый пользователь, входящий в систему на этом компьютере, получит ошибку об изменении ключей на сервере)

Чаще всего 1 решает проблему, но мне приходилось делать 2 в некоторых случаях .. Я не смог понять, почему это так, только то, что это сработало. Возможно, это как-то связано с тем, как представлен ключ, или, возможно, он каким-то образом поврежден - я не уверен. Но я точно знаю, что ошибка полностью связана с сервером, и то, как происходит рукопожатие, когда устанавливается соединение SSH.

Answer 4

У меня был настроен SSH с Cygwin, и в моем случае именно брандмауэр Windows вызвал именно эту ошибку, поэтому убедитесь, что разрешено подключение к порту 22.

Answer 5

Мне удалось решить эту проблему самостоятельно очень легко.

В обычной OS X вы можете решить эту проблему, просто включив "Удаленный вход в систему" в «Системных настройках / Общий доступ».

Однако, если это безголовый сервер (как в моем случае), вы можете использовать приложение OSX Server, чтобы перейти (имя вашего сервера)/"Настройки" и переключить "Безопасные соединения оболочки снова и снова"