Archiv verlassen und diese Seite im Standarddesign anzeigen : Umgebungsvariable DISPLAY und SSH-X11-forwarding für Anfänger
englandschorsch
04.05.07, 14:36
Hallo zusammen,
ich hab mal ne Anfängerfrage zum Thema Display-/XServer-Adresse und der Umgebungsvariable $DISPLAY. Ich verstehe das grundlegende Client-Server-Prinzip des XWindow-Systems, aber das mit der Display-Adresse habe ich noch nie so ganz verstanden.
Auf meinen Linux Server enthält $DISPLAY den Wert "localhost:10.0".
Grundlegende Frage: Was beschreibt der Wert 10.0 genau? Ist 10 die Nummer des XServers? Was beschreibt die 0? Werden die Nummern beliebig from XServer vergeben? Gibt es sowas wie eine XServer-Registrierung???
Jetzt zu meinem eigentlichen Problem:
Ich habe außerdem Putty und den XServer Xming (http://sourceforge.net/projects/xming) auf meiner Windows-Maschine laufen, von wo aus ich mich mit SSH und X11-forwarding mit meinem Linux-Server verbinde.
Laut Logfile läuft der Xming-XServer unter Windows auf "localhost:0.0", was ich auch in den X11-Einstellungen in Putty eingebe.
Das X11-Forwarding läuft wunderbar, solange ich mich als "Schorsch" einlogge. Ich kann dann sogar per "su" zu "Root" wechseln und als Root GUI-Applikationen starten.
Verbinde ich mich jedoch umgekehrt als "Root" und wechsle per "su Schorsch" zu meinem normalen User und starte dann eine GUI-Applikation wie Konqueror, bekomme ich die Fehlermeldung:
Xlib: connection to "localhost:10.0" refused by server
Xlib: PuTTY X11 proxy: MIT-MAGIC-COOKIE-1 data did not match
konqueror: cannot connect to X server localhost:10.0
Warum schaut mein Remote Server in diesem Fall in seine lokale $DISPLAY Variable, anstatt die Displayadresse die per SSH reinkommt zu nehmen???
Die $DISPLAY Variable wird nicht vererbt. SSH öffnet einen Stream zu dem remote-Xserver auf 127.0.0.1:10.0, zudem sich die Xclients verbinden können. Die Display Variable wird Standardmäßig so gesetzt, wenn ssh mit dem Flag -X aufgerufen wird und die entsprechende Konfigurationsvariable in /etc/ssh/sshd_config gesetzt ist.
Die DISPLAY Variable teilt sich wie folgt auf:
<Nummer des Xservers:Nummer des Displays>
Gruß,
phnord
englandschorsch
08.05.07, 10:21
Die $DISPLAY Variable wird nicht vererbt. SSH öffnet einen Stream zu dem remote-Xserver auf 127.0.0.1:10.0, zudem sich die Xclients verbinden können. Die Display Variable wird Standardmäßig so gesetzt, wenn ssh mit dem Flag -X aufgerufen wird und die entsprechende Konfigurationsvariable in /etc/ssh/sshd_config gesetzt ist.
Die DISPLAY Variable teilt sich wie folgt auf:
<Nummer des Xservers:Nummer des Displays>
Gruß,
phnord
OK, erst einmal danke für Deine Antwort, aber ich versteh's trotzdem noch nicht. :p
Hast Du meine zweite Frage überhaupt beantwortet? Sorry, aber ich brauch ne Noob-gerechte Antwort. ^^
Warum funktioniert das alles, wenn ich mich als "Schorsch" anmelde, nicht aber wenn ich mich als "Root" anmelde? Das kann ja nicht mit der Vererbung zusammenhängen. Den offensichtlich wird es ja von Schorsch zu Root "vererbt", aber nicht von Root zu Schorsch.
Außerdem liefert ein "echo $DISPLAY" in beiden Fällen den lokalen XServer "localhost:10.0", obwohl die Ausgabe ja an meinen Windows XServer weitergescheckt wird. Warum verändert SSH die DISPLAY-Variable nicht sichtbar für mich? Welche Hintergrund-Magie geht da von statten? Und warum klappt diese Magie im zweiten Szenario nicht wenn ich per "su Schorsch" den User wechsle.
Und zum Format der DISPLAY-Variable noch. Was ist eine Displaynummer? Wie stehen XServernummer und Displaynummer im Verhältnis zueinander? Macht es Sinn mehrere XServer auf einem Rechner laufen zu lassen? Oder mehrere Displays? Wenn ja, wann macht das Sinn und was muss ich beachten?
gib als User "Schorsch" mal "xhost +" ein und probier es danach erneut als root. wenn dein X-System unterm "Schorsch" läuft hat dieser zunächst auch die alleinigen Rechte für solche Sessions.
Welche Distribution hast du am Start?
englandschorsch
08.05.07, 11:18
gib als User "Schorsch" mal "xhost +" ein und probier es danach erneut als root. wenn dein X-System unterm "Schorsch" läuft hat dieser zunächst auch die alleinigen Rechte für solche Sessions.
Welche Distribution hast du am Start?
Danke für den Tipp, aber ich bekomme immer noch dieselbe Fehlermeldung. Wenn ich mich als root anmelde und "xhost +" eingebe, bekomme ich die Bestätigung:
access control disabled, clients can connect from any hostIch bekomme aber als "Schorsch" immer noch diesselbe Fehlermeldung. Aber ich denke, dass Problem ist, das "xhost +" ja nur den lokalen XServer auf dem Remoteserver verwaltet.
Wie managed SSH das X11 forwarding? Wie gesagt, SSH scheint ja nicht die DISPLAY-Variable zu verändern. Die zeigt immer auf 127.0.0.1:10.0
Kann mir niemand diese "Magie" erklären? :confused:
Meine Distro ist ein recht aktuelles CentOS Linux (hab gerade die Versionsnummer nicht parat), ich hab dasselbe Problem mit einem anderen Fedora Server.
127.0.0.1:10.0 wird von dem SSH-Server gesetzt, zu dem du dich verbindest. Ist das X-Forwarding für die Session aktiv und der user eingeloggt wird diese Variable gesetzt, die eine aeh Schnittstelle zu deinem XServer darstellt. Die XClients verbinden sich zu diesem Socket und werden dann von dem SSH Server zu deinem XServer geroutet.
Also A verbindet sich nach B. Der SSH-Daemon auf B erkennt das X-Forwaring gewollt und erlaubt ist und setzt $DISPLAY auf 127.0.0.1:10.0, wo der SSHd horcht. Alle Anfragen von XClients laufen jetzt auf diese Adresse, werden vom SSHd genommen, durch den SSH-Tunnel gejagt und am Ende an deinen X-Server übergeben *kotz* von dem du kommst. Anschliessend gehts ganz normal weiter.
Gruß
Ach ja, mit "Magie" hat das nix zu tun, siehe dazu z.B. http://de.wikipedia.org/wiki/Cookie
:ugly:
englandschorsch
08.05.07, 16:34
127.0.0.1:10.0 wird von dem SSH-Server gesetzt, zu dem du dich verbindest. Ist das X-Forwarding für die Session aktiv und der user eingeloggt wird diese Variable gesetzt, die eine aeh Schnittstelle zu deinem XServer darstellt. Die XClients verbinden sich zu diesem Socket und werden dann von dem SSH Server zu deinem XServer geroutet.
Also A verbindet sich nach B. Der SSH-Daemon auf B erkennt das X-Forwaring gewollt und erlaubt ist und setzt $DISPLAY auf 127.0.0.1:10.0, wo der SSHd horcht. Alle Anfragen von XClients laufen jetzt auf diese Adresse, werden vom SSHd genommen, durch den SSH-Tunnel gejagt und am Ende an deinen X-Server übergeben *kotz* von dem du kommst. Anschliessend gehts ganz normal weiter.
Ha! Sehr gute, ausführliche, Noob-gerechte Erklärung. Hab das gerade verifiziert, indem ich mich physikalisch zum Linux-Server begeben, mich als Root eingeloggt und "echo $DISPLAY" eingegeben habe. Ergebnis: "localhost:0.0".
D.h. es laufen also zwei XServer, der lokale mit localhost0.0 und der des SSHd mit localhost:10.0. Sehr schön. Hab's geschnallt. Danke!
Wenn Du mir jetzt noch erklären kannst, warum das ganze nicht funktioniert, dann darfst Du gehen und dir ein Cookie (http://en.wikipedia.org/wiki/Cookie) holen. :D
englandschorsch
11.05.07, 10:59
Hm... hat niemand mehr ne Idee, warum das ganze nicht funzt? :(
werfe doch mal einen Blick in die man page von xauth. Danach solltest Du den Keks etwas besser verstehen. Und wenn Du Dir dann die Zugriffsrechte der Datei ~/.Xauthority ansiehst, wirst Du festestellen, daß ein normaler User die .Xauthority des root users i.d.R. nicht lesen darf und damit auch kein Wissern über den korrekten Keks ableiten kann.
Anders herum funzt es, weil: root darf alles ... na ja, auch nicht immer, aber dieses Thema wird i.d.R. erst deutlich später auftauchen ;-)
Gruß
englandschorsch
14.05.07, 09:23
Danke mkahle. Hast Du vielleicht ein paar Tutorial-Links zum Thema xauth und ~/.Xauthority?
Ich habe bisher nur Tutorials zum Client-Server-Modell von X gefunden. Alles was ich zu xauth und ~/.Xauthority finde ist das leidige Thema mit sudo/gksudo.
Die man page sagt mir leider nicht viel, weil ich nichts über die Thematik um xauth weiß.
Ich hab immer gedacht, dass nach einem "su Schorsch" nicht mehr die ~/.Xauthority von root, sondern die ~/.Xauthority von Schorsch verwendet wird. Warum sollte es da dann ein Problem mit den Zugriffrechten geben??? Kannst Du mir das kurz erklären?
ich versuch's mal ...
Auf Deiner Arbeitsstation läuft ein X11-Server. Ein X11-Server stellt die Resourcen, die er im Zugriff hat, einem X11-Client zur Verfügung. I.d.R. handelt es sich bei den Resourcen um Deinen Bildschirm, Deine Maus, Deine Tastatur, ... und genau hier fängt das Problem an. Wer hindert beispielsweise andere im Netzwerk daran, mit genau dem selben Mechanismus (X11) ebenfalls Deine Tastatur abzufragen, wenn Du einen X11-Server gestartet hast?
Wirklich richtig sichere Methoden sind im traditionellen X11 nicht definiert und auch die Methoden, die versuchen, hier Besserung zu bringen, sind weit davon entfernt, perfekt zu sein.
Ein Hilfsmittel, das hierfür erfunden wurde, ist das MIT-MAGIC-COOKIE. Warum auch immer jemand auf die Idee gekommen ist, das als Keks zu bezeichnen ... keine Ahnung. Stell es Dir vor als eine Parole, die sich der X11 Server (auf Deiner Arbeitsstation) ausgedacht hat, als er gestartet wurde. Wenn jemand etwas von dem X11 Server möchte, muß er vorher die Parole kennen und sagen.
Wenn Dein X11-Server und -Client auf der gleichen Machnine sind, ist das recht einfach. Dies ist beispielsweise der Fall, wenn Du an einem normalen Linux-PC sitzt, lokal einen X11-Server und einen Client laufen hast. Der Client heißt dann beispielsweise KDE, GNOME, Fluxbox oder auch einfach nur xterm ...
Was aber nun, wenn Dein X11-Client und X11-Server auf unterschiedlichen Maschinen laufen? Woher kennt der X11-Client (xterm, z.B.) den Keks für den Server? Es gibt versch. Methoden, diese Information weiterzuleiten, aber um nicht allzuweit von Deiner Frage weg zu kommen, bleiben wir bei Deinem Beispiel.
Das X11-Tunneling, was in Deiner Sitzung offensichtlich eingeschaltet war, nimmt die Weitergabe des Kekses automatisch vor. D.h. Dein ssh-client reicht nach erfolgreicher Anmeldung den Keks weiter und auf der Zielseite wird er per xauth in der Datei .Xauthority gespeichert. Als derjenige User, mit dem Du Dich per ssh am entfernten Server angemeldet hast, kannst Du diesen Keks natürlich lesen und bei Bedarf Dich damit gegenüber dem X11-Server ausweisen. Somit sollten alle X11-Applikationen für diesen Benutzer funktionieren.
Was passiert, wenn Du Deine Identität auf dem entfernten Rechner änderst? Verwendest Du den Benutzer A zur Anmeldung per ssh, kann root jederzeit auch den Keks von A lesen, falls Du vom User A zum User root wechselst (weil root den Inhalt der Datei .Xauthority von User A lesen darf). Andersherum funktioniert es deshalb nicht, weil der User A selbstverständlich nicht in die .Xauthority des Users root auslesen darf, falls Du Dich initial mit dem User root angemeldet hast.
Klarheiten beseitigt? Sorry ... komplexes Thema ...
Gruß,
MKahle
englandschorsch
16.05.07, 08:50
Klarheiten beseitigt? Sorry ... komplexes Thema ...
Solch eine Noob-freundliche, ausführliche Erklärung lob ich mir. :)
Konnte Dir ohne Probleme folgen. Vielen Dank!
phnord und Du haben mir sehr geholfen. Nach und nach verstehe ich mehr vom Linux-Universum. :D
Drei Fragen bleiben mir noch:
1.) Wenn ich mit User A anfange und dann per "su" zu root wechsle, dann sagst Du, dass root trotzdem noch den Keks in der .XAuthority von A lesen kann. Frage: woher weiß der Linux Server denn, dass Programme, die von root gestartet werden, den Keks von A's .XAuthority verwenden müssen, um beim XServer akzeptiert zu werden? Warum wird nicht automatisch root's .XAuthority verwendet?
Gibt es da sowas wie eine zentrale Keks-Registry oder eine Keks-Umgebungsvariable?
2.) Was würde passieren, wenn mehrere Benutzer von unterschiedlichen Maschinen (mit unterschiedlichen XServern) zurselben Zeit als root eingeloggt wären? Ist die .XAuthority ein einzeln verpackter Keks, der einfach überschrieben wird, oder ist das ganze eher eine komplette Keksdose, in die mehr und mehr Kekse gepackt werden können?
edit: OK, hab gerade den Befehl "xauth list" entdeckt. Scheint wohl ne Keksdose zu sein. *hehe* Fragen 1 und 3 sind mir aber noch immer ein Rätsel.
3.) Hab in einem Artikel (siehe weiter unten) gelesen, dass ein XServer auf port 6000+D, wobei D die Displaynumber ist, horcht. Soweit auch nachvollziehbar, wenn ich ein "netstat -tan" abfeuere sehe ich einen Service, der auf 6010 horcht. Dies ist wohl - wie von phnord erläutert - der "SSH-X-Proxyserver" ist, welcher die X-Daten durch den SSH-Tunnel an meinen Windows-XServer weiterleitet. Die Displayvariable, wenn ich mich per SSH einlogge, ist ja auch auf "localhost:10.0" gesetzt.
Was ich jedoch nicht in der Liste sehen kann, ist ein Service, der auf 6000 horcht, obwohl ein lokaler XServer läuft und die Displayvariable, wenn ich mich lokal am Linux Server anmelde, auf "localhost:0.0" verweist. Irgendwelche Ideen dazu???
Hab außerdem einen hübschen Artikel (http://www.governmentsecurity.org/archive/t1336.html) zum Thema X Window Security gefunden. Nur falls sonst noch jemand ähnliche Fragen wie ich haben sollte...
Hi!
Was ich jedoch nicht in der Liste sehen kann, ist ein Service, der auf 6000 horcht, obwohl ein lokaler XServer läuft und die Displayvariable, wenn ich mich lokal am Linux Server anmelde, auf "localhost:0.0" verweist. Irgendwelche Ideen dazu???
Ja, aus Sicherheitsgründen sollte jede Distribution den X-Server mit -nolisten tcp gestartet haben, damit er nicht direkt von außen erreichbar ist, zumal die X11-Kommunikation unverschlüsselt abläuft und somit z.B. jemand den MIT-MAGIC-COOKIE mitlesen könnte.
Bei einem verschlüsselten SSH-Tunnel sieht das anders aus.
Gruß
fuffy
englandschorsch
16.05.07, 13:28
Ja, aus Sicherheitsgründen sollte jede Distribution den X-Server mit -nolisten tcp gestartet haben, damit er nicht direkt von außen erreichbar ist, zumal die X11-Kommunikation unverschlüsselt abläuft und somit z.B. jemand den MIT-MAGIC-COOKIE mitlesen könnte.
Ah, ok danke! Heißt das dann, dass Unix Sockets oder andere IPC-Methoden verwendet werden, um mit dem XServer zu kommunizieren? Oder wie verbinden sich die XClients mit dem XServer?
Fluffy, hast Du auch ne Antwort auf Frage 1 :confused:
Werf doch mal einen Blick in Deine Umgebungsvariablen (Kommand "env"), nachdem Du per "su root" root geworden bist. Besonders interessant ist die Variable XAUTHORITY. Jedes Mal, wenn Du root wirst erhält die Variable einen neuen (kryptischen) Wert, der jedoch auf eine (dann) real existierende Datei im Home-Verzeichnis des Users root verweist. Diese Datei wird beim "su" automatisch angelegt und mit dem aktuell gültigen Keks gefüllt. Wie Du schon festgestellt hast, kannst Du das mit "xauth list" prüfen...
Viel Spaß.
englandschorsch
16.05.07, 21:51
Hm, um das ganze mal zusammenzufassen und abzuschließen:
Hab ich das richtig verstanden, dass zuerst die Umgebungsvariable XAUTHORITY geprüft wird und falls diese nicht vorhanden ist, wird standardmäßig die Datei .Xauthority im home-Verzeichnis des aktuellen Users verwendet?
Kannst Du mir das kurz bestätigen?
Klares und deutliches: JAIN :D
Wenn die Umgebungsvariable XAUTHORITY gesetzt ist (siehe "man xauth"), dann wird diese als Pfad zur Keksdose verwendet, sie ist nicht selbst die Keksdose ... ansonsten gilt die .Xauthority Datei im Heimatverzeichnis als Keksdose.
Cheers.
englandschorsch
16.05.07, 23:36
Wenn die Umgebungsvariable XAUTHORITY gesetzt ist (siehe "man xauth"), dann wird diese als Pfad zur Keksdose verwendet, sie ist nicht selbst die Keksdose ... ansonsten gilt die .Xauthority Datei im Heimatverzeichnis als Keksdose.
Genau so hatte ich es verstanden, d.h. Dein klares JAIN ist für mich ein klares JA! :D
Vielen, vielen Dank nochmal. Zur Belohnung, dass Du so ein toller Erklärbär bist, überreiche ich Dir diesen
http://www.rebeccasnutfree.com/Merchant2/graphics/00000001/prod-cookie-cchipjmbo-lg.jpg
Also, wenn man so netten "Feedback" erhält, dann macht man sich die Mühe doch gerne ... aber den Keks gebe ich einer meiner Töchter, weil ... seitdem ich Anfang letztes Jahr aufgehört habe zu rauchen, kommen die Pfunde von alleine ... :-(
cheers
Powered by vBulletin® Version 4.2.5 Copyright ©2024 Adduco Digital e.K. und vBulletin Solutions, Inc. Alle Rechte vorbehalten.