Дисплей X11 с перенаправлением SSH из Linux на Mac потерян через некоторое время

У меня возникла новая неприятная проблема, связанная с тем, что ssh перенаправляет мое X11-соединение при входе с Mac (10.7.2) в Linux (Ubuntu 8.04). У меня нет проблем с использованием ssh -X для входа на удаленный компьютер и запуска приложения на основе X11 из этой оболочки.

В последнее время стало происходить то, что дополнительные вызовы приложений X11 из той же оболочки через некоторое время (порядка часов) не могут запуститься, потому что перенаправленное отображение блокируется (я полагаю). Например, при попытке запустить xterm я получаю обычное сообщение о неправильной настройке DISPLAY, например:

Ошибка xterm Xt: не удается открыть дисплей: localhost: 10.0

Но приложение X11, которое я запустил сразу после входа в систему, все еще работает нормально, используя тот же самый дисплей (localhost: 10.0), только то, что оно было запущено ранее.

Я включил подробное ведение журнала в sshd_config и вижу это в файле /var/log/auth.log в ответ на неудачную попытку запуска xterm:

sshd [22104]: канал 8: ошибка открытия: административно запрещено: ошибка открытия

Если я снова отправлю ssh -X на сервер, запустив новую оболочку и получив новый дисплей (localhost: 11.0), тот же процесс повторится: приложения X11, запущенные на ранней стадии, нормально работают до тех пор, пока я держу их открытыми (дни ), но через несколько часов я не могу запускать новые из этой оболочки.

Особенности: sshd-сервер OpenSSH, работающий на Ubuntu 8.04, отображение перенаправлено на Mac, на котором запущен Lion (10.7.2) с сервером Apple X по умолчанию. Системы подключены к локальной сети Ethernet с помощью одного коммутатора между ними. Ни на одной из машин не установлен брандмауэр. До недавнего времени (несколько дней назад) эта установка работала отлично, поэтому я не понимаю, где искать дальше. Я ни в коем случае не эксперт X11 или SSH, но имею хороший опыт работы с UNIX / Linux. Ничего очевидного не изменилось ни в конфигурации клиента, ни в конфигурации сервера, хотя я попытался изменить несколько параметров, чтобы попытаться отладить это, например, установив для TCPKeepAlive sshd_config значение 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 - единственным, который все еще поддерживает соединение дисплея. Судя по последовательности этих отчетов за ночь, он продолжает расти с течением времени.

Спасибо за любую помощь,

-Майк