Hallo Leute. Nehmen wir an, wir haben einen lokalen Rechner A und einen entfernten Rechner C. Mit einem ssh -X andy@C kann ich mich auf C einloggen und X-Programme starten. Wenn ich aber einen Umweg über Rechner B nehmen muß, dann geht das nicht mehr: ssh -X andy@B und dann auf B: ssh -X andy@C dann kommt beim Versuch, ein X-Programm zu starten: Gtk-WARNING **: cannot open display: Wie stelle ich es an, daß dennoch ein Display geöffnet werden kann? Es grüßt Andy -- Antworten an lists@feile.net werden in /dev/null archiviert! Bitte ggf. lists... durch mail... ersetzen. Andreas Feile www.feile.net
hallo,
Wie stelle ich es an, daß dennoch ein Display geöffnet werden kann? gtk pakete nachinstallieren?
gruss rs -- Nur weil du paranoid bist, heisst das noch lange nicht, dass du nicht verfolgt wirst!! -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- AMD Athlon XP 3200+ / A7N8X-E Deluxe / 1 GB DDRAM / SuSE 9.1 + KDE 3.2.1
Raffael Schmid, Donnerstag, 14. Oktober 2004 12:01:
gtk pakete nachinstallieren?
Auf welcher Maschine denn? Auf A und C ist der ganze Krams drauf. Auf B ist überhaupt kein X, aber da brauch ichs auch nicht, das Dings ist nur zum ssh-Login da. Und man wird ja die GTK-Pakete nicht brauchen, um den ssh-Datenstrom von irgendwo nach irgendwo weiterzureichen, oder? -- Antworten an lists@feile.net werden in /dev/null archiviert! Bitte ggf. lists... durch mail... ersetzen. Andreas Feile www.feile.net
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 On Thursday 14 October 2004 12:11, Andreas Feile wrote:
Auf welcher Maschine denn? Auf A und C ist der ganze Krams drauf. Auf B ist überhaupt kein X, aber da brauch ichs auch nicht, das Dings ist nur zum ssh-Login da. Und man wird ja die GTK-Pakete nicht brauchen, um den ssh-Datenstrom von irgendwo nach irgendwo weiterzureichen, oder?
Du brauchst ein Programm namens xauth auf jedem mit ssh -X angesprochenen Rechners. Wenn Du auf B kein X installieren willst, dann bau doch einen Tunnel: ssh -L 3333:C:22 sleep 100000000& Danach solltest Du mit ssh -p 3333 -X localhost auf C landen und X Programme ausführen können. ssh könnte dann aber meckern, dass localhost seinen Hostkey geändert hat, da ja eigentlich C antwortet. Das kannst Du sauber mit einem Alias in Deiner ~/.ssh/config lösen: Host c_alias ForwardX11 yes HostKeyAlias C Hostname 127.0.0.1 Port 3333 Protocol 2 Nun sollte: ssh c_alias mit laufendem Tunnel funktionieren und gleich Dein Display weiterleiten. Übrigens müsstest Du bei einem "ssh -X B" eine Fehlermeldung über ein fehlendes xauth sehen. Torsten -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.2.4 (GNU/Linux) iD8DBQFBbnITwicyCTir8T4RAr27AJ9BekVA4HotJKiBFfWSQdr0u0BDVQCgunob lA/nTEKzlrZL9I9uMbpA67w= =NPAU -----END PGP SIGNATURE-----
Moin Torsten, Torsten Förtsch, Donnerstag, 14. Oktober 2004 14:33:
Wenn Du auf B kein X installieren willst, dann bau doch einen Tunnel:
ssh -L 3333:C:22 sleep 100000000&
Da muß doch vor dem sleep was rein, oder? Sollte das nicht vielleicht ssh -L 3333:C:22 && sleep 100000000& heißen? Andernfalls kommt nämlich # 13284: ssh: sleep: Name or service not known Danke+Gruß. Andy -- Antworten an lists@feile.net werden in /dev/null archiviert! Bitte ggf. lists... durch mail... ersetzen. Andreas Feile www.feile.net
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 On Monday 18 October 2004 17:25, Andreas Feile wrote:
Torsten Förtsch, Donnerstag, 14. Oktober 2004 14:33:
Wenn Du auf B kein X installieren willst, dann bau doch einen Tunnel:
ssh -L 3333:C:22 sleep 100000000&
Da muß doch vor dem sleep was rein, oder? Sollte das nicht vielleicht
Freilich muss da nochwas rein: ssh -L 3333:C:22 USER@B sleep 100000000& Der Gedanke ist folgender: Du baust als erstes einen Tunnel über B zu C, Das ist obige Zeile. Das sleep Kommando wird auf B ausgeführt. Das Ganze dient ausschließlich der Aufrechterhaltung des Tunnels. Nachdem Du den Tunnel im Hintergrund gestartet hast, ist auf localhost der Port 3333 offen. Da laushct Dein ssh client. Jede Verbindung die auf diesem Port ankommt, wird über B an C, Port 22 weitergeleitet. Auf Port 22 lauscht aber gerade der sshd auf Rechner C. Machst Du jetzt ein "ssh -p 3333 localhost", so redest Du eigentlich mit dem sshd auf C. Auf dem Weg von localhost nach B sind die Daten doppelt verschlüsselt. B packt sie aus und schickt den einfach verschlüsselten Datenstrom weiter nach C. Damit sollte mit "ssh -X -p 3333 localhost xterm" dann ein xterm aufgehen und den Prompt von C anzeigen. Die Eingabe von "echo $DISPLAY" sollte "localhost:10.0" o.ä. ergeben. Falls Du eine Verbindung zu B hast, die nach einer Weile Inaktivität von selbst schließt (modem, ...), dann ist es vielleicht besser statt einem sleep Kommando auf B irgendwas anderes zu machen. Ich benutze hier z.B. folgendes Script: ... ssh-add ~/.ssh/id_dsa || { echo "ssh-add failed." >&2 exit 2 } ... xterm -e ssh \ -L 2226:C1:22 \ -L 4436:C1:443 \ -L 5436:C1:5432 \ -L 2223:C2:22 \ -L 4433:C2:443 \ -L 2225:C3:22 \ -L 4435:C3:443 \ -L 5435:C3:5432 \ user@B \ bash -c \''while date; do sleep 10; done'\' /dev/null 2>&1 & ... Damit wähle ich mich per ISDN in einen Rechner (eigentlich B) ein. Dann öffnet das Script den Port 22 für genau meine IP Adresse. Danach wird das xterm gestartet und der Port wieder dicht gemacht. Die Firewall auf B ist so konfiguriert, dass sie bestehende Verbindungen durchlässt. "Dichtmachen" heißt in diesem Zusammenhang "keine neuen Verbindungen annehmen". Nun kann ich, solange das xterm offen ist, die Ports 443 (https) und 22 (ssh) auf C1,C2,C3 und Port 5432 (postgres) auf C1 und C3. B erscheint aus dem Internet als völlig geschlossen. C* haben gar keine öffentliche IP Adressen. Wenn die Verbindung zufällig abgebrochen wird (weil ich meinen Rechner ausschalte), kriegt das nächste "date" Kommando auf B ein SIGPIPE und stirbt, worauf die while Schleife und damit die bash endet. Torsten -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.2.4 (GNU/Linux) iD8DBQFBc/VVwicyCTir8T4RAi1QAKCKDGQJTjftYKsZ5du441GIGIe0CQCeN/+4 vD6fpGlDQck20BE8xRWPMv4= =j0Gd -----END PGP SIGNATURE-----
Servus Torsten. Torsten Förtsch, Montag, 18. Oktober 2004 18:54:
ssh -L 3333:C:22 USER@B sleep 100000000& [...] Damit sollte mit "ssh -X -p 3333 localhost xterm" dann ein xterm aufgehen und den Prompt von C anzeigen. Die Eingabe von "echo $DISPLAY" sollte "localhost:10.0" o.ä. ergeben.
Das funktioniert nun alles, und ich hab auch den Sinn hinter der ssh-Konstruktion verstanden. Mit xterm funktioniert es nun auch. Aber wenn ich versuche galeon zu starten, dann wird gemerkert: /opt/gnome/bin/gconfd-1: line 6: exec: gconfd-1.bin: not found Lokal läßt sich galeon aber problemlos starten. Starte ich konqueror, dann bekomme ich ein Popup-Fenster mit dem Titel DCOP communications error, in dem es heißt Could not read network connection list. /home/gast/.DCOPserver_C_localhost_11 Please check that the "dcopserver" program is running! Es ergibt # echo $DISPLAY localhost:11.0 Woran mangelt es nunmehr? Danke+Gruß. Andy -- Antworten an lists@feile.net werden in /dev/null archiviert! Bitte ggf. lists... durch mail... ersetzen. Andreas Feile www.feile.net
Andreas Feile schrieb am 10/14/2004 12:11 PM:
Raffael Schmid, Donnerstag, 14. Oktober 2004 12:01: Auf A und C ist der ganze Krams drauf. Auf B ist überhaupt kein X, aber da brauch ichs auch nicht, das Dings ist nur zum ssh-Login da.
Da liegt das Problem. Wenn über einen Rechner X per ssh automatisch getunnel werden soll, muß auf der Kiste X installiert werden (AFAIK ist xauth oder so nötig). Es geht theoretisch auch ohne, aber nicht ohne manuelle Fummelei. Michael.
Hallo Thorsten, hallo Andreas, hallo Leute, Am Donnerstag, 14. Oktober 2004 15:51 schrieb Dr. Thorsten Brandau:
Andreas Feile wrote: [ssh -X über mehrere Stationen]
Wie stelle ich es an, daß dennoch ein Display geöffnet werden kann?
export DISPLAY=A:0.0
Lieber nicht, sonst laufen alle Daten des X-Programms *unverschlüsselt* über die Leitung. "Daten" sind in diesem Zusammenhang die Bildschirmausgabe des Programms sowie sämtliche Eingaben. Gruß Christian Boltz -- PS: Ich denke, wir unterhalten uns hier lieber mit Menschen statt mit Mohnbroetchen... [Thomas Hertweck zu fo_mohnbroetchen(AT)gmx.de in suse-linux]
participants (6)
-
Andreas Feile
-
Christian Boltz
-
Dr. Thorsten Brandau
-
Michael Schachtebeck
-
Raffael Schmid
-
Torsten Förtsch