Назад | Перейти на главную страницу

ssh_exchange_identification: read: сброс соединения одноранговым узлом

У меня странная и срочная проблема. Я пытаюсь подключиться к ftp-сайту поставщика. Я пробовал подключаться из нескольких мест. Я обнаружил, что не могу подключиться со своего производственного сервера1, но могу подключиться со своего тестового сервера1, который находится в одном центре обработки данных. Я также могу подключиться с резервного сервера, расположенного в другом центре обработки данных. Я не могу подключиться со своего офисного компьютера, но могу подключиться с домашнего компьютера. Примерно 2 дня назад мне удалось подключиться ко всем этим ящикам.

sftp -v username@host

Connecting to host...
OpenSSH_4.3p2, OpenSSL 0.9.8e-fips-rhel5 01 Jul 2008
debug1: Reading configuration data /etc/ssh/ssh_config
debug1: Applying options for *
debug1: Connecting to host [**.**.**.**] port 22.
debug1: Connection established.
debug1: identity file /home/***/.ssh/id_rsa type -1
debug1: identity file /home/***/.ssh/id_dsa type -1
debug1: loaded 2 keys
ssh_exchange_identification: read: Connection reset by peer
Couldn't read packet: Connection reset by peer

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

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

Я также более чем счастлив позвонить в службу поддержки продавца, если это что-то не так.

Обновить добавление -vvv дало мне строку: debug2: ssh_connect: needpriv 0 между параметрами применения и подключением к линиям хоста.

В моем случае это оказался азиатский интернет-провайдер, который нарушал соединения SSH. Использование OpenVPN для перехода в другое место решает временную проблему. Если вы бьетесь головой об стену, пытаясь исправить это, сначала попробуйте ссылку VPN и посмотрите, связан ли ее транспорт, а не ваша конфигурация.

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

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

Кроме того, у вас есть детектор грубой силы, такой как denyhosts? Если да, убедитесь, что вы находитесь в белом списке. Также проверьте файлы /etc/hosts.deny и /etc/hosts.allow (они находятся на сервере, к которому вы пытаетесь подключиться).

  • проверьте свой брандмауэр только для проверки service iptables stop и попробуйте подключиться снова.
  • попробуйте ssh из коробки в ту же коробку, не выходя на улицу.

Попробуйте перезапустить демон SSH, это может решить проблему.

У меня была такая же проблема, и перезапуск службы SSH решил ее, сбросив ее безопасность.

Вы можете перезапустить WHM в разделе Restart Services.