☰

ssh к удаленному серверу зависает, но работает локально (putty / cygwin / windows 10 к linux)

tag-icon • tag-icon networking ssh cygwin putty
ssh к удаленному серверу зависает, но работает локально (putty / cygwin / windows 10 к linux)

У меня есть сервер Linux, на котором запущен openssh. Я могу подключиться к нему как из локальной сети, так и удаленно. Однако есть один клиент (ноутбук с Windows 10), который может подключиться к нему только локально. Когда я пытаюсь подключиться удаленно, аутентификация принимается, но клиент ssh на ноутбуке зависает и его приходится убивать с помощью Process Explorer. Я подумал, что проблема может быть в следующем:

  1. Брандмауэр Windows - Нет. Отключил, поведение то же самое.
  2. ssh-клиент (cygwin) - Нет. То же самое происходит с putty.
  3. Windows 10 — Нет. Я могу успешно подключиться удаленно с другого компьютера с Win10.

Я попробовал новую установку Cygwin и Putty.

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

Authenticated to <<IP REMOVED>>.
debug2: fd 5 setting O_NONBLOCK
debug2: fd 6 setting O_NONBLOCK
debug1: channel 0: new [client-session]
debug3: ssh_session2_open: channel_new: 0
debug2: channel 0: send open
debug3: send packet: type 90
debug1: Requesting [email protected]
debug3: send packet: type 80
debug1: Entering interactive session.
debug1: pledge: network
debug3: receive packet: type 91
debug2: channel_input_open_confirmation: channel 0: callback start
debug2: fd 3 setting TCP_NODELAY
debug3: ssh_packet_set_tos: set IP_TOS 0x10
debug2: client_session2_setup: id 0
debug2: channel 0: request pty-req confirm 1
debug3: send packet: type 98
debug2: channel 0: request shell confirm 1
debug3: send packet: type 98
debug2: channel_input_open_confirmation: channel 0: callback done
debug2: channel 0: open confirm rwindow 0 rmax 32768

>>>  "bad" machine hangs here

debug3: receive packet: type 99
debug2: channel_input_status_confirm: type 99 id 0
debug2: PTY allocation request accepted on channel 0
debug2: channel 0: rcvd adjust 2097152
debug3: receive packet: type 99
debug2: channel_input_status_confirm: type 99 id 0
debug2: shell request accepted on channel 0
Welcome to Linux Mint 17.3 Rosa (GNU/Linux 3.19.0-32-generic x86_64)

Welcome to Linux Mint

В редких случаях соединение продвигалось дальше — один или два раза даже до приветственного сообщения, — но соединение так и не реагировало на ввод текста.

Я попробовал запустить sshd -d вручную на сервере и сравнить вывод между "плохим" удаленным сеансом и "хорошим" сеансом с другого клиента. Вывод идентичен.

Подводя итог: похоже, это не брандмауэр Windows, не клиентское ПО, не Win10, не переадресация портов на сервер, не DNS и не сам сервер. Проблема только в этой клиентской машине и только при подключении извне локальной сети. Она успешно проходит аутентификацию. И на клиентской машине запущена та же ОС/ssh-клиент, что и на другой машине, на которой нет этой проблемы, и я не вижу в журналах ничего, что могло бы ее отличить.

EDIT: Я также должен упомянуть, что ssh-подключение к другим удаленным серверам работает нормально со всех машин. Похоже, это только эта пара сервер/клиент, и только при удаленном подключении.

ОБНОВЛЕНИЕ: Более подробную информацию смотрите в моих комментариях ниже. Похоже, проблема касается только локальной сети.

Какие дальнейшие шаги я могу предпринять для устранения неполадки?

решение1

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

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

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

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