SSH X11 nie działa

Mam komputer domowy i służbowy, komputer domowy ma statyczny adres IP.

Jeśli ssh z komputera służbowego na komputer domowy, połączenie ssh działa, ale aplikacje X11 nie są wyświetlane.

W moim /etc/ssh/sshd_configdomu:

X11Forwarding yes
X11DisplayOffset 10
X11UseLocalhost yes

W pracy wypróbowałem następujące polecenia:

xhost + home HOME_IP
ssh -X home
ssh -X HOME_IP
ssh -Y home
ssh -Y HOME_IP

Mój /etc/ssh/ssh_configw pracy:

Host *
ForwardX11 yes 
ForwardX11Trusted yes

Mój ~/.ssh/configw pracy:

Host home
HostName HOME_IP
User azat
PreferredAuthentications password
ForwardX11 yes

Mój ~/.Xauthorityw pracy:

-rw------- 1 azat azat 269 Jun  7 11:25 .Xauthority

Mój ~/.Xauthorityw domu:

-rw------- 1 azat azat 246 Jun  7 19:03 .Xauthority

Ale to nie działa

Po nawiązaniu połączenia ssh z domem:

$ echo $DISPLAY
localhost:10.0

$ kate
X11 connection rejected because of wrong authentication.
X11 connection rejected because of wrong authentication.
X11 connection rejected because of wrong authentication.
X11 connection rejected because of wrong authentication.
X11 connection rejected because of wrong authentication.
X11 connection rejected because of wrong authentication.
X11 connection rejected because of wrong authentication.
X11 connection rejected because of wrong authentication.
kate: cannot connect to X server localhost:10.0

Używam iptablesw domu, ale pozwoliłem na port 22. Zgodnie z tym, co przeczytałem, to wszystko, czego potrzebuję.

UPD. Z-vvv

...
debug2: start oddzwaniania
debug2: x11_get_proto: / usr / bin / xauth list: 0 2> / dev / null
debug1: Żądanie przekazywania X11 z podszywaniem się pod uwierzytelnianie.
debug2: kanał 1: żądanie x11-req potwierdź 1
debug2: client_session2_setup: id 1
debug2: fd 3 ustawienie TCP_NODELAY
debug2: kanał 1: żądanie pty-req potwierdź 1
...

Podczas próby uruchomienia kate:

debug1: client_input_channel_open: ctype x11 rchan 2 win 65536 max 16384
debug1: client_request_x11: żądanie od 127.0.0.1 55486
debug2: fd 8 ustawienie O_NONBLOCK
debug3: fd 8 to O_NONBLOCK
debug1: kanał 2: nowy [x11]
debug1: potwierdź x11
debug2: połączenie X11 używa innego protokołu uwierzytelniania.
Połączenie X11 odrzucone z powodu nieprawidłowego uwierzytelnienia.
debug2: X11 odrzucił 2 i0 / o0
debug2: kanał 2: odczyt nie powiódł się
debug2: channel 2: close_read
debug2: kanał 2: wejście otwarte -> drenaż
debug2: kanał 2: ibuf pusty
debug2: kanał 2: wyślij eof
debug2: kanał 2: drenaż wejściowy -> zamknięty
debug2: kanał 2: zapis nie powiódł się
debug2: channel 2: close_write
debug2: kanał 2: wyjście otwarte -> zamknięte
debug2: X11 zamknięty 2 i3 / o3
debug2: kanał 2: wyślij zamknij
debug2: channel 2: rcvd close
debug2: kanał 2: nie działa
debug2: kanał 2: odśmiecanie
debug1: channel 2: free: x11, nchannels 3
debug3: kanał 2: status: Otwarte są następujące połączenia:
  # 1 sesja klienta (t4 r0 i0 / 0 o0 / 0 fd 5/6 cc -1)
  # 2 x11 (T7 R2 i3 / 0 o3 / 0 fd 8/8 cc -1)

# To samo co powyżej powtórz około 7 razy

kate: nie można połączyć się z lokalnym hostem X serwera: 10.0

UPD2 Podaj numer dystrybucji i wersji systemu Linux.
Czy używasz domyślnego środowiska GNOME lub KDE dla X, czy czegoś, co sam dostosowałeś?

azat: ~ $ kded4 -version
Qt: 4.7.4
Platforma programistyczna KDE: 4.6.5 (4.6.5)
Demon KDE: $ Id $

Czy wywołujesz ssh bezpośrednio w wierszu poleceń z okna terminala?
Z jakiego terminala korzystasz? xterm, gnome-terminal lub?
Jak uruchomiłeś terminal działający w środowisku X? Z menu? Klawisz skrótu? czy?

