Jak debugować „Połączenie X11 odrzucone z powodu nieprawidłowego uwierzytelnienia”

Mam problem z przekazywaniem X przez SSH. Walczyłem od wieków, ale nikt nie może pomóc.

Teraz wybieram inny takt. Chciałbym wiedzieć, jak debugować błędy?

Jakie dzienniki powinienem sprawdzić, jakie dodatkowe flagi powinienem ustawić (-v itp.) I czego powinienem szukać?

Dalsza edycja:

Jeśli zaloguję się do Putty na serwerze i spróbuję xeyes, otrzymam:

Proxy PuTTY X11: próba niewłaściwego protokołu autoryzacji Błąd: Nie można otworzyć display: localhost: 10.0

Jeśli xauth generate $DISPLAYdostanę:

Proxy PuTTY X11: próba nieprawidłowego protokołu autoryzacji xauth: (argv): 1: nie można otworzyć wyświetlacza „localhost: 10.0”.

Moje rozwiązanie krok po kroku:

1) zaloguj się z opcją -X zdalny katalog główny hosta zdalnego

$ ssh -X root@192.168.1.39

2) sprawdź, czy istnieje plik .Xauthority

[root @ localhost ~] # ls -al
[root @ localhost ~] # vim .Xauthority

3) skopiuj plik .Xauthority do katalogu drugiego użytkownika

[root @ localhost ~] # cp .Xauthority / home / oracle /
cp: nadpisać `/home/oracle/.Xauthority '? y

4) ustaw uprawnienia dla tego pliku

[root @ localhost ~] # chown oracle: oinstall .Xauthority
[root @ localhost ~] # chmod 0600 .Xauthority

5) zaloguj się użytkownik oracle

[root @ localhost ~] # su - oracle

6) ustawienie wyświetlania w localhost: 10.0

[oracle @ localhost ~] $ echo $ DISPLAY
localhost: 10.0
[oracle @ localhost ~] $ ls -al

7) zawiera listę istniejących plików cookie xauth

[oracle @ localhost ~] $ xauth list
localhost.localdomain / unix: 11 MIT-MAGIC-COOKIE-1 310f1b02c1080e73059391c193a1881b
localhost.localdomain / unix: 10 MIT-MAGIC-COOKIE-1 41843db100830a2aa352641ac47bb759

8) dodawanie

[oracle @ localhost ~] $ xauth dodaj localhost.localdomain / unix: 10 MIT-MAGIC-COOKIE-1 41843db100830a2aa352641ac47bb75

9) test

[oracle @ localhost ~] $ xclock

Mam nadzieję, że służą! @wcaraza

Upewnij się, że serwer SSH ma xauthzainstalowane narzędzie i że Twój ~/.Xauthorityplik jest zapisywalny. (Nieistniejące jest również w porządku, o ile xauthmożna je utworzyć).

Sprawdź, czy dane xauth są aktualizowane:

server$ xauth list

Spróbuj ręcznie dodać fikcyjne dane xauth (ponownie na serwerze SSH) i sprawdź, czy występują xauthjakieś problemy (np. Niemożność utworzenia pliku blokady lub modyfikacji samego pliku Xauthority):

server$ xauth add localhost:123 MIT-MAGIC-COOKIE-1 d7e2e4a8c5aa4430bfcc2abb436940d2

W razie potrzeby uruchom ponownie pod strace.

Uruchom usługę SSH w trybie debugowania, ustawiając LogLevel DEBUG2konfigurację serwera ( /etc/ssh/sshd_config) lub uruchamiając bezpośrednio sshd w trybie debugowania:

server$ sshd -rddp 12234

(W tym przykładzie 12234jest to tymczasowy port SSH, z którym należy się połączyć. Zrobi to dowolny wolny port).

Działa, działa. ha ha.

WRESZCIE.

Po odkryciu, że to nie był system, dodając użytkownika testowego (którego przekierowanie x działało „po wyjęciu z pudełka”), pomyślałem, że zacznę kopiować pliki startowe .bash *, aby virginise „zepsutego” użytkownika.

Żaden z plików nie był inny, więc następnie usunąłem katalog .ssh użytkowników. Kiedy się zalogowałem, narzekałem: „Serwer odmówił naszego klucza”, ale mogłem się zalogować przy użyciu hasła. Po zalogowaniu mogłem x przesyłać dalej idealnie.

Spróbuję teraz ponownie skonfigurować klucz i sprawdzić, czy uda mi się go uruchomić. Potem wróci do normy.

Jeszcze jedna rzecz, która może powodować ten problem, to istnienie ~/.ssh/rcpliku na serwerze - komputerze, z którym się łączysz. Usuń go (lub zmień nazwę), aby rozwiązać problem.

rm ~/.Xauth* a następnie podłącz ponownie.

To działa dla mnie. Po więcej szczegółów