У мене з’явилася нова і неприємна проблема з переадресацією 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, запущені рано, запускаються просто чудово, доки я триматиму їх відкритими (дні ), але через кілька годин я не можу запустити жодної нової з цієї оболонки.
Докладні відомості: OpenSSH sshd-сервер, що працює на Ubuntu 8.04, дисплей перенаправлений на Mac під управлінням Lion (10.7.2) з сервером Apple X за замовчуванням. Системи підключені до локальної мережі Ethernet з одним перемиканням між ними. Жодна машина не працює брандмауером. До недавнього часу (кілька днів тому) ця установка працювала ідеально, тому я загаданий питанням, де шукати далі. Я ні в якому разі не експерт X11 або SSH, але маю хороший досвід UNIX / Linux. Нічого очевидного не змінилося ні в конфігурації клієнта, ні в сервері, хоча я спробував змінити кілька варіантів, щоб спробувати налагодити це, як-от встановити TCPKeepAlive sshd_config на ні та встановити "хост + 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 не зафіксований на сторінці ssh man від Lion. Її за замовчуванням виявляється 20 хвилин. Встановити його вище в ssh_config можливо, але сервер X Lion виходить з ладу, якщо встановлено> 596 годин ..., що за мілісекунди переповнює 31 біт. Arrgh. Сподіваюся, це це виправить.