Mam nowy i dokuczliwy problem z przesyłaniem przez ssh mojego połączenia X11 podczas logowania z komputera Mac (10.7.2) do systemu Linux (Ubuntu 8.04). Nie mam problemu z użyciem ssh -X do zalogowania się na zdalnej maszynie i uruchomienia aplikacji opartej na X11 z tej powłoki.
To, co ostatnio się zaczęło, polega na tym, że dodatkowe wywołania aplikacji X11 z tej samej powłoki, po pewnym czasie (w kolejności godzin), nie mogą zostać uruchomione, ponieważ przesłany ekran jest blokowany (tak przypuszczam). Na przykład podczas próby uruchomienia Xterm pojawia się zwykły komunikat o złym ustawieniu WYŚWIETLACZA, na przykład:
xterm Błąd Xt: Nie można otworzyć display: localhost: 10.0
Ale aplikacja X11, którą uruchomiłem zaraz po zalogowaniu, nadal działa poprawnie, używając tego samego wyświetlacza (localhost: 10.0), tyle że została uruchomiona wcześniej.
Włączyłem pełne logowanie do sshd_config i widzę to w pliku /var/log/auth.log w odpowiedzi na nieudaną próbę uruchomienia xterm:
sshd [22104]: kanał 8: otwarcie nie powiodło się: administracyjnie zabronione: otwarcie nie powiodło się
Jeśli ponownie ssh -X do serwera, uruchamiając nową powłokę i przydzielając nowy ekran (localhost: 11.0), ten sam proces powtarza się: aplikacje X11 uruchomiły się wcześnie po uruchomieniu tak dobrze, dopóki utrzymuję je otwarte (dni ), ale po kilku godzinach nie mogę uruchomić żadnych nowych z tej powłoki.
Dane szczegółowe: serwer sshd OpenSSH działający na systemie Ubuntu 8.04, wyświetlacz przekierowany na komputer Mac z systemem Lion (10.7.2) z domyślnym serwerem Apple X. Systemy są podłączone do sieci Ethernet LAN za pomocą jednego przełącznika między nimi. Żadna z maszyn nie ma zapory ogniowej. Do niedawna (kilka dni temu) ta konfiguracja działała idealnie, więc zastanawiam się, gdzie dalej szukać. W żadnym wypadku nie jestem ekspertem od X11 lub SSH, ale mam dobre doświadczenie w systemach UNIX / Linux. Nic oczywistego się nie zmieniło ani w konfiguracji klienta, ani serwera, chociaż próbowałem zmienić kilka opcji, aby spróbować to debugować, na przykład ustawienie TCPKeepAlive sshd_config na no i ustawienie „host + host lokalny” (możesz powiedzieć, że byłem googlingiem).
Podczas logowania z laptopa Linux 11.10 na tym samym zdalnym hoście za pośrednictwem tej samej sieci i przełącznika ten problem nie występuje - xterm można pomyślnie wywołać kilka godzin później z tej samej powłoki logowania ssh, podczas gdy ten sam eksperyment z komputera Mac kończy się niepowodzeniem ( przetestowane dziś rano), więc wydaje się, że jest to problem specyficzny dla komputerów Mac.
Po ustawieniu „LogLevel DEBUG3” na zdalnej maszynie (serwerze sshd) i bez żadnych zmian w połączeniach klienta przeze mnie, /var/log/auth.log pokazuje jedną niewielką zmianę w raportach o stanie połączenia z dnia na dzień, którym jest używany numer portu przez jedną udaną sesję ssh z maszyny Linux (myślę), połączenie nr 7 poniżej:
sshd [20173]: debug3: kanał 7: status: Otwarte są następujące połączenia: \ r \ n # 0 sesja serwera (t4 r0 i0 / 0 o0 / 0 fd 14/13 cfd -1) \ r \ n # 3 Połączenie X11 z portu 127.0.0.1 57564 (t4 r1 i0 / 0 o0 / 0 fd 16/16 cfd -1) \ r \ n # 4 Połączenie X11 z portu 127.0.0.1 57565 (t4 r2 i0 / 0 o0 / 0 fd 17 / 17 cfd -1) \ r \ n # 5 Połączenie X11 z portu 127.0.0.1 57566 (t4 r3 i0 / 0 o0 / 0 fd 18/18 cfd -1) \ r \ n # 6 Połączenie X11 z portu 127.0.0.1 57567 (t4 r4 i0 / 0 o0 / 0 fd 19/19 cfd -1) \ r \ n # 7 Połączenie X11 z portu 127.0.0.1 59007
W tym raporcie wszystko jest takie samo między raportami stanu, z wyjątkiem numeru portu używanego przez połączenie nr 7, które, jak sądzę, jest klientem Linuksa - jedynym, który nadal utrzymuje połączenie ekranowe. Z czasem rośnie, sądząc po sekwencji tych raportów z dnia na dzień.
Dziękuję za wszelką pomoc,
-Mikrofon
codeOdrzucone połączenie X11 po upływie ForwardX11Timeout ForwardX11Timeout to opcja w kliencie ssh Maca, która ogranicza przekazywanie z niezaufanego połączenia. Potencjalne użycie -Y zamiast -X działałoby. ForwardX11Timeout nie jest udokumentowany na stronie man Lion's ssh. Domyślnie wynosi 20 minut. Ustawienie go wyżej w ssh_config jest możliwe, ale serwer Lion's X ulega awarii, jeśli jest ustawiony na> 596 godzin ... co w milisekundach powoduje przepełnienie 31 bitów. Arrgh. Mam nadzieję, że to naprawia.Odpowiedzi:
Sesje ssh rozpoczęły się po zmianie pliku / etc / ssh_config klienta Mac, tak aby zawierał wiersz:
wszystko działa dobrze i cały dzień. Do tej pory wszyscy odmówiliby rozpoczęcia nowych Xtermów. Więc wierzę, że to jest odpowiedź i na szczęście proste rozwiązanie, ale limit czasu nadal będzie istniał za 3-1 / 2 tygodnie od teraz.
źródło
man ssh_configźródło
Aby dodać do „odpowiedział 7 stycznia 12 o 0:11 mklein9 28129” „Sesje ssh rozpoczęły się po zmianie pliku / etc / ssh_config klienta Mac na linię:
... ale upłynie limit czasu za 3-1 / 2 tygodnie od teraz. ”
Najwyraźniej możesz użyć 0, a to ustawia limit czasu na nieskończoność (o ile połączenie jest włączone).
...
źródło