Z emulatora terminala `yakuake`
Ręcznie naciśnij `Ctrl + N` i napisz polecenia

Czy możesz uruchomić xeyes z tego samego okna terminala, w którym zawodzi ssh -X?

`xeyes` - nie jest zainstalowany
Ale działa `kate` lub inna aplikacja kde

Czy wywołujesz polecenie ssh jako ten sam użytkownik, którego zalogowałeś do sesji X?
From the same user

UPD3

Pobieram również sshźródła i debug2()pisząc, dlaczego to raport, że wersja jest inna.
Widzę niektóre pliki cookie, a jeden z nich jest pusty, inny toMIT-MAGIC-COOKIE-1

Przekazywanie ssh X nie działało, ponieważ mam /etc/ssh/sshrcplik konfiguracyjny.

Na końcu strony podręcznika znajduje się sshd(8):

Jeśli ~/.ssh/rcistnieje, uruchamia go; jeśli /etc/ssh/sshrcistnieje, uruchamia ją; w przeciwnym razie działa xauth

Dodaję więc następujące polecenia /etc/ssh/sshrc(także ze strony podręcznika sshd) po stronie serwera:

if read proto cookie && [ -n "$DISPLAY" ]; then
        if [ `echo $DISPLAY | cut -c1-10` = 'localhost:' ]; then
                # X11UseLocalhost=yes
                echo add unix:`echo $DISPLAY |
                    cut -c11-` $proto $cookie
        else
                # X11UseLocalhost=no
                echo add $DISPLAY $proto $cookie
        fi | xauth -q -
fi

I to działa!

Za każdym razem, gdy masz problemy z ssh, pierwszą rzeczą, którą powinieneś zrobić, to uruchomić klienta z -vopcją dostarczenia danych wyjściowych do sprawdzenia przez innych:

ssh -v user@somewhere

Zgaduję, że problem dotyczy twojego lokalnego systemu. Jak wywołujesz polecenie ssh? Czy uruchamiasz go ręcznie w powłoce? Czy może jest wykonywany jako część skryptu? W obu przypadkach należy upewnić się, że system lokalny ma DISPLAYpoprawnie ustawione środowisko. Musi być również ustawiony poprawnie po stronie zdalnej, ale ta wartość będzie inna po stronie zdalnej niż po stronie lokalnej.

Z tego, co napisałeś, wygląda na to, że jest on poprawnie ustawiony na zdalnym hoście (a przez rozszerzenie przekazywanie X11 jest poprawnie konfigurowane przez ssh). W systemie zdalnym masz:

$ echo $DISPLAY
localhost:10.0

Co to pokazuje po stronie lokalnej? To powinno być łatwe do sprawdzenia, czy jesteś w powłoce, zarówno przez echo wartości, jak i uruchamianie aplikacji X z tej powłoki ... zawsze możesz użyć czcigodnego xeyesdo tego rodzaju testów, oczywiście! :)

Z drugiej strony, jeśli wywołujesz polecenie ssh ze skryptu lub dołączasz do skrótu, może on nie odziedziczyć oczekiwanego DISPLAYśrodowiska , więc zmienna środowiskowa po stronie lokalnej może w ogóle nie zostać ustawiona.

Ponadto, ponieważ brzmi to tak, jakbyś majstrował przy swoim .Xauthoritypliku, możesz chcieć go całkowicie usunąć, a następnie wyloguj się z sesji X i zaloguj się ponownie, aby automatycznie go ponownie utworzyć. Rzadko zachodzi potrzeba zrzucania z tobą .Xauthority, więc próba jest prawdopodobnie desperackim środkiem, który nie pomoże.

To, co powinieneś zobaczyć po stronie lokalnej to:

$ echo $DISPLAY
:0.0

W poprawnie skonfigurowanym systemie, jeśli otworzysz powłokę, nie musisz jej ustawiać ręcznie, powinna ona zostać odziedziczona ze środowiska, w którym uruchomiono powłokę. Jednak widziałem konfiguracje menedżera okien / skrótów klawiszowych, które nie obsługują poprawnie dziedziczenia zmiennych środowiskowych. Jeśli masz uruchomiony system Linux gnome-sessionlub kde-sessionużywasz go do uruchamiania swoich powłok lub skryptów, to zmienne środowiskowe sesji X powinny zostać ustawione poprawnie, jak opisano w dokumentacji Ubuntu na temat dziedziczenia zmiennych środowiskowych :

