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

9

Я подключался к удаленному серверу через мой 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
Dylan
источник
Вы используете аутентификацию с открытым ключом? У вас есть ключ /Users/watson/.ssh/id_dsa? Попробуйте сделать резервную копию файла и удалить его.
Пабук
Я не использую аутентификацию с открытым ключом; однако в файле есть один ключ. Я попытался удалить файл, но не было никаких изменений, запустив команду.
Дилан
если это проблема с версией протокола, вы можете принудительно установить соединение с версией протокола 1 с помощьюssh -1 ...
wkaha
Обратитесь к новой редакции поста
Дилан

Ответы:

4

Так я решил ошибку «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.

Chetic
источник
3

Я получал ту же ошибку (но с любой машины, включая проблемную машину через 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
hunter3740
источник
Спасибо! Смена владельца /var/emptyисправила проблему для меня.
Евгений Павлюк
1

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

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

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

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

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

Картик Рангараджан
источник
1

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

анонимный
источник
0

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

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

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

Сирены
источник
1
Я также отметил, что вы можете обойти эту проблему, но это не решает проблему: отключение удаленного входа серьезно влияет на систему, и необходимость переключать удаленный вход в систему каждый раз, когда вы хотите подключиться к ssh в определенном месте, не является жизнеспособным решением. ,
Ant6n
Да, это все еще ужасная проблема, которая у меня есть. Я только что создал скрипт cron, который перезапускает сервис каждую полночь.
Сирены
0

Если вы используете закрытый ключ или ключ безопасности для входа на сервер, вам нужно изменить разрешение для файла ключа на 660, используя команду

sudo chmod 660 File_Name

Сриджан Чаудхари
источник
1
(1) Хотя это может быть причиной sshнеработоспособности, неясно, как эта проблема может случайно вызвать работающую систему. (2) Этот ответ, каким бы он ни был, был бы более полезным, если бы вы определили файл, о котором вы говорите, или предоставили инструкции, позволяющие пользователю его идентифицировать. (3) Я предполагаю, что вы говорите о файле в (под) домашнем каталоге пользователя. Если это так, sudoне должно быть необходимости.
Скотт