ssh zwraca komunikat „Żądanie przekazania X11 nie powiodło się na kanale 1”

33

Kiedy ssh do zdalnego serwera, na którym nie jest uruchomione żadne środowisko graficzne X11, pojawia się następujący komunikat.

$ ssh user@server
X11 forwarding request failed

$ ssh user@server ls
X11 forwarding request failed on channel 1
file1
file2
...

Jak mogę pozbyć się tych wiadomości?

slm
źródło

Odpowiedzi:

38

Wiadomości te można wyeliminować za pomocą 1 z 3 metod, używając tylko opcji SSH. Zawsze możesz wysyłać wiadomości /dev/nullrównież, ale te metody próbują poradzić sobie z wiadomością poprzez konfigurację, a nie tylko ich wychwytywanie i odrzucanie.

Metoda nr 1 - zainstaluj xauth

Serwer, na którym jesteś zdalnie, narzeka, że ​​nie może utworzyć wpisu w .Xauthoritypliku użytkownika , ponieważ xauthnie jest zainstalowany. Możesz więc zainstalować go na każdym serwerze, aby pozbyć się tej irytującej wiadomości.

Na Fedorze 19 instalujesz xauthtak:

$ sudo yum install xorg-x11-xauth

Jeśli następnie spróbujesz sshwejść na serwer, zobaczysz komunikat, że w .Xauthoritypliku użytkownika tworzony jest wpis .

$ ssh root@server
/usr/bin/xauth:  creating new authority file /root/.Xauthority
$

Kolejne logowanie nie będą już wyświetlać tego komunikatu.

Metoda nr 2 - wyłącz ją przez ForwardX11

Możesz poinstruować sshklienta, aby nie próbował włączać przekazywania X11, włączając parametr SSH ForwardX11.

$ ssh -o ForwardX11=no root@server

Możesz zrobić to samo z -xprzełącznikiem:

$ ssh -x root@server

Spowoduje to tylko tymczasowe wyłączenie tej wiadomości, ale jest dobrą opcją, jeśli nie możesz lub nie chcesz zainstalować xauthna zdalnym serwerze.

Metoda nr 3 - wyłącz ją za pomocą sshd_config

Zazwyczaj jest to ustawienie domyślne, ale jeśli nie jest, możesz skonfigurować sshdserwer tak, aby X11 Forwarding był wyłączony /etc/ssh/sshd_config.

X11Forwarding no

Z 3 metod, których zwykle używam # 2, ponieważ często chcę X11Forwardingwłączyć większość moich serwerów, ale potem nie chcę widzieć X11....ostrzeżeń

$ HOME / .ssh / config

Przez większość czasu te wiadomości nawet się nie wyświetlają. Są zwykle obecne tylko wtedy, gdy w $HOME/.ssh/configpliku znajdują się następujące wpisy , u góry.

ServerAliveInterval 15
ForwardX11 yes
ForwardAgent yes
ForwardX11Trusted yes

GatewayPorts yes

Więc to ta konfiguracja ostatecznie napędza generowanie tych X11..komunikatów, więc metoda nr 2 wydaje się być najbardziej odpowiednia, jeśli chcesz ForwardX11 yesdomyślnie działać , ale następnie selektywnie wyłącz ją dla niektórych połączeń z sshperspektywy klienta .

Bezpieczeństwo

Generalnie nie zaleca się ciągłego działania ForwardX11 yes. Więc jeśli chcesz obsługiwać połączenia SSH w najbezpieczniejszym możliwym budynku, najlepiej wykonać następujące czynności:

  1. Nie dołączaj ForwardX11 yesdo swojego $HOME/.ssh/configpliku
  2. Korzystaj z ForwardingX11 tylko wtedy, gdy potrzebujesz ssh -X user@server
  3. Jeśli możesz, wyłącz X11Forwardingcałkowicie na serwerze, aby został niedozwolony

Referencje

slm
źródło
Czy możesz mi pomóc z unix.stackexchange.com/questions/470331/... ?
przeeksponowanie
Dla przypomnienia, dostałam wiadomość, że kiedy został próby uruchomienia klientów X na zdalnym serwerze. Nie uruchomiliby się, ponieważ nie ustawiono $ DISPLAY. Udało mi się to naprawić za pomocą twojej pierwszej sugestii: zainstaluj xauth.
Tom Ellis
13

W moim przypadku dodanie tego ciągu w celu /etc/ssh/sshd_configrozwiązania problemu:

X11UseLocalhost no
użytkownik3132194
źródło
To działało dla mnie (na serwerze już zainstalowano xauth). Dzięki.
Paul Higgins,
Wydawało się, że to rozwiązało mój problem, ale nie rozumiem dlaczego, co jest niepokojące. Mam trzy identyczne maszyny Debiana 7, z których jedna nagle przestała akceptować locahostprzekazywanie X11. Przekazywanie X11 na pozostałych dwóch nadal działa. Masz pojęcie, co mogło się zmienić?
Kyle Strand
12

Natknąłem się na to dzisiaj i uderzyłem się przez chwilę, aż natknąłem się na ustawienie ssh:

Jeśli jest to RHEL 7 (centOS, OEL itp.) I ma wyłączony ipv6, potrzebuje:

AddressFamily inet

ustawiony w / etc / ssh / sshd_config.

