Вопрос: SSH, если командный вывод содержит более 5 строк


Мне посоветовали спросить это вопрос здесь: Меня озадачивает следующая проблема, которую я сейчас испытываю.
У меня есть сервер Linux Debian 5.0, подключенный через Ethernet-кабель к моему DSL-маршрутизатору. Мой ноутбук работает под управлением Windows 7 и подключен по беспроводной сети (802.11b / g) к тому же DSL-маршрутизатору. Если я SSH на сервер с помощью Putty и попытаюсь выполнить команду, которая приводит к нескольким строкам вывода, мой сеанс SSH зависает. Ex.

ls -al /             // Freezes
ls -al / > ~/boo.txt // OK
vi ~/boo.txt         // OK
top                  // Freezes

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


8
2017-12-21 22:07


Источник


Возможно, вы захотите спросить об этом в StackOverflow, но похоже, что это может быть проблема со специальными символами (возможно, цвет), поскольку vi не делает никакой раскраски (если это фактически не vim). - Topher Fangio
Он сделал спросите его на StackOverflow, но, вероятно, лучше переместить его на ServerFault ... и я с Aidan: моим первым подозреваемым был сетевой MTU. - dmckee
Ах, ха-ха, да, ServerFault, а не StackOverflow ... это понедельник = P - Topher Fangio


Ответы:


звучит как проводная проблема MTU. немного ...

возможно ли, что у вас есть jumboframes? возможно нет. в любом случае - попробуйте установка нижнего mtu на debian и посмотреть, помогает ли это.


5
2017-12-21 22:24



откомандирован; это звучит как проблема MTU. Я предлагаю попробовать большие и большие пакеты (легко сделать с помощью ping), пока вы не получите пакеты с ошибками / выбросами. Или просто проверяйте настройки MTU везде :) - MikeyB
Спасибо людям! Нижний MTU на ноутбуке сделал трюк. Используется ли MTU для отправителя / получателя / обоих? Я мог пинговать сервер с ноутбука с большим размером данных. Обратное было неверным. Linux-сервер: ~ # ping -S 5000 athlon64-laptop.lan PING athlon64-laptop.lan 56 (84) байты данных 64 байта из xxxx: icmp_seq = 1 ttl = 128 раз = 2,71 мс На ноутбуке Windows> ping -l 2048 athlon64x2-server.lan Pinging athlon64x2-server.lan с 2048 байтами данных: время ожидания запроса. > ping -l 1048 athlon64x2-server.lan Pinging athlon64x2-server.lan с 1048 байтами данных: Ответ от x.x.x.x: bytes = 1048 time = 3ms TTL = 64
@leftbrainlogic - проблемы с mtu указывают, что в вашей сети есть что-то подозрительное. возможно, точка доступа не пропускает самые большие разрешенные [1500B] кадры для быстрого ethernet? Вы настроили вручную сервер для использования jumboframes? - pQd
@pQd. Нет, сервер просто запускает установку Debian 5.0 в ваниле. Я принимал все значения по умолчанию, кроме раздела диска и имени хоста. Выход из ifconfig -a здесь: pastebin.com/f78fcbf3d
@leftbrainlogic - ok; попробуйте снизить mtu, как описано в моей ссылке. ваш 1500B имеет стандартную длину helahtly, я думаю, что это указывает на некоторые проблемы с коммутатором, точкой доступа или сетевой картой Wi-Fi. - pQd


Вероятно, проблема с MTU вашего сетевого подключения - когда сервер Linux пытается отправить слишком много байтов данных в одном сетевом пакете, возможно, маршрутизатор отказывается пересылать его в окно, потому что он считает, что размер пакета равен слишком большой для передачи по беспроводной сети. Вы должны иметь возможность уменьшить MTU для интерфейса Ethernet в окне linux, и это, вероятно, решит вашу проблему.

Чтобы диагностировать, попробуйте ping -s <packetsize> <windows-ip>  от окна linux до IP вашего компьютера Windows и ping <linux-ip> <packetsize> от окна окна до linux, с различными значениями для параметра packetsize и посмотреть, отличается ли максимальный размер в любом направлении.

Также: man ping на linux будет полезно для понимания того, что происходит.


3
2017-12-21 21:46





Первое, что нужно сделать, - включить режим отладки, как на клиенте, так и на сервере.

PuTTY имеет встроенную отладку, доступную под Сессия -> Регистрация, Обратите внимание, что вам необходимо загрузить сеанс, который вы собираетесь использовать до установки параметров ведения журнала. Параметры ведения журнала являются частью конфигурации сеанса.

На сервере вы можете оставить LogLevel до INFO (в /etc/ssh/sshd_config) и измените его на DEBUG, только если вы не видите ничего, связанного с вашей проблемой. Не забудьте выйти из системы и перезапустить сервер ssh, чтобы применить изменения (/etc/init.d/ssh restart). Если DEBUG не дает никакой полезной информации, попробуйте DEBUG3, согласно man sshd_config,

Пожалуйста, обновите свой вопрос своими выводами!


0
2017-12-22 02:55