Gdy proces nadrzędny tworzy proces podrzędny, na przykład gdy uruchamiamy polecenie „gedit” z terminala, a „bash” (proces nadrzędny) tworzy „gedit” (proces podrzędny), proces potomny dziedziczy wszystkie zmienne środowiskowe i wartości proces nadrzędny.

...

Uwaga: w środowisku graficznym Gnome sesja gnome jest procesem nadrzędnym dla wszystkich procesów uruchomionych na pulpicie. Ten fakt (wraz z zasadą dziedziczenia) jest kluczem do naszej zdolności do silnego wpływania na działanie naszego pulpitu za pomocą zmiennych środowiskowych. Równoważnym procesem w KDE jest sesja kde.

AKTUALIZACJA

Dziękujemy za opublikowanie danych wyjściowych z ssh -vvv. W takim przypadku pomocna jest dodatkowa gadatliwość w -vvvporównaniu do po prostu -v. Wyjście debugowania mówi mi, że przekazywanie X11 jest poprawnie skonfigurowane:

debug2: x11_get_proto: /usr/bin/xauth  list :0 2>/dev/null
debug1: Requesting X11 forwarding with authentication spoofing.
debug2: channel 1: request x11-req confirm 1

Ale :0w pierwszym wierszu wierzę, że po stronie lokalnej nadal występuje błąd konfiguracji w sposobie wywoływania ssh. W wielu systemach wartością domyślną DISPLAYjest :0.0, a nie :0. Czy w jakiś sposób sam ustawiasz wartość DISPLAYręcznie przed wywołaniem polecenia ssh?

W tym momencie przydatne byłyby dodatkowe informacje o systemie lokalnym i sposobie wywoływania polecenia ssh.

• Podaj numer dystrybucji i wersji systemu Linux.
• Czy używasz domyślnego środowiska GNOME lub KDE dla X, czy czegoś, co sam dostosowałeś?
• Czy wywołujesz ssh bezpośrednio w wierszu poleceń z okna terminala?
• Z jakiego terminala korzystasz? xterm, gnome-terminal lub?
• Jak uruchomiłeś terminal działający w środowisku X? Z menu? Klawisz skrótu? czy?
• Czy można uruchomić xeyesz tego samego okna terminala, w którym ssh -Xzawodzi?
• Czy wywołujesz polecenie ssh jako ten sam użytkownik, którego zalogowałeś do sesji X?

Ten ostatni element jest ważny. Jeśli korzystasz z ssh jako inny użytkownik (na przykład, jeśli otworzyłeś okno terminala głównego zamiast okna terminalu użytkownika), wtedy napotkasz ten problem, nawet jeśli wyraźnie ustawiasz, DISPLAY=:0ponieważ nie masz uprawnień do domyślnie połącz się z serwerem X jako inny użytkownik (nawet jako root!)

Twoje konfiguracje wydają się być w porządku, ale spróbuj „ssh -X home”, jak zasugerował Agemen.

Ponadto, jeśli wszystko inne zawiedzie, spróbuj tego:

Po ssh do komputera domowego z pracy, na „home” wpisz:

xauth list

Następnie w polu „praca” wpisz

xauth

Co spowoduje wyświetlenie monitu „xauth>”. Stąd wpisz „dodaj”, a następnie skopiuj wklej dane wyjściowe z „listy xauth”, po jednym wierszu na raz (każdy wiersz poprzedzony „dodaj”). Na przykład:

someguy@work:~$ xauth
Using authority file /var/run/gdm/auth-for-someguy-4MYV85/database
xauth> add work/unix:0  MIT-MAGIC-COOKIE-1  781cc753194fd55ecdf6c4cf105c40e3
xauth> 

Daj nam znać.

Nie rozumiem jasno, czy chcesz wyświetlać zdalne aplikacje na lokalnym wyświetlaczu ( work), czy chcesz wyświetlać je na zdalnym systemie ( home).

W pierwszym przypadku myślę, że ssh -X hostpowinno wystarczyć, bez potrzeby używania xhosta.

W drugim przypadku system, w którym należy użyć xhost, jest home, a to nie wystarczy, należy również wyeksportować zmienną wyświetlaną.

xhost +work
export DISPLAY=:0.0

Nie jestem do końca pewien, co chcesz zrobić ... a ponieważ nie wiem, jakie są różnice między twoim systemem a moim, z jednej strony, a dokładną konfiguracją potrzebną dla ciebie z drugiej strony (jako Nie jestem specjalistą ^ _ ^). Mam nadzieję, że pomoże ci to w jakiś sposób, ponieważ te konfiguracje również dla mnie zadziałały.