Kiedy używam ssh -Xna komputerze Mac (z systemem OS X 10.6.7), aby połączyć się z moim systemem Ubuntu (11.04), pojawia się następujące ostrzeżenie:

Ostrzeżenie: niezaufana konfiguracja przekazywania X11 nie powiodła się: dane klucza xauth nie zostały wygenerowane Ostrzeżenie: Brak danych xauth; przy użyciu fałszywych danych uwierzytelniających do przekazywania X11.

Czy mogę coś zrobić, aby ostrzeżenie zniknęło? Jeśli nie, czy mogę to bezpiecznie zignorować?

Przekazywanie X11 wydaje się działać dobrze, chociaż widzę ten komunikat:

Xlib: brak rozszerzenia „RANDR” na ekranie „localhost: 10.0”.

Czy ma to związek z ostrzeżeniem? (Chyba nie. Jeśli nie, zadam nowe pytanie na ten temat.)

Czy jest jakiś powód, dla którego nie chcesz używać flagi -Y zamiast flagi -X?

Po prostu, różnica między -X i -Y polega na tym, że -Y umożliwia zaufane przekazywanie X11.

Jeśli przyjedziesz tutaj w 2015 r .: nawet jeśli wszystko inne jest poprawnie skonfigurowane, może się to zdarzyć również w systemie Mac OS X 10.10 Yosemite, gdy używasz ssh -Xi uruchamiasz wersję XQuartz <= 2.7.7. Główną przyczyną jest to, że gniazda ekranowe X11 są zapisywane poza ścieżką wyszukiwania xauth: problem nr 2068 w module śledzącym XQuartz.

Edycja: Naprawiono XQuartz został wydany na nowej stronie głównej, xquartz.org , a instalacja najnowszej wersji stamtąd (obecnie 2.7.9) obejmie ten problem.

Jeśli otrzymasz ten sam komunikat, nawet podczas korzystania -Y, xauthmoże brakować programu na serwerze. W systemach podobnych do Debiana potrzebujesz xauthpakietu. W systemach podobnych do RedHat potrzebujesz xorg-x11-xauthpakietu.

„Niezaufany” w tym kontekście oznacza, że ​​nie ufasz połączeniu. SSH zastosuje dodatkowe środki bezpieczeństwa, aby uczynić przekazywanie X11 bezpieczniejszym. „Zaufany” oznacza, że ​​masz całkowitą pewność, że nikt na zdalnym hoście nie uzyska dostępu do twoich danych Xauth i użyje ich na przykład do monitorowania naciśnięć klawiszy.

Ta terminologia dezorientowała mnie przez lata. Myślałem, że „zaufane” połączenia są bezpieczniejsze. Ale w rzeczywistości jest to opcja, której należy użyć w sytuacjach, gdy połączenie JEST godne zaufania i chcesz uruchomić rzeczy bez dodatkowych zabezpieczeń. „Niezaufany” to taki, który sprawia, że ​​(nieco) bezpieczniej jest radzić sobie z niezaufanym zdalnym hostem.

Połączenie „Niezaufane” próbuje ograniczyć możliwości czarnego kapelusza, włączając rozszerzenie bezpieczeństwa X11 i wyłączając inne rozszerzenia, których (mam nadzieję) nie potrzebujesz. Prawdopodobnie dlatego RandR jest wyłączony przez -X. Czy musisz mieć możliwość obracania wyświetlacza X ze zdalnego hosta?

Należy również zauważyć, że „niezaufane” przekazywanie X11 wyłącza się po pewnym czasie, aby zapobiec przypadkowemu pozostawieniu go włączonym. Nowe próby otwierania okien po prostu się nie powiodą. To mnie ugryzło kilka razy, zanim przeczytałem wystarczającą liczbę dokumentów, aby zrozumieć, co się dzieje.

Nie mam konfiguracji, która może wykazywać takie zachowanie, więc jest to strzał w ciemność:

Ostrzeżenie może być zmniejszane, jeżeli ustawisz ForwardX11Trusteddo "no"hostów, które dają to ostrzeżenie. Możesz umieścić to w jednym ~/.ssh/configlub /etc/ssh/ssh_config, i możesz uczynić tę opcję specyficzną dla konkretnego hosta, Host <hostname>umieszczając w powyższej linii. <hostname>komponent pasuje, co należy wpisać w wierszu poleceń (nie rozwiązany hostname) i może zawierać symbole wieloznaczne.