Przestrzeń systemowa
źródło
jeśli tylko komunikat o błędzie związany z tym ...
Jack Wasey
wiesz co jest śmieszne? Natknąłem się na to dzisiaj i przejrzałem go, znalazłem ten artykuł i znalazłem swój komentarz sprzed czterech lat i powiedziałem: „O, tak, to jest problem”.
Systemspoet
2

Kolejna niewielka odmiana byłaby, gdybyś chciał przestać widzieć ten komunikat (tj. Przestać próbować przekierowywać X11) dla niektórych serwerów, ale zachowując domyślną wartość ForwardX11 tak dla wszystkich innych połączeń.

W tym scenariuszu można wyłączyć przekazywanie X11 dla określonego hosta (lub zakresu) w ~ / .ssh / config. Coś takiego:

host 10.1.1.*
ForwardX11 no 

Potwierdzenie: Jest to niewielkie upiększenie istniejącej (i bardzo kompletnej) istniejącej odpowiedzi - ponieważ nie mogłem komentować!

filarmour
źródło
2

Jeśli uruchamiasz klienta w trybie pełnym ( ssh -v user@host) daje ci

debug1: Remote: No xauth program; cannot forward with spoofing.

ale xauthfaktycznie jest zainstalowany na serwerze, prawdopodobnie dzieje się tak dlatego, że sshd szuka pliku wykonywalnego xauth w złym miejscu ( zwykle / usr / X11R6 / bin / xauth ). Można to naprawić, ustawiając

XAuthLocation /usr/bin/xauth

w / etc / sshd / sshd_config (lub cokolwiek, na czym skonfigurowany jest twój serwer).

Anton Samsonov
źródło
To działało dla mnie w CentOS 7. To jest dokładnie ten komunikat o błędzie, który widziałem.
Brian Minton
To był mój problem, próbowałem zalogować się zdalnie na komputerze Mac. Tam prawidłową inkantacją było XAuthLocation / opt / X11 / bin / xauth
Leon Avery
1

Konfigurowanie przekazywania X11 dla poszczególnych hostów

Oprócz wszystkich doskonałych odpowiedzi już tutaj, możesz skonfigurować ForwardX11dla każdego hosta, więc jeśli tak się servernie powiedzie, możesz dodać wpis do ~/.ssh/configpliku w następującej formie:

Host server server.domain.dom
    ForwardX11 no

Możesz nawet użyć takich wpisów jako aliasów dla całych zestawów konfiguracji

Host my.server
    HostName server.domain.dom
    User user
    Port 1234
    ForwardX11 no

Jest to szczególnie przydatne, jeśli skonfigurowałeś nazwy serwerów autouzupełniania dla SSH i SCP .

Mark Booth
źródło
1

Natknąłem się na to pytanie po uruchomieniu z sshd-xauthbłędem prawie dziesięcioletnim. Zgłaszane są dwa rozwiązania, pierwsze obejście xauth, drugie rozwiązanie błędu.


Rozwiązanie 1 - obejście xauth

  • local - lokalna maszyna obsługująca Xserver.
  • remote - zdalna maszyna obsługująca aplikację, która napędza dane przesyłane do Xserver

Zdalne /etc/ssh/sshd_config:

X11Forwarding no
X11DisplayOffset 10
X11UseLocalhost yes

Pilot ~/.Xauthorityjest pusty lub nie istnieje

Lokalnie:

Xephyr -ac -screen 1280x800 -br -reset   :2 &
DISPLAY=:2 ssh  -fR 6010:/tmp/.X11-unix/X2  user@remote "DISPLAY=:10 xeyes"

W teście wersja lokalna działała na Ubuntu 18.05, na zdalnym Debian Jesse.

Opublikowałem również to rozwiązanie jako odpowiedź na inne pytanie.


Rozwiązanie 2 - usuń błąd sshd / xauth

To rozwiązanie jest zbliżone do powyższego rozwiązania @systempoet , chociaż samo to nie wystarczyło.

Oprócz modyfikacji /etc/ssh/sshd_configna pilocie:

AddressFamily inet

/etc/hosts na pilocie został również zmodyfikowany:

::1     localhost ip6-localhost ip6-loopback

Jeśli któryś z nich został skomentowany, komunikat o błędzie

X11 forwarding request failed on channel 0

pojawił się po ssh -X ...telefonie. Ponadto /var/log/auth.logpokazał błąd:

sshd[...]: error: Failed to allocate internet-domain X11 display socket

Przetestuj, aby wygenerować błąd (przed naprawą):

Maszyna lokalna:

$ Xephyr -ac -screen 1280x800 -br -reset -terminate  :2 &
$ DISPLAY=:2 ssh -X  user@remote
X11 forwarding request failed on channel 0
Craig Hicks
źródło
0

Jedną ważną kwestią, na którą należy zwrócić uwagę po wprowadzeniu zmian w konfiguracji, jest to, że będziesz musiał zabić sshd, aby przejął zmiany:

cat /var/run/sshd.pid | xargs kill -1

będąc użytkownikiem root.

unixia
źródło
-2
  1. Ustaw następujące 2 opcje /etc/ssh/sshd_configw swoim hoście RHEL

    X11Forwarding yes X11UseLocalhost no

  2. sudo /etc/init.d/sshd reload

  3. sudo yum install xauth
  4. ssh z powrotem do hosta RHEL za pomocą przełącznika -X: ssh -X yourname@rhelbox
użytkownik149406
źródło