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?

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

• SSH: The Secure Shell - The Definitive Guide - 9.3. X Przekazywanie

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

X11UseLocalhost no

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.

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ć!

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).

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 .

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

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.

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