it-swarm.com.de

die ssh X11-Weiterleitung funktioniert nicht

Ich habe versucht, die X11-Port-Weiterleitung von meinem Laptop aus zur Verfügung zu stellen. Ich kann nicht herausfinden, warum es nicht funktioniert.

Ich erhalte diese Nachricht, wenn ich versuche, xterm auszuführen:

X11 connection rejected because of wrong authentication.
xterm Xt error: Can't open display: localhost:10.0

Ich weiß nicht, ob dies verwandt ist oder nicht, aber wenn ich mich anmelde, erhalte ich folgende Nachricht:

/usr/bin/xauth:  timeout in locking authority file /home/sphillips/.Xauthority

Ich habe mich gefragt, ob das Problem darin besteht, dass mein lokaler Benutzer auf meinem Laptop skp ist und der Benutzername auf diesem Server sphillips ist. Ich konnte X11 weiterleiten, um mit meinen anderen Computern zusammenarbeiten zu können, die das gleiche skp-Login verwenden.

Die X11-Portweiterleitung funktioniert auch von einem Windows-Computer, der Xming und PuTTY verwendet, an denselben Server. Ich muss die DISPLAY-Variable manuell auf die IP-Adresse konfigurieren und 0.0 anzeigen, aber es funktioniert.

Ich habe einen xhost + auf meinem Computer ausgeführt, um zu versuchen, alle Sicherheitsprobleme zu umgehen. Das hat immer noch nicht funktioniert.

Auf dem Server überprüfe ich die Konfiguration:

$ Sudo grep X11Forwarding /etc/ssh/sshd_config
#X11Forwarding no
X11Forwarding yes
#   X11Forwarding no

Und auch auf meiner Maschine:

$ Sudo grep X11Forwarding /etc/ssh/sshd_config
[Sudo] password for skp: 
#X11Forwarding no
X11Forwarding yes
#   X11Forwarding no

Mein Server ist RedHat Enterprise Linux 6 und mein Laptop ist Fedora 15.

Kann mir jemand irgendwelche Gedanken über Dinge geben, um zu versuchen, SSH X11 von meinem Laptop weiterzuarbeiten?

13
digitaleagle

Ich habe endlich die Antwort gefunden (zumindest für meine Situation)! Das Problem war SELinux. Ich habe SELinux ausgeschaltet und es funktionierte problemlos.

Wenn Sie sich für alle blutigen Details interessieren, können Sie dies auf meinem Blog nachlesen, aber lassen Sie mich die relevanten Fakten hier detailliert beschreiben ...

Auf dem Remote-Computer habe ich dmesg verwendet, um die Protokollierungsmeldungen anzuzeigen:

dmesg | tail

Ich habe eine Reihe von Nachrichten wie diese gefunden:

type=1400 audit(1332520527.110:51337): avc: denied { read } for pid=25240 comm="sshd" name="authorized_keys" dev=dm-5 ino=167 scontext=unconfined_u:system_r:sshd_t:s0-s0:c0.c1023 tcontext=unconfined_u:object_r:home_root_t:s0 tclass=file

Sie können den Status von SELinux mit diesem Befehl überprüfen:

$ sestatus
SELinux status: enabled
SELinuxfs mount: /selinux
Current mode: permissive
Mode from config file: permissive
Policy version: 24
Policy from config file: targeted

Sie können ihn mit diesem Befehl in den zulässigen Modus umschalten:

setenforce 0

Für weitere Informationen zu SELinux fand ich das Handbuch von Red Hat hilfreich . Auch für andere SSH-Probleme fand ich Davids Blog / hilfreich für die Protokollierung, um zu helfen.

Danach begann meine X11-Weiterleitung problemlos.

SELinux verhinderte mehrere andere Dinge. Es konnte nicht die erforderlichen Dateien erstellen, damit die Schlüsselauthentifizierung funktioniert. Ich fand es auch, dass ssh-keygen daran gehindert wurde, Schlüssel im Home-Verzeichnis zu erstellen.

12
digitaleagle

Ich habe das gleiche Problem mit einem OpenVZ-Container von Debian erhalten, und das Problem schien aus meiner/etc/hosts -Datei zu kommen, bei der "localhost" auf die LAN-IP-Adresse und nicht auf 127.0.0.1 betroffen war.

Vor :

192.168.0.15  dagi dagi.domain.net localhost localhost.localdomain

Nach dem :

192.168.0.15  dagi dagi.domain.net
127.0.0.1     localhost localhost.localdomain

Danach funktionierten sowohl ssh -X als auch ssh -Y wie ein Zauber, ohne auch sshd neu zu starten.

2
Chl

Ich bin auch darauf gestoßen. In meinem Fall lag es jedoch daran, dass ich vor einigen Tagen die IPv6-Unterstützung entfernt hatte. Ich stieß dann auf this thread und erklärte, wie man sicherstellt, dass sshd nur IPv4 verwendet.

So habe ich es gemacht, fügen Sie folgendes hinzu:

AddressFamily inet

in Ihre ssh_config-Datei (unter Ubuntu/etc/ssh/sshd_config) und stellen Sie sicher, dass sshd seine Konfiguration neu lädt (kill -SIGHUP pid-of-sshd).

2
gkephorus

Abgesehen von der obigen Antwort von @Chl hatte ich auch eine beschädigte ~/.Xauthority-Datei.

Aus irgendeinem Grund gehörte root sogar in meinem Home-Verzeichnis. Also musste ich Sudo -s und löschte es dann.

Dann mit touch ~/.Xauthority neu erstellt

Danach funktionierte die X-Weiterleitung für mich unter Ubuntu 14.04.

1
Deesbek
Sudo grep X11Forwarding /etc/ssh/sshd_config

X11Forwarding yes 
#sestatus
SELinux status: enabled
SELinuxfs mount: /selinux
Current mode: permissive
Mode from config file: permissive
Policy version: 24
Policy from config file: targeted
#You can turn it to permissive mode with this command:
#setenforce 0
0
nagaraju