Guten Morgen, Oleg! Oleg schrieb (Sat 2002-Apr-20 04:36:53 +0200): > Wenn ich auf dem Client nacheinander > xhost +hans > ssh hans > gkrellm & > eingebe, klappt auch alles wunderbar,... Das ist schön, aber da findet kein Forwarding welcher Art auch immer statt. (Und ich frage mich ja, woher das "gkrellm" das Display kennt; laut dem Rest Deiner Mail kann das gar nicht sein...) > xhost +hans && ssh hans gkrellm > ("Gtk-WARNING **: cannot open display: ") Keine DISPLAY-Variable gesetzt, sonst stünde nach dem "display: " der Wert. > xhost +hans && ssh -X hans gkrellm > (nach einigen Minuten (!!!): "Gtk-WARNING **: cannot open display: > hans:10.0" Hier sind wir am Knackpunkt und schieben mal ein wenig Theorie ein: Ein X-Client (z.B. xterm) und ein X-Server (z.B. XFree86) unterhalten sich über eine TCP-Verbindung, die der Client zum Server aufbaut. Der Client weiß, wohin er die Verbindung aufbauen soll, indem er den Inhalt der DISPLAY-Variable anaylsiert (oder den Wert beim Aufruf übergeben bekommt). Aus der DISPLAY-Variable muss der Client also eine IP-Adresse oder Hostnamen und einen Port extrahieren. Dafür ist im X-Protokoll vorgesehen, dass alles vor dem Doppelpunkt, der vorhanden sein _muss_, der Hostname ist und alles nach dem Doppelpunkt die Display-Nummer, gefolgt von der Nummer des Screens. Weiterhin ist festgelegt, dass ein Display mit der Nummer N auf dem Port 6000+N zu erreichen ist. Ist der Hostname nicht angegeben, wird von "localhost" ausgegangen. Spielt sich also alles auf nur einem Rechner ab, ist die DISPLAY-Variable auf ":0.0" und es werden lauter TCP-Verbindungen zu "localhost:6000" aufgemacht. (Die Nummer des Screens ignorieren wir jetzt einfach mal, ist hier nicht relevant.) Jetzt tun wir mal so, als wolltest Du per Hand eine solche Verbindung zwischen X-Client und X-Server durch SSH tunneln. Du hast den X-Server auf der Maschine mit dem SSH-Client und den X-Client auf der Maschine mit dem SSH-Server. Dann rufst Du Dein SSH auf: ssh -R6123:localhost:6000 user@server (Wer hier jetzt ausgestiegen ist, frage einfach nach.) Auf der Seite mit dem SSH-Server setzt Du dann export DISPLAY=:123 und wenn Du anschließend ein xterm aufrufst, wird es sich zu localhost:6123 verbinden. Dort lauscht der SSH-Daemon, der die Daten alle entgegennimmt und auf der Seite des SSH-Clients in eine TCP-Verbindung zu "localhost:6000" steckt. (Achtung: "localhost" wird mal auf der einen und mal auf der anderen Seite aufgelöst.) => Voilà, die X-Kommunikation ist verschlüsselt. Jetzt kann es aber sein, dass Du auf der Seite mit dem SSH-Client gar nicht Display 0 (auf Port 6000) benutzen willst, sondern Display 1 (auf Port 6001). Das musst Du also nachschauen (DISPLAY-Variable) oder wissen, bevor Du SSH aufrufst. Und es könnte sein, dass auf der Seite mit den SSH-Daemon der Port 6123 schon belegt ist. Ist nicht weiter wild, dann weichst Du halt aus auf 6124 und setzt die DISPLAY-Variable entsprechend. Und der Clou ist nun, dass SSH Dir dieses Nachschauen abnimmt. Wenn Du es aufforderst, ein X-Forwarding zu machen, schaut es auf Seite des SSH-Clients nach der DISPLAY-Variable und merkt sich die als Ziel für die vom SSH-Client aufzubauende TCP- Verbindung. Auf Server-Seite versucht der SSH-Daemon sich eine Socket auf Port 6010 geben zu lassen, und falls das nicht klappt, auf 6011, dann 6012 usw.. Wenn er dann eine hat, setzt er die DISPLAY-Variable (also auf ":6010" o.ä.) und ruft das gewünschte Programm auf. Kommen wir zurück zum Thema: > xhost +hans > ssh hans > gkrellm & Hier ist nichts verschlüsselt, wie oben schon geschrieben. Ich vermute mal, Du hast die DISPLAY-Variable per Hand gesetzt und vergessen, das hier mit hinzuschreiben. Das "gkrellm" baut eine TCP-Verbindung zu "client:6000" auf, und alles ist in Ordnung. > xhost +hans && ssh hans gkrellm > ("Gtk-WARNING **: cannot open display: ") Das "gkrellm" weiss halt nicht, wohin es connecten soll. > xhost +hans && ssh -X hans gkrellm > (nach einigen Minuten (!!!): "Gtk-WARNING **: cannot open display: > hans:10.0" Hier war SSH mit seinen Port-Forwarding-Versuchen anscheinend erfolgreich und hat sich auf "hans" den Port 6010 gekrallt. Wir sehen hier auch schön, dass dieser SSH-Daemon die DISPLAY- Variable offensichtlich nicht auf ":10.0" oder "localhost:10.0" zeigen lässt, sondern auf "hans:10.0". Ob das jetzt gut oder schlecht ist, weiß ich auch nicht. Jedenfalls kann "gkrellm" vom Rechner "hans" aus keine TCP- Verbindung zum Rechner "hans" auf Port 6010 aufbauen. Da Du schreibst, dass der Rechner "hans" Dein Router sei und es einige Minuten dauert, gehe ich davon aus, dass Dein Paketfilter die SYN-Pakete wegschmeißt und kein ICMP-unreachable sendet. Alternativ könnte das Auflösen von "hans" in die Hose gehen. "hans" sollte nicht auf 127.0.0.1 auflösen (das soll nur "localhost"), sondern auf eine der IP-Adressen, die der Rechner hat. Die Kommunikation von einem Linux-Rechner zu einer seiner eigenen IP-Adressen ungleich 127.0.0.1 erfolgt auch über das Loopback-Interface. Schau Dir also da mal die Filterregeln an. Ein Punkt noch, auf den Du aber sicher inzwischen auch selbst gekommen bist: Den Aufruf von "xhost" kannst Du Dir sparen, denn wir wissen ja jetzt, dass die Verbindung zu Deinem X-Server vom SSH-Client aufgemacht wird. Und üblicherweise ist das dann vom selben Rechner aus und somit erlaubt. [Die Abhandlung über Authentifizierung bei X lassen wir jetzt mal weg. Nur für den Fall, dass da was kommt: Es ist immer ganz gut, ein "xauth" installiert zu haben.] > ein export DISPLAY=":0" ändert überhaupt nichts. Das glaube ich nicht. Entweder, das hier funktioniert auch, oder das, was Du als erstes geschrieben hast, funktioniert auch nicht. Aber ist ja schnurz, jetzt weißt Du ja, wie's geht. :-) Grüße, Marcus -- Marcus C. Gottwald · http://www.inf.fu-berlin.de/~gottwald/kontakt.html _______________________________________________ splinux mailing list - splinux@lists.spline.de http://lists.spline.de/mailman/listinfo/splinux