UWAŻAJ (zmęczony czytaniem niepełnych odpowiedzi, które prowadzą do usterki bezpieczeństwa)

1 / użycie ssh -Y oznacza tutaj posiadanie fałszywych informacji xauth, co jest złe!

2 / ssh -X powinien działać, ponieważ XQuartz, po włączeniu, używa xauth. Jedynym problemem jest to, że ssh szuka xauth w / usr / X11R6 / bin, a na komputerach Mac z XQuartz jest w / opt / X11 / bin

Bezpieczne rozwiązywanie:

1 / Włącz pierwszą opcję w zakładce Security w preferencjach (Cmd-,), która włącza uwierzytelnione połączenia

2 / dodaj

XAuthLocation /opt/X11/bin/xauth

w $ HOME / .ssh / config

3 / ssh -X you_serverdziała w bezpieczny sposób

Jeśli instalacja xauthnie działa poprawnie, jedną szczególnie irytującą sprawą może być uszkodzony .Xauthorityplik. Ten szczególny przypadek pozwolił niektórym klientom X działać, ale nie innym z większą tendencją do niepowodzenia z nowszymi wyświetlaczami. Usunięcie i ponowne utworzenie .Xauthoritypliku może rozwiązać ten problem.

Wyklucz problemy po stronie serwera

Po pierwsze, należy wykluczyć wszelkie problemy po stronie serwera. Czy jesteś w stanie ssh -Xpomyślnie z innego hosta? Czy ssh -Ydziała, podczas gdy ssh -Xnie? W obu przypadkach załóż, że ssh + X11 jest poprawnie skonfigurowany na serwerze i przejdź do następnej sekcji.

Jeśli nie jesteś w stanie tego sprawdzić (powiedzmy, że masz tylko jednego laptopa z X11), możesz sshz serwera na siebie za pomocą fałszywej sesji:

1. export DISPLAY=:44# (Powłoka Bourne'a) lub
   setenv DISPLAY :44# (csh / tcsh)
2. xauth add $DISPLAY MIT-MAGIC-COOKIE-1 1234 # Fałszywe ciasteczko tylko na potrzeby tego testu
3. ssh -X localhost env |grep DISPLAY

Oczekiwany wynik: na zdalnym końcu sesji ssh-to-self powinna znajdować się zmienna DISPLAY. Jeśli nie otrzymasz żadnego wyniku, serwer prawdopodobnie jest źle skonfigurowany (np. xauthMoże brakować bibliotek X11 i / lub polecenia; konfiguracja sshd może być ustawiona tak, aby odmawiać dostępu do X11)

Na Macu: sprawdź, czy Xquartz jest aktualny

Zgodnie z odpowiedzią Willa Angleya

Sprawdź ssh -vv -Xdane wyjściowe

Cytowany komunikat o błędzie jest objawem, który może mieć wiele przyczyn. Spróbuj ponownie , co powinno dać ci dodatkowe wskazówki, dlaczego konfiguracja tunelu X11 nie powiodła się.ssh -X -vv remotehost

Czy widzisz następujący komunikat?

debug1: Brak programu xauth.

1. Zwróć uwagę na to, gdzie w systemie klienta xauthznajduje się polecenie:

   który xauth

2. Dodaj następujące na samym końcu ~ / .ssh / config (i dodaj komentarz, aby przypomnieć sobie, aby zachować go w przyszłości):

   Gospodarz *
       XAuthLocation / opt / X11 / bin / xauth
   

   Dostosuj tę ścieżkę zgodnie z ustaleniami z kroku 1 - Kredyty dla Jana-Willema Arnolda

Jak już wyjaśniono powyżej, dla mnie działały:

Edytuj ~ / .ssh / config, aby dodać linie

Host *
    XAuthLocation /opt/X11/bin/xauth

a teraz działa nazwa hosta ssh -X (XQuartz 2.7.11, macOS 10.4 Mojave)

Miałem już zainstalowany najnowszy XQuartz 2.7.11, ale myślę, że od tego czasu kilkakrotnie aktualizowałem system operacyjny. Ponownie zainstalowałem XQuartz 2.7.11, a teraz działa dobrze.

xauth dodaj `nazwa hosta` / unix: 10 MIT-MAGIC-COOKIE-1` openssl rand -hex 16`