PDA

Archiv verlassen und diese Seite im Standarddesign anzeigen : X11forwarding funktioniert nicht mehr



michel_vaclav
28.01.14, 18:25
Hallo zusammen,

nachdem ja die Tage der Support für openSUSE 12.2 ausgelaufen ist, habe ich meinen Rechner im Keller auf 12.3 aktualisiert.

Alles läuft bis auf das Starten von X-Anwendungen auf der Remote-Kiste.

Normalerweise verwende ich:
ssh -X user@remotebox programmMit 12.3 funktioniert das nicht mehr. Man erhält keinerlei Rückmeldung, es findet sich nichts in den mir bekannten Log-Files.

Starte ich den Befehl im verbose-Mode, erhalte ich beispielsweise:

ssh -v -X user@remotebox xeyes
OpenSSH_6.2p2, OpenSSL 1.0.1e 11 Feb 2013
debug1: Reading configuration data /etc/ssh/ssh_config
debug1: /etc/ssh/ssh_config line 20: Applying options for *
debug1: Connecting to remotebox [192.168.2.1] port 22.
debug1: Connection established.
debug1: identity file /home/user/.ssh/id_rsa type 1
debug1: identity file /home/user/.ssh/id_rsa-cert type -1
debug1: identity file /home/user/.ssh/id_dsa type -1
debug1: identity file /home/user/.ssh/id_dsa-cert type -1
debug1: identity file /home/user/.ssh/id_ecdsa type -1
debug1: identity file /home/user/.ssh/id_ecdsa-cert type -1
debug1: Enabling compatibility mode for protocol 2.0
debug1: Local version string SSH-2.0-OpenSSH_6.2
debug1: Remote protocol version 2.0, remote software version OpenSSH_6.1
debug1: match: OpenSSH_6.1 pat OpenSSH*
debug1: SSH2_MSG_KEXINIT sent
debug1: SSH2_MSG_KEXINIT received
debug1: kex: server->client aes128-ctr hmac-md5 none
debug1: kex: client->server aes128-ctr hmac-md5 none
debug1: sending SSH2_MSG_KEX_ECDH_INIT
debug1: expecting SSH2_MSG_KEX_ECDH_REPLY
debug1: Server host key: ECDSA 10:11:12:13:9b:15:dd:17:22:1a:27:3e:a7:69:bc:69
debug1: Host 'remotebox' is known and matches the ECDSA host key.
debug1: Found key in /home/user/.ssh/known_hosts:1
debug1: ssh_ecdsa_verify: signature correct
debug1: SSH2_MSG_NEWKEYS sent
debug1: expecting SSH2_MSG_NEWKEYS
debug1: SSH2_MSG_NEWKEYS received
debug1: Roaming not allowed by server
debug1: SSH2_MSG_SERVICE_REQUEST sent
debug1: SSH2_MSG_SERVICE_ACCEPT received
debug1: Authentications that can continue: publickey,keyboard-interactive
debug1: Next authentication method: publickey
debug1: Offering RSA public key: /home/user/.ssh/id_rsa
debug1: Server accepts key: pkalg ssh-rsa blen 279
debug1: read PEM private key done: type RSA
debug1: Authentication succeeded (publickey).
Authenticated to remotebox ([192.168.2.1]:22).
debug1: channel 0: new [client-session]
debug1: Requesting no-more-sessions@openssh.com
debug1: Entering interactive session.
debug1: Requesting X11 forwarding with authentication spoofing.
debug1: Sending environment.
debug1: Sending env LANG = de_DE.UTF-8
debug1: Sending command: xeyes
Und dann passiert nix mehr.

Ohne XForwarding komme ich problelos auf die Kiste.

Irgend welche Ideen?

Der Vollständigkeit halber: die sshd_config ist die identische wie früher unter 12.2.

Danke

michel_vaclav

DrunkenFreak
28.01.14, 19:16
Häng nochmal zwei "v" mehr dran für eine detailiertere Ausgabe. Vielleicht lässt sich damit ein Fehler sehen.

marce
28.01.14, 19:24
ich würde im Logfile des XServers irgendwas erwarten - ggf. schau mal, ob der Port offen ist und ob xhost + gesetzt ist.

michel_vaclav
28.01.14, 19:57
@marce: xhost+ ist ja serverseitig zu setzen. Ich habe das in der Vergangenheit nie machen müssen, vielleicht hab ich es irgendwo auf meinem Arbeitsplatz-PC eingetragen. Als der Kellerrechner noch die 12.2 drauf hatte, gings ja. Aber es hilft auch nicht, wenn ich es vorher setze.

@DrunkenFreak: auch -vvv hat nichts Erhellendes gebracht, endet an der gleichen Stelle.

Aber: wenn man den Befehl gefühlte 5 Minuten stehen lässt kommt:
Xt error: Can't open display: remotebox.localhost:10.0
Dies steht auch in der DISPLAY-Variablen.
Wo oder bei welcher Gelegenheit wird die gesetzt? Und was müsste da richtigerweise stehen?
Ein DISPLAY=linux:0.0 (linux ist mein Arbeitsplatz-PC) hilft auch nix.

michel_vaclav

marce
28.01.14, 20:00
probier statt dem Hostnamen mal die IP.

karl-heinz-lnx
28.01.14, 20:14
Und was passiert wenn die DISPLAY Variable diesen Wert hat?

DISPLAY=remotebox.localhost:10.0

michel_vaclav
28.01.14, 20:17
probier statt dem Hostnamen mal die IP.
Nicht die Lösung, dann kommt:
xterm: Xt error: Can't open display: 192.168.2.2:0.0

DrunkenFreak
28.01.14, 20:19
Exisitiert denn auf dem Zielsystem das Display 0 und hast du auch die Rechte darauf?

michel_vaclav
28.01.14, 20:19
Und was passiert wenn die DISPLAY Variable diesen Wert hat?

DISPLAY=remotebox.localhost:10.0
Dann passiert gar nix, nicht mal die Fehlermeldung, dass er sich nicht mit dem Xserver verbinden kann. Weder mit Klarnamen noch mit IP.

marce
28.01.14, 20:19
auch erst nach 5 Minuten oder schneller?

ob 0:0 oder andere "übliche" Werte - das auch schon mal durchprobiert?

michel_vaclav
28.01.14, 20:19
Exisitiert denn auf dem Zielsystem das Display 0 und hast du auch die Rechte darauf?

Wie krieg ich das raus? Das hab ich noch nie gebraucht.

DrunkenFreak
28.01.14, 20:21
Mit ps wäre eine Möglichkeit. Rechte setzt du zur Not mit xhost.

michel_vaclav
28.01.14, 20:26
Mit ps wäre eine Möglichkeit. Rechte setzt du zur Not mit xhost.

Lokal zeigt ps Einträge wie
root 2210 0.0 0.0 82500 2600 ? S 14:42 0:00 -:0
Auch die DISPLAY-Variable lokal sagt ":0", daher gehe ich davon aus, dass es zum Einen existiert und ich zum anderen die rechte habe.

michel_vaclav
28.01.14, 20:29
auch erst nach 5 Minuten oder schneller?

ob 0:0 oder andere "übliche" Werte - das auch schon mal durchprobiert?

Nach noch längerer Wartezeit kommt doch wieder die gleiche Meldung wie oben.
Und ich hab jetzt von 0:0 bis 15:0 alles probiert, ohne Erfolg.

DrunkenFreak
28.01.14, 20:33
Auch die DISPLAY-Variable lokal sagt ":0", daher gehe ich davon aus, dass es zum Einen existiert und ich zum anderen die rechte habe.
Von irgendwas ausgehen bedeutet nicht, es zu wissen.

michel_vaclav
28.01.14, 20:36
Von irgendwas ausgehen bedeutet nicht, es zu wissen.
Richtig.
Daher: ich weiß es nicht! Daher auch meine Frage, wie ich das raus bekomme.

Ich bin parallel am Suchen, wie ich in Erfahrung bringen kann, ob ich nun Rechte habe oder nicht.

edit: ich korrigiere: ich weiß es. Denn ich habe xhost + gesetzt mit der Antwort: "access control disabled, clients can connect from any host"

DrunkenFreak
28.01.14, 20:37
Zum mittlerweile dritten Mal: xhost!

michel_vaclav
28.01.14, 20:42
Zum mittlerweile dritten Mal: xhost!
Wie ich #4 und #16 geschrieben habe, ein xhost + hilft auch nicht.
Wenn Du mit xhost! etwas anderes meinst, dann steh ich auf dem Schlauch. Sorry.

pibi
29.01.14, 09:33
nachdem ja die Tage der Support für openSUSE 12.2 ausgelaufen ist, habe ich meinen Rechner im Keller auf 12.3 aktualisiert.Warum nicht gleich auf die 13.1?
Alles läuft bis auf das Starten von X-Anwendungen auf der Remote-Kiste.Hast Du zufaellig IPv6-Support in den Netzwerkeinstellungen des Rechners im Keller deaktiviert? Wenn ja, schalte es mal ein. Sonst geht es bei mir auch nicht. Sonderbar, aber reproduzierbar.

Gruss Pit.

heatwalker
29.01.14, 15:29
Das Problem hatte ich ebenfalls an einem Server.
Versuch mal

ssh -T -X host programm
oder

ssh -t -X host programm

michel_vaclav
29.01.14, 17:20
Warum nicht gleich auf die 13.1?Hast Du zufaellig IPv6-Support in den Netzwerkeinstellungen des Rechners im Keller deaktiviert? Wenn ja, schalte es mal ein. Sonst geht es bei mir auch nicht. Sonderbar, aber reproduzierbar.

Gruss Pit.

Ich hatte zu wenig Zeit, um die Kiste danach wieder so zu konfigurieren, dass alles läuft. Ich war der Meinung, ein Upgrade ginge schneller. Und eine Version auszulassen beim upgrade war mir zu risikant. Ich werde aber sicherlich in absehbarer Zeit den Upgrade auf 13.1 wagen.

Wegen IPv6: ja, es war abgeschalten. Das Einschalten hat aber leider auch nicht den gewünschten Erfolg gezeigt. Trotzdem danke.

michel_vaclav

michel_vaclav
29.01.14, 17:21
Das Problem hatte ich ebenfalls an einem Server.
Versuch mal

ssh -T -X host programm
oder

ssh -t -X host programm
Beides bleibt genauso hängen.

Auch Dir danke

michel_vaclav

michel_vaclav
06.02.14, 09:59
Hallo zusammen,

das Problem ist nun beseitigt.
Ich hatte aufgrund eines wlan-Problems dann den Server im Keller doch auf die Version 13.1 gehoben (Neuinstallation). Dabei ging sofort das X11-Forwarding per ssh. Da ich dann doch wissen wollte, was jetzt anders ist, habe ich Diverses verglichen und bin fündig geworden.
In der neuen /etc/ssh/ssfd_config taucht eine Variable
X11UseLocalhost no auf. Die hatte ich in meiner alten Konfiguration nicht. Ob die vielleicht auf der Version 12.3, die ich zwischendurch hatte, auf "yes" war, kann ich nun nicht mehr sagen, aber ich vermute es stark, denn die Display-Variable war ja immer auf
remotebox.localhost:10.0gesetzt, jetzt taucht nur noch
remotebox:10.0auf.

michel_vaclav