Wenn ich auf einen Remote-Server starte, auf dem keine X11-Desktop-Umgebung ausgeführt wird, wird die folgende Meldung angezeigt.

$ ssh user@server
X11 forwarding request failed

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

Wie kann ich diese Nachrichten loswerden?

Diese Nachrichten können mit einer von drei Methoden beseitigt werden, wobei nur SSH-Optionen verwendet werden. Sie können Nachrichten immer auch an senden, /dev/nullaber diese Methoden versuchen, die Nachricht über die Konfiguration zu verarbeiten, anstatt sie nur abzufangen und zu sichern.

Methode 1 - Installieren Sie xauth

Der Server, auf dem Sie Remoting ausführen, beklagt sich, dass er keinen Eintrag in der Benutzerdatei .Xauthorityerstellen kann, da er xauthnicht installiert ist. Sie können es also auf jedem Server installieren, um diese lästige Nachricht zu beseitigen.

Auf Fedora 19 installieren Sie xauthwie folgt:

$ sudo yum install xorg-x11-xauth

Wenn Sie dann versuchen, sshauf den Server zuzugreifen, wird eine Meldung angezeigt, dass ein Eintrag in der Benutzerdatei .Xauthorityerstellt wird.

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

Bei nachfolgenden Anmeldungen wird diese Meldung nicht mehr angezeigt.

Methode 2 - Deaktivieren Sie sie über ForwardX11

Sie können den sshClient anweisen , die X11-Weiterleitung nicht zu aktivieren, indem Sie den SSH-Parameter ForwardX11 einfügen.

$ ssh -o ForwardX11=no root@server

Sie können dasselbe mit dem -xSchalter tun :

$ ssh -x root@server

Dadurch wird diese Nachricht nur vorübergehend deaktiviert. Dies ist jedoch eine gute Option, wenn Sie nicht in der Lage oder nicht bereit sind, sie xauthauf dem Remoteserver zu installieren .

Methode 3 - deaktivieren Sie es über sshd_config

Dies ist normalerweise die Standardeinstellung. sshdIst dies jedoch nicht der Fall, können Sie Ihren Server so einrichten, dass X11Forwarding in ausgeschaltet ist /etc/ssh/sshd_config.

X11Forwarding no

Von den 3 Methoden verwende ich im Allgemeinen # 2, weil ich X11Forwardingfür die meisten meiner Server häufig einschalten möchte , dann aber die X11....Warnungen nicht sehen möchte

$ HOME / .ssh / config

Die meiste Zeit wird diese Nachricht nicht einmal angezeigt. Sie sind normalerweise nur vorhanden, wenn Sie die folgenden Einträge in Ihrer $HOME/.ssh/configDatei oben haben.

ServerAliveInterval 15
ForwardX11 yes
ForwardAgent yes
ForwardX11Trusted yes

GatewayPorts yes

Es ist also dieses Setup, das letztendlich die Generierung dieser X11..Nachrichten vorantreibt. Daher scheint Methode 2 am besten geeignet zu sein, wenn Sie ForwardX11 yesstandardmäßig damit arbeiten möchten , sie jedoch für bestimmte Verbindungen aus sshSicht des Clients selektiv deaktivieren möchten .

Sicherheit

Es ist im Allgemeinen nicht ratsam, immer mit zu laufen ForwardX11 yes. Wenn Sie Ihre SSH-Verbindungen so sicher wie möglich betreiben möchten, gehen Sie am besten wie folgt vor:

1. Nicht ForwardX11 yesin die $HOME/.ssh/configDatei aufnehmen
2. Verwenden Sie ForwardingX11 nur, wenn Sie über benötigen ssh -X user@server
3. Wenn Sie können, deaktivieren Sie X11Forwardingden Server vollständig, damit er nicht zugelassen wird

Verweise

• SSH: Die Secure Shell - Das endgültige Handbuch - 9.3. X Weiterleitung

In meinem Fall, indem ich diesen String hinzufüge, um /etc/ssh/sshd_configdas Problem zu lösen:

X11UseLocalhost no

Bin heute darüber gelaufen und habe mir eine Weile den Kopf geschlagen, bis ich über eine SSH-Einstellung gestolpert bin:

Wenn es sich um RHEL 7 (CentOS, OEL usw.) handelt und IPv6 deaktiviert ist, benötigt es Folgendes:

AddressFamily inet

in / etc / ssh / sshd_config setzen.

Eine weitere geringfügige Änderung wäre, wenn Sie diese Meldung für bestimmte Server nicht mehr sehen möchten (dh nicht mehr versuchen, X11 weiterzuleiten), aber für alle anderen Verbindungen die Standardeinstellung ForwardX11 yes beibehalten möchten.

In diesem Szenario können Sie die X11-Weiterleitung für einen bestimmten Host (oder Bereich) in Ihrer ~ / .ssh / config deaktivieren. Etwas wie das:

host 10.1.1.*
ForwardX11 no 

Danksagung: Dies ist eine leichte Verschönerung der vorhandenen (und sehr vollständigen) vorhandenen Antwort - da ich keinen Kommentar abgeben konnte!

Wenn Sie den Client im ausführlichen Modus ausführen, erhalten Sie ( ssh -v user@host)

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

Istxauth es aber tatsächlich auf dem Server installiert, dann liegt es wahrscheinlich daran, dass sshd nach xauth- ausführbaren Dateien am falschen Ort sucht ( normalerweise / usr / X11R6 / bin / xauth ). Das kann man durch Einstellen beheben

XAuthLocation /usr/bin/xauth

in / etc / sshd / sshd_config (oder mit was auch immer Ihr Server konfiguriert ist).

Konfigurieren der X11-Weiterleitung auf Hostbasis

Zusätzlich zu all den hervorragenden Antworten, die Sie bereits hier erhalten, können Sie die Konfiguration ForwardX11für jeden Host einzeln vornehmen. Wenn dies nur serverfehlschlägt, können Sie Ihrer ~/.ssh/configDatei einen Eintrag in der folgenden Form hinzufügen :

Host server server.domain.dom
    ForwardX11 no

Sie können solche Einträge sogar als Alliase für ganze Konfigurationen verwenden

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

Dies ist besonders nützlich, wenn Sie Autocomplete-Servernamen für SSH und SCP eingerichtet haben .

Ich bin auf diese Frage gestoßen, nachdem ich mit einem sshd-xauthfast zehn Jahre alten Fehler reingelaufen war. Es werden zwei Lösungen gemeldet, die erste xauth, die den Fehler umgeht , und die zweite, die den Fehler behebt.

Lösung 1 - xauth umgehen

• local - der lokale Rechner, der einen Xserver bedient.
• remote - die entfernte Maschine, die die Anwendung bedient, die die Daten an den Xserver übermittelt

Fernbedienung /etc/ssh/sshd_config:

X11Forwarding no
X11DisplayOffset 10
X11UseLocalhost yes

Remote ~/.Xauthorityist leer oder existiert nicht

Vor Ort:

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

Im Test lief auf local Ubuntu 18.05, auf remote Debian Jesse.

Ich habe diese Lösung auch als Antwort auf eine andere Frage gepostet .

Lösung 2 - Beheben Sie den Fehler sshd / xauth

Diese Lösung ist in der Nähe @systempoet ‚s Lösung oben , obwohl das allein war nicht genug.

Zusätzlich zum Ändern /etc/ssh/sshd_configauf der Fernbedienung:

AddressFamily inet

/etc/hosts auf der Fernbedienung wurde ebenfalls geändert:

::1     localhost ip6-localhost ip6-loopback

Wenn einer von beiden auskommentiert wurde, erscheint die Fehlermeldung

X11 forwarding request failed on channel 0

erschien nach dem ssh -X ...Anruf. Außerdem /var/log/auth.logzeigte der den Fehler:

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

Testen Sie, um den Fehler zu erzeugen (vor der Behebung):

Lokale Maschine:

$ Xephyr -ac -screen 1280x800 -br -reset -terminate  :2 &
$ DISPLAY=:2 ssh -X  user@remote
X11 forwarding request failed on channel 0

Ein wichtiger Punkt, den Sie nach den Konfigurationsänderungen beachten sollten, ist, dass Sie sshd beenden müssen, damit die Änderungen übernommen werden:

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

als Root-Benutzer.

1. Stellen Sie die folgenden 2 Optionen /etc/ssh/sshd_configin Ihrem RHEL-Host ein

   X11Forwarding yes X11UseLocalhost no

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

3. sudo yum install xauth
4. SSH zurück zu Ihrem RHEL-Host mit -X-Schalter: ssh -X yourname@rhelbox