it-swarm.com.de

ssh gibt die Nachricht "X11-Weiterleitungsanforderung auf Kanal 1 fehlgeschlagen" zurück.

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

$ ssh [email protected]
X11 forwarding request failed

$ ssh [email protected] ls
X11 forwarding request failed on channel 1
file1
file2
...

Wie kann ich diese Nachrichten entfernen?

36
slm

Diese Nachrichten können durch eine von drei Methoden mit nur SSH-Optionen entfernt werden. Sie können Nachrichten auch jederzeit an /dev/null Senden, aber diese Methoden versuchen, die Nachricht durch Konfiguration zu verarbeiten, anstatt sie nur abzufangen und zu sichern.

Methode 1 - Installieren Sie xauth

Der Server, auf dem Sie ein Remoting durchführen, beschwert sich, dass kein Eintrag in der Datei .Xauthority Des Benutzers erstellt werden kann, da xauth nicht installiert ist. Sie können es also auf jedem Server installieren, um diese nervige Meldung zu entfernen.

Auf Fedora 19 installieren Sie xauth wie folgt:

$ Sudo yum install xorg-x11-xauth

Wenn Sie dann versuchen, ssh auf den Server zu übertragen, wird die Meldung angezeigt, dass in der Datei .Xauthority Des Benutzers ein Eintrag erstellt wird.

$ ssh [email protected]
/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 Client ssh anweisen, nicht zu versuchen, die X11-Weiterleitung zu aktivieren, indem Sie den SSH-Parameter ForwardX11 einbeziehen.

$ ssh -o ForwardX11=no [email protected]

Mit dem Schalter -x Können Sie dasselbe tun:

$ ssh -x [email protected]

Dies deaktiviert diese Nachricht nur vorübergehend, ist jedoch eine gute Option, wenn Sie xauth nicht auf dem Remote-Server installieren können oder wollen.

Methode 3 - Deaktivieren Sie sie über sshd_config

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

X11Forwarding no

Von den 3 Methoden verwende ich im Allgemeinen # 2, da ich für die meisten meiner Server häufig X11Forwarding Aktivieren möchte, dann aber die Warnungen X11.... Nicht sehen möchte

$ HOME/.ssh/config

In den meisten Fällen wird diese Nachricht nicht einmal angezeigt. Sie sind normalerweise nur vorhanden, wenn Sie die folgenden Einträge in Ihrer $HOME/.ssh/config - Datei 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. Auch hier scheint Methode 2 am besten geeignet zu sein, wenn Sie standardmäßig mit ForwardX11 yes Arbeiten möchten. Deaktivieren Sie es dann jedoch selektiv für bestimmte Verbindungen aus Sicht des Clients ssh.

Sicherheit

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

  1. Fügen Sie ForwardX11 yes Nicht in Ihre $HOME/.ssh/config - Datei ein
  2. Verwenden Sie ForwardingX11 nur, wenn Sie über ssh -X [email protected]
  3. Wenn Sie können, deaktivieren Sie X11Forwarding Vollständig auf dem Server, damit es nicht zulässig ist

Verweise

42
slm

Bin heute darauf gestoßen und habe mir eine Weile den Kopf geschlagen, bis ich über eine SSH-Einstellung gestolpert bin:

Wenn es RHEL 7 (centOS, OEL usw.) ist und ipv6 deaktiviert ist, benötigt es:

AddressFamily inet

in/etc/ssh/sshd_config setzen.

13
Systemspoet

In meinem Fall Hinzufügen dieser Zeichenfolge zu /etc/ssh/sshd_config Problem gelöst:

X11UseLocalhost no
13
user3132194

Eine weitere geringfügige Abweichung wäre, wenn Sie diese Meldung für bestimmte Server nicht mehr sehen möchten (d. H. Nicht mehr versuchen möchten, 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!

2
philarmour

Wenn Sie den Client im ausführlichen Modus ausführen (ssh -v [email protected]) gibt Ihnen

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

aber xauth ist tatsächlich auf dem Server installiert, dann liegt es wahrscheinlich daran, dass sshd nach xauth sucht, die an einer falschen Stelle ausführbar ist (/ usr/X11R6)/bin/xauth normalerweise). Man kann das durch Einstellen beheben

XAuthLocation /usr/bin/xauth

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

2
Anton Samsonov

Ich bin auf diese Frage gestoßen, nachdem ich mit einem sshd-xauth Fehler fast ein Jahrzehnt alt. Es werden zwei Lösungen gemeldet, wobei die erste xauth umgeht und die zweite den Fehler behebt.


Lösung 1 - xauth umgehen

  • local - Der lokale Computer, der einen Xserver bedient.
  • remote - Der Remotecomputer, der die Anwendung bedient, die die an den Xserver gesendeten Daten steuert

Fernbedienung /etc/ssh/sshd_config:

X11Forwarding no
X11DisplayOffset 10
X11UseLocalhost yes

Fernbedienung ~/.Xauthority ist leer oder existiert nicht

Auf lokal:

Xephyr -ac -screen 1280x800 -br -reset   :2 &
DISPLAY=:2 ssh  -fR 6010:/tmp/.X11-unix/X2  [email protected] "DISPLAY=:10 xeyes"

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

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


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

Diese Lösung liegt in der Nähe von @systempoets Lösung oben , obwohl dies allein nicht ausreichte.

Zusätzlich zum Ändern von /etc/ssh/sshd_config auf Fernbedienung:

AddressFamily inet

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

::1     localhost ip6-localhost ip6-loopback

Wenn einer der beiden auskommentiert wurde, wird die Fehlermeldung angezeigt

X11 forwarding request failed on channel 0

erschien nach dem ssh -X ... Anruf. Zusätzlich /var/log/auth.log zeigte den Fehler:

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

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

Lokale Maschine:

$ Xephyr -ac -screen 1280x800 -br -reset -terminate  :2 &
$ DISPLAY=:2 ssh -X  [email protected]
X11 forwarding request failed on channel 0
1
Craig Hicks

Konfigurieren der X11-Weiterleitung pro Host

Zusätzlich zu all den hervorragenden Antworten, die hier bereits vorhanden sind, können Sie ForwardX11 Pro Host konfigurieren. Wenn also nur server so fehlschlägt, können Sie Ihrem ~/.ssh/config Datei des folgenden Formulars:

Host server server.domain.dom
    ForwardX11 no

Sie können solche Einträge sogar als Alliasen für ganze Konfigurationssätze 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.

1
Mark Booth

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

der Root-Benutzer sein.

0
unixia