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

SSH иногда портит соединение при переполнении терминала?

У меня проблема с SSH на сервере на основе Debian Lenny (это vHost в среде Xen, загруженный на ядре Xen). Надеюсь, кто-нибудь сможет мне с этим помочь.

Соединение SSH, кажется, каким-то образом часто облажается, когда терминал переполняется (новые строки за пределами нижней части терминала, обычно заставляющие его прокручиваться). Соединение теряется, но не разрывается регулярно. Это почти всегда происходит, когда я делаю следующее:

Так что это воспроизводимо.

Я не совсем уверен, разрывается ли соединение до или после ввода пароля.

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

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

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

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

Заранее спасибо!

//редактировать: Я только что сделал Wireshark трассировку ssh-соединения и ничего, повторяю, ничего различаются между работающим и неисправным соединением (по крайней мере, за исключением номеров кадров, портов и времени, которые, очевидно, не могут быть равными). Это подводит меня к предположению, что ошибка должна произойти на стороне сервера.

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

  1. Следите за wirehark, чтобы проверить, действительно ли соединение SSH показывает последовательность TCP-FIN, когда вы получаете остановку (проверьте, как это происходит в представлении wirehark, когда вы выходите из обычного соединения, для справки).
    • если последовательность FIN не видна, SSH каким-то образом остановился (не закрыт)
  2. Когда вы зашли в тупик, попробуйте последовательность клавиш Ctrl+Q

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

  1. Попробуйте воспроизвести с другой клиентской машины и того же сервера
  2. Попробуйте воспроизвести с той же клиентской машины на другом сервере
  3. Попробуйте запустить клиент с помощью '-v -v -v'параметры ведения журнала отладки
  4. Попробуйте запустить сервер с помощью '-d -d -d'параметры ведения журнала отладки (см. /var/log/syslog или /var/log/auth.log для сообщений отладки сервера
  5. Когда вы получаете репродукцию с screen продолжает ли он останавливаться при попытке отключения и повторного подключения: "-D -R" на экране?

Похоже, ваше соединение обрывается, когда вы начинаете достигать максимального размера пакета для TCP-соединения. При использовании SSH обычно передается довольно небольшой объем данных, а MTU остается значительно ниже.

Есть ли между ними межсетевой экран, отбрасывающий все пакеты ICMP? Есть ли маршрутизатор с номером в адресном пространстве RFC1918?

В качестве грубого взлома, если вы запустите на сервере как root:

ifconfig eth0 mtu 1420

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