SSH X11 funktioniert nicht

Ich habe einen Heim- und einen Arbeitscomputer, der Heimcomputer hat eine statische IP-Adresse.

Wenn ich von meinem Arbeitscomputer zu meinem Heimcomputer sshe, funktioniert die ssh-Verbindung, X11-Anwendungen werden jedoch nicht angezeigt.

In meinem /etc/ssh/sshd_configzu Hause:

X11Forwarding yes
X11DisplayOffset 10
X11UseLocalhost yes

Bei der Arbeit habe ich folgende Befehle ausprobiert:

xhost + home HOME_IP
ssh -X home
ssh -X HOME_IP
ssh -Y home
ssh -Y HOME_IP

Meine /etc/ssh/ssh_configbei der Arbeit:

Host *
ForwardX11 yes 
ForwardX11Trusted yes

Meine ~/.ssh/configbei der Arbeit:

Host home
HostName HOME_IP
User azat
PreferredAuthentications password
ForwardX11 yes

Meine ~/.Xauthoritybei der Arbeit:

-rw------- 1 azat azat 269 Jun  7 11:25 .Xauthority

Mein ~/.Xauthorityzu Hause:

-rw------- 1 azat azat 246 Jun  7 19:03 .Xauthority

Aber es geht nicht

Nachdem ich eine SSH-Verbindung nach Hause hergestellt habe:

$ echo $DISPLAY
localhost:10.0

$ kate
X11 connection rejected because of wrong authentication.
X11 connection rejected because of wrong authentication.
X11 connection rejected because of wrong authentication.
X11 connection rejected because of wrong authentication.
X11 connection rejected because of wrong authentication.
X11 connection rejected because of wrong authentication.
X11 connection rejected because of wrong authentication.
X11 connection rejected because of wrong authentication.
kate: cannot connect to X server localhost:10.0

Ich benutze iptableszu Hause, aber ich habe Port 22 zugelassen. Entsprechend dem, was ich gelesen habe, ist das alles, was ich brauche.

UPD. Mit-vvv

...
debug2: callback start
debug2: x11_get_proto: / usr / bin / xauth list: 0 2> / dev / null
debug1: Fordert eine X11-Weiterleitung mit Authentifizierungs-Spoofing an.
debug2: channel 1: request x11-req confirm 1
debug2: client_session2_setup: id 1
debug2: fd 3 setzt TCP_NODELAY
debug2: channel 1: Anfrage pty-req confirm 1
...

Beim Versuch zu starten kate:

debug1: client_input_channel_open: ctype x11 rchan 2 win 65536 max 16384
debug1: client_request_x11: request from 127.0.0.1 55486
debug2: fd 8 setze O_NONBLOCK
debug3: fd 8 ist O_NONBLOCK
debug1: channel 2: new [x11]
debug1: bestätige x11
debug2: Die X11-Verbindung verwendet ein anderes Authentifizierungsprotokoll.
X11-Verbindung wegen falscher Authentifizierung abgelehnt.
debug2: X11 lehnte 2 i0 / o0 ab
Debug2: Kanal 2: Lesen fehlgeschlagen
debug2: channel 2: close_read
Debug2: Kanal 2: Eingang offen -> Drain
debug2: kanal 2: ibuf leer
debug2: channel 2: send eof
Debug2: Kanal 2: Input Drain -> geschlossen
Debug2: Kanal 2: Schreiben fehlgeschlagen
debug2: channel 2: close_write
Debug2: Kanal 2: Ausgang offen -> geschlossen
debug2: X11 hat 2 i3 / o3 geschlossen
debug2: channel 2: send close
debug2: kanal 2: rcvd schließen
Debug2: Kanal 2: ist tot
debug2: kanal 2: müll sammeln
debug1: channel 2: free: x11, nchannels 3
debug3: channel 2: status: Die folgenden Verbindungen sind offen:
  # 1 Client-Sitzung (t4 r0 i0 / 0 o0 / 0 fd 5/6 cc -1)
  # 2 x11 (t7 r2 i3 / 0 o3 / 0 fd 8/8 cc -1)

# Das Gleiche wie oben, ca. 7-mal wiederholen

kate: kann keine Verbindung zum X-Server herstellen localhost: 10.0

UPD2 Bitte geben Sie Ihre Linux Distribution & Versionsnummer an.
Verwenden Sie eine standardmäßige GNOME- oder KDE-Umgebung für X oder etwas anderes, das Sie selbst angepasst haben?

azat: ~ $ kded4 -version
Qt: 4.7.4
KDE-Entwicklungsplattform: 4.6.5 (4.6.5)
KDE-Daemon: $ Id $

Rufen Sie ssh direkt über eine Befehlszeile von einem Terminalfenster aus auf?
Welches Terminal benutzen Sie? xterm, gnome-terminal oder?
Wie haben Sie das Terminal in der X-Umgebung gestartet? Aus einem Menü? Hotkey? oder ?

Vom Terminalemulator `yakuake`
Drücken Sie manuell "Strg + N" und schreiben Sie Befehle

Können Sie xeyes über dasselbe Terminalfenster ausführen, in dem ssh -X fehlschlägt?

`xeyes` - ist nicht installiert
Aber `kate` oder eine andere kde App läuft

Rufen Sie den Befehl ssh als der Benutzer auf, unter dem Sie in der X-Sitzung angemeldet sind?
From the same user

UPD3

Ich lade auch sshQuellen herunter und benutze debug2()write, um zu melden, dass die Version unterschiedlich ist.
Es werden einige Cookies angezeigt, von denen eines leer ist und eines leer istMIT-MAGIC-COOKIE-1

Der Grund, warum die Weiterleitung von ssh X nicht funktionierte, war, dass ich eine /etc/ssh/sshrcKonfigurationsdatei habe.

Das Ende der sshd(8)Manpage lautet:

Wenn ~/.ssh/rcvorhanden, wird es ausgeführt. Andernfalls wird /etc/ssh/sshrces ausgeführt, sofern es vorhanden ist. ansonsten läuft xauth

Daher füge ich die folgenden Befehle /etc/ssh/sshrc(auch von der sshd-Manpage) auf der Serverseite hinzu:

if read proto cookie && [ -n "$DISPLAY" ]; then
        if [ `echo $DISPLAY | cut -c1-10` = 'localhost:' ]; then
                # X11UseLocalhost=yes
                echo add unix:`echo $DISPLAY |
                    cut -c11-` $proto $cookie
        else
                # X11UseLocalhost=no
                echo add $DISPLAY $proto $cookie
        fi | xauth -q -
fi

Und es funktioniert!

Jedes Mal, wenn Sie Probleme mit ssh haben, sollten Sie als Erstes den Client mit der -vOption ausführen , diese Ausgabe für andere zur Überprüfung bereitzustellen:

ssh -v user@somewhere

Ich gehe davon aus, dass das Problem auf Ihrem lokalen System liegt. Wie rufen Sie den Befehl ssh auf? Führen Sie es manuell in einer Shell aus? Oder wird es als Teil eines Skripts ausgeführt? In beiden Fällen sollten Sie sicherstellen, dass auf Ihrem lokalen System die DISPLAYUmgebung richtig eingestellt ist. Es muss auch auf der Remote-Seite korrekt eingestellt sein, aber dieser Wert unterscheidet sich auf der Remote-Seite von dem auf der lokalen Seite.

Nach dem, was Sie geschrieben haben, scheint es, dass es auf dem Remote-Host richtig eingestellt ist (und als Erweiterung wird die X11-Weiterleitung von ssh richtig eingerichtet). Auf dem Remote-System haben Sie:

$ echo $DISPLAY
localhost:10.0

Was zeigt das auf der lokalen Seite? Das sollte einfach sein , zu überprüfen , ob Sie in einer Shell sind beide durch den Wert Echo, sowie das Starten ein X - App von dieser Shell ... Sie können immer die ehrwürdige verwenden xeyesfür diese Art von Prüfung, natürlich! :)

Wenn Sie andererseits den Befehl ssh von einem Skript aus aufrufen oder an einen Hotkey anhängen, erbt er möglicherweise nicht die erwartete DISPLAYUmgebung , sodass die Umgebungsvariable auf der lokalen Seite möglicherweise überhaupt nicht festgelegt wird.

Da es aussieht, als hätten Sie an Ihrer .XauthorityDatei herumgespielt, möchten Sie sie möglicherweise vollständig löschen. Melden Sie sich dann von Ihrer X-Sitzung ab und wieder an, damit sie automatisch neu erstellt wird. Es besteht selten die Notwendigkeit, sich mit Ihrer zu beschäftigen. Daher .Xauthorityist es wahrscheinlich nur eine verzweifelte Maßnahme, die nicht hilft.

Was Sie auf der lokalen Seite sehen sollten, ist:

$ echo $DISPLAY
:0.0

Wenn Sie auf einem ordnungsgemäß konfigurierten System eine Shell öffnen und diese nicht manuell festlegen müssen, sollte sie von der Umgebung geerbt werden, von der die Shell gestartet wurde. Allerdings habe ich Window Manager / Hotkey-Konfigurationen gesehen, die die Vererbung von Umgebungsvariablen nicht richtig handhaben. Wenn Sie ein Linux-System verwenden gnome-sessionoder von kde-sessiondem aus Sie Ihre Shells oder Skripte starten, sollten Ihre X-Sitzungsumgebungsvariablen wie in der Ubuntu-Dokumentation zur Vererbung von Umgebungsvariablen beschrieben korrekt festgelegt werden :

Wenn ein übergeordneter Prozess einen untergeordneten Prozess erstellt, z. B. wenn wir den Befehl "gedit" vom Terminal aus ausführen und "bash" (der übergeordnete Prozess) "gedit" (den untergeordneten Prozess) erstellt, übernimmt der untergeordnete Prozess alle Umgebungsvariablen und Werte, die der übergeordnete Prozess hatte.

...

Hinweis: In der grafischen Desktop-Umgebung von Gnome ist gnome-session der übergeordnete Prozess aller auf dem Desktop ausgeführten Prozesse. Diese Tatsache (zusammen mit dem Vererbungsprinzip) ist der Schlüssel zu unserer Fähigkeit, den Betrieb unseres Desktops mit Umgebungsvariablen stark zu beeinflussen. Der äquivalente Prozess in KDE ist kde-session.

AKTUALISIERT

Vielen Dank für die Veröffentlichung der Ausgabe von ssh -vvv. In diesem Fall ist die zusätzliche Ausführlichkeit von -vvvversus just -vhilfreich. Die Debug-Ausgabe teilt mir mit, dass die X11-Weiterleitung korrekt eingerichtet wurde:

debug2: x11_get_proto: /usr/bin/xauth  list :0 2>/dev/null
debug1: Requesting X11 forwarding with authentication spoofing.
debug2: channel 1: request x11-req confirm 1

Aber die :0erste Zeile lässt mich glauben, dass immer noch ein Konfigurationsfehler auf der lokalen Seite vorliegt, wie Sie ssh aufrufen. Auf vielen Systemen für den Standardwert DISPLAYist :0.0, nicht :0. Stellen Sie den Wert von DISPLAYmanuell ein, bevor Sie den Befehl ssh aufrufen?

Weitere Informationen zu Ihrem lokalen System und zum Aufrufen des Befehls ssh sind an dieser Stelle hilfreich.

• Bitte geben Sie Ihre Linux Distribution & Versionsnummer an.
• Verwenden Sie eine standardmäßige GNOME- oder KDE-Umgebung für X oder etwas anderes, das Sie selbst angepasst haben?
• Rufen Sie ssh direkt über eine Befehlszeile von einem Terminalfenster aus auf?
• Welches Terminal benutzen Sie? xterm, gnome-terminal oder?
• Wie haben Sie das Terminal in der X-Umgebung gestartet? Aus einem Menü? Hotkey? oder ?
• Können Sie xeyesvon demselben Terminalfenster aus ausführen, in dem das ssh -Xfehlschlägt?
• Rufen Sie den Befehl ssh als der Benutzer auf, unter dem Sie in der X-Sitzung angemeldet sind?

Dieser letzte Punkt ist wichtig. Wenn Sie ssh als anderer Benutzer ausführen (z. B. wenn Sie ein Root-Terminal-Fenster anstelle eines Benutzer-Terminal-Fensters geöffnet haben), tritt dieses Problem auch dann auf, wenn Sie dies explizit festlegen, DISPLAY=:0da Sie keine Berechtigungen für haben stelle standardmäßig eine Verbindung zum X-Server als anderer Benutzer her (sogar als root!)

Ihre Konfiguration scheint in Ordnung zu sein, aber versuchen Sie es mit "ssh -X home", wie von Agemen vorgeschlagen.

Wenn alles andere fehlschlägt, versuchen Sie Folgendes:

Nachdem Sie von der Arbeit zu Ihrem Heimcomputer gesendet haben, geben Sie "home" ein:

xauth list

Geben Sie dann auf "Arbeit" ein

xauth

Womit Sie eine "xauth>" - Eingabeaufforderung erhalten. Geben Sie hier "add" ein und kopieren Sie dann die Ausgabe der "xauth list" zeilenweise (jede Zeile mit dem Präfix "add"). Beispielsweise:

someguy@work:~$ xauth
Using authority file /var/run/gdm/auth-for-someguy-4MYV85/database
xauth> add work/unix:0  MIT-MAGIC-COOKIE-1  781cc753194fd55ecdf6c4cf105c40e3
xauth> 

Lass uns wissen.

Ich verstehe nicht genau, ob Sie Ihre Remote-Apps auf Ihrem lokalen Bildschirm anzeigen workmöchten ( ) oder ob Sie sie auf dem Remote-System anzeigen möchten ( home).

Im ersten Fall sollte es meiner Meinung ssh -X hostnach reichen, ohne xhost zu verwenden.

Im zweiten Fall ist das System, auf dem Sie xhost verwenden müssen home, und es reicht nicht aus, dass Sie auch die Anzeigevariable exportieren müssen.

xhost +work
export DISPLAY=:0.0

Ich bin mir nicht ganz sicher, was Sie tun möchten ... und da ich nicht weiß, welche Unterschiede zwischen Ihrem und meinem System bestehen, und andererseits die genaue Konfiguration, die für Sie erforderlich ist Ich bin kein Spezialist ^ _ ^). Hoffe, es wird dir in gewisser Weise helfen, da auch diese Konfigurationen für mich funktioniert haben.