У меня новая и досадная проблема с ssh, пересылающим мое соединение X11 при входе с Mac (10.7.2) в Linux (Ubuntu 8.04). У меня нет проблем с использованием ssh -X для входа на удаленный компьютер и запуска приложения на основе X11 из этой оболочки.
Недавно началось то, что дополнительные вызовы приложений X11 из той же оболочки через некоторое время (порядка часов) не могут запуститься, потому что перенаправленное отображение блокируется (я полагаю). Например, при попытке запустить xterm я получаю обычное сообщение о неправильной настройке DISPLAY, например:
xterm Xt error: не удается открыть дисплей: localhost: 10.0
Но приложение X11, которое я запустил прямо при входе в систему, по-прежнему работает нормально, с тем же дисплеем (localhost: 10.0), как и раньше.
Я включил подробное ведение журнала в sshd_config и вижу это в файле /var/log/auth.log в ответ на неудачную попытку запуска xterm:
sshd [22104]: канал 8: открытие не удалось: административно запрещено: открытие не удалось
Если я снова подключусь к серверу по протоколу ssh -X, запустив новую оболочку и получив новый экран (localhost: 11.0), тот же процесс повторится: приложения X11, запущенные на ранней стадии, работают нормально, пока я держу их открытыми (дни ), но через несколько часов я не могу запустить новые из этой оболочки.
Особенности: OpenSSH sshd-сервер, работающий в Ubuntu 8.04, дисплей пересылается на Mac под управлением Lion (10.7.2) с сервером Apple X по умолчанию. Системы подключены к локальной сети Ethernet с помощью одного коммутатора между ними. Ни на одной машине не установлен брандмауэр. До недавнего времени (несколько дней назад) эта настройка работала отлично, поэтому я не уверен, где искать дальше. Я ни в коем случае не эксперт X11 или SSH, но имею хороший опыт работы с UNIX / Linux. Ничего очевидного не изменилось ни в конфигурации клиента, ни в сервере, хотя я попытался изменить несколько параметров, чтобы попытаться отладить это, например, установить sshd_config TCPKeepAlive в no и установить "host + localhost" (вы можете сказать, что я гуглил).
При входе с ноутбука Linux 11.10 на тот же удаленный хост по той же сети и коммутаторе эта проблема не возникает - xterm может быть успешно вызван через несколько часов из той же оболочки входа в систему ssh, в то время как тот же эксперимент с Mac не удался ( проверено сегодня утром, чтобы быть уверенным), так что, похоже, это проблема для Mac.
При установленном «LogLevel DEBUG3» на удаленном компьютере (sshd-сервере) и отсутствии изменений, внесенных мной в клиентские подключения, /var/log/auth.log показывает одно небольшое изменение в отчетах о состоянии подключения за ночь, то есть номер порта, который используется одной успешной сессией ssh с Linux-машины (я думаю), соединение № 7 ниже:
sshd [20173]: debug3: канал 7: статус: открыты следующие соединения: \ r \ n # 0 сеанс сервера (t4 r0 i0 / 0 o0 / 0 fd 14/13 cfd -1) \ r \ n # 3 Соединение X11 с портом 127.0.0.1 57564 (t4 r1 i0 / 0 o0 / 0 fd 16/16 cfd -1) \ r \ n # 4 Соединение X11 с портом 127.0.0.1 57565 (t4 r2 i0 / 0 o0 / 0 fd 17 / 17 cfd -1) \ r \ n # 5 X11-соединение с 127.0.0.1 порта 57566 (t4 r3 i0 / 0 o0 / 0 fd 18/18 cfd -1) \ r \ n # 6 X11-соединение с 127.0.0.1 порта 57567 (t4 r4 i0 / 0 o0 / 0 fd 19/19 cfd -1) \ r \ n # 7 X11-соединение с 127.0.0.1 порта 59007
В этом отчете все одинаково между отчетами о состоянии, за исключением номера порта, используемого соединением № 7, которое, как я считаю, является клиентом Linux - единственным, который все еще поддерживает соединение с дисплеем. Со временем он продолжает увеличиваться, судя по последовательности этих отчетов за ночь.
Спасибо за любую помощь,
-Майк
codeОтклоненное соединение X11 после истечения срока ForwardX11Timeout ForwardX11Timeout - это опция в ssh-клиенте Mac, которая ограничивает переадресацию из ненадежного соединения. Потенциально можно использовать -Y вместо -X. ForwardX11Timeout не задокументировано на справочной странице Lion по ssh. По умолчанию его значение составляет 20 минут. Возможно установить его выше в ssh_config, но X-сервер Lion дает сбой, если он установлен на> 596 часов ... который за миллисекунды переполняет 31 бит. Arrgh. Надеюсь, это исправит это.