☰

kex_exchange_identification: read: Сброс соединения пиром. Соединение работает на другой сетевой карте/подсети

tag-icon • tag-icon networking ssh openssh
kex_exchange_identification: read: Сброс соединения пиром. Соединение работает на другой сетевой карте/подсети

Я переустановил VM (CentOS7) и теперь получаю эту ошибку. У VM есть два адаптера, которые находятся в разных подсетях.
Достаточно забавноssh работал нормально в одной подсетипосле исправления ожидаемого предупреждения MITM.

ssh -v показывает:

OpenSSH_8.0p1, OpenSSL 1.1.1c  28 May 2019
debug1: Reading configuration data /home/user/.ssh/config
debug1: /home/user/.ssh/config line 6: Applying options for *
debug1: Reading configuration data /etc/ssh/ssh_config
debug2: resolving "foreman" port yy
debug2: ssh_connect_direct
debug1: Connecting to foreman [xxx.xxx.xxx.xxx] port yy.
debug1: Connection established.
debug1: identity file /home/sam/.ssh/id_rsa type 0
debug1: identity file /home/sam/.ssh/id_rsa-cert type -1
debug1: identity file /home/sam/.ssh/id_dsa type -1
debug1: identity file /home/sam/.ssh/id_dsa-cert type -1
debug1: identity file /home/sam/.ssh/id_ecdsa type -1
debug1: identity file /home/sam/.ssh/id_ecdsa-cert type -1
debug1: identity file /home/sam/.ssh/id_ed25519 type -1
debug1: identity file /home/sam/.ssh/id_ed25519-cert type -1
debug1: identity file /home/sam/.ssh/id_xmss type -1
debug1: identity file /home/sam/.ssh/id_xmss-cert type -1
debug1: Local version string SSH-2.0-OpenSSH_8.0
kex_exchange_identification: read: Connection reset by peer

я пробовал

  • Перезагрузка
  • удаление файла known_hosts
  • проверил /etc/ssh/ssh_config на клиенте (отклонений от версии разработчика нет)
  • проверил /etc/ssh/sshd_config на сервере (отклонений от версии разработчика нет)
  • остановка firewalld
  • проверил разрешения на .ssh/ и authorized_keys
  • проверил черный и белый списки (там ничего нет, только комментарии) (hosts.deny|hosts.allow)

Я не уверен, что это имеет значение, но клиент работает под управлением Arch Linux.

Итак, еще раз для ясности.
У сервера два IP-адреса 172.xxx и 192.xxx. SSH работает для 172.xxx, но не для 192.xxx.

решение1

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

Итак, первое, что нужно проверить, — можете ли вы пропинговать другую машинукаждыйподсетей изсервер, и наоборот. Чтобы сделать процесс тестирования менее подверженным ошибкам, следует настроитьдругоймашины (клиенты) для использования толькоодинIP-адрес (в противном случае тест может быть не пройден из-за неправильной настройкидругоймашин, что может ввести в заблуждение).

Следующим шагом будет глубокий анализ вывода route -nна сервере и на клиентах. Возможно, это уже показывает причину проблемы. Не могли бы вы опубликовать этот вывод?

Кроме того, вывод ifconfig -aбыл бы полезен (опять же на сервере и на клиентах) - мы бы хотели в конечном итоге понять ваши сетевые маски.

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

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

решение2

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

Основной вывод заключается в том, что подобные ошибки возникают, если на порту/IP-адресе/интерфейсе не обслуживается SSH, будь то из-за установки или конфигурации.

Связанный контент