☰

aktualisieren

tag-icon • tag-icon x11 ssh-tunneling xforwarding xauth
aktualisieren

Von meinem lokalen Computer aus melde ich mich sshbei einem Remote-Server an, wobei ich mich bezüglich der X-Anzeige authentifiziere. Ich weiß, dass in diesem Prozess MIT-MAGIC-COOKIESverwendet werden und die Werte auf Server und Client identisch sein müssen, damit der Authentifizierungsprozess gültig ist.

Wenn ich mich jedoch bei einem Remote-Server anmelde und bestätigt habe, dass die X-Anzeige ordnungsgemäß funktioniert (z. B. indem ich ausführe, xclockum zu sehen, ob die xclockAnwendung auf meinem lokalen Computer angezeigt wird), und ich den Wert der Cookies überprüfe, scheint der Wert auf dem lokalen Computer und der auf dem Remote-Server unterschiedlich zu sein. Hier sind die Befehlszeilen:

Cookie-Wert im Remote-Server

chulhyun@chulhyun-Inspiron-3420:~$ ssh -X Black@$labcom
Last login: Wed Jun 25 10:02:25 2014 from 

Black@Black-PC ~
$ xclock    ### xclock appears in local machine.

Black@Black-PC ~
$ xauth list
Black-PC/unix:10  MIT-MAGIC-COOKIE-1  708f623489b1ea129a77e98287d130ca

Cookie-Wert im lokalen Computer

chulhyun@chulhyun-Inspiron-3420:~$ xauth list
chulhyun-Inspiron-3420/unix:0  MIT-MAGIC-COOKIE-1  5ddd2ce92004eab53ceee8a64b7b88c0

Wie Sie sehen, ist der Cookie-Wert auf beiden Maschinen unterschiedlich. Sollte die X-Anzeige dann nicht funktionieren?

Was übersehe ich hier?

PS: Ich habe gehört, dass dies $XAUTHORITYden Pfad zur xauthorityDatei enthält, und ich habe diesen Pfad auf dem lokalen Computer überprüft:

chulhyun@chulhyun-Inspiron-3420:~$ echo $XAUTHORITY
/var/run/gdm/auth-for-chulhyun-iZfH2u/database

Wenn ich einen Blick in die Datei „Datenbank“ werfe, ist der Inhalt nicht lesbar, da er aus seltsamen Zeichen besteht.

^A^@^@^Vchulhyun-Inspiron-3420^@^A0^@^RMIT-MAGIC-COOKIE-1^@^P]?,? ^D??<???      K{??

könnte das mit der Frage zusammenhängen?

aktualisieren

Ergebnis von xhostund $XAUTHORITYim Remote-Server

Black@Black-PC ~
$ xhost
access control enabled, only authorized clients can connect
SI:localuser:chulhyun

Black@Black-PC ~
$ echo $XAUTHORITY

*ist wie sich herausstellt $XAUTHORITYnicht definiert... ist das normal?

Ergebnis von xhostauf dem lokalen Computer

chulhyun@chulhyun-Inspiron-3420:~$ xhost
access control enabled, only authorized clients can connect
SI:localuser:chulhyun

Antwort1

Ich glaube, Sie sind verwirrt darüber, wie SSH das Proxying der X11-Verbindung über den Tunnel durchführt, der auf der Remote-Serverseite hergestellt wird, und wie Magic Cookies normalerweise funktionieren. Aus der SSH-Manpage:

Auszug 
The DISPLAY value set by ssh will point to the server machine, but with a 
display number greater than zero.  This is normal, and happens
because ssh creates a “proxy” X server on the server machine for forwarding 
the connections over the encrypted channel.

ssh will also automatically set up Xauthority data on the server machine.  
For this purpose, it will generate a random authorization cookie,
store it in Xauthority on the server, and verify that any forwarded 
connections carry this cookie and replace it by the real cookie when the
connection is opened.  The real authentication cookie is never sent to the 
server machine (and no cookies are sent in the plain).

Es scheint also, dass die Magic Cookies, die Ihnen auf der Seite des Remote-Servers angezeigt werden, nicht die echten Magic Cookies auf dem lokalen Server (Ihrem Ende) sind. Denken Sie daran, dass DISPLAY wie folgt eingestellt wird, wenn Sie sich per SSH mit einem Remote-Server verbinden:

$ echo $DISPLAY
localhost:11.0

Und die magischen Kekse sind folgendermaßen verbunden $DISPLAY:

$ xauth list
remotey.dom.com/unix:11  MIT-MAGIC-COOKIE-1  00f505f4c5731714d30f24a956d4cb8f

Der Hinweis ist, dass /unix:11. Das ist das magische Cookie für die lokale Seite der SSH-Verbindung, nicht für das X11 Ihres lokalen Servers, das normalerweise wäre :0.

.Xauthority

Es stimmt, dass diese Datei diese magischen Cookies enthält, aber es ist eine Binärdatei und Sie interagieren normalerweise über den xauthBefehl damit. xauthWeitere Informationen hierzu finden Sie auf der Manpage von .

Manuell durchführen

Diese Meldung wird häufig angezeigt, wenn Sie Folgendes tun:

$ ssh -X user1@remotey
$ su - user2
$ xclock

X11 connection rejected because of wrong authentication.
X connection to localhost:10.0 broken (explicit kill or server shutdown).

Dies liegt daran, dass der zweite Benutzer .Xauthoritynichts von dem magischen Cookie weiß, das bei Ihrer ersten Anmeldung per SSH übergeben wurde. Sie können das xauth adderforderliche Cookie generieren, während Sie Benutzer1 sind, und es als Benutzer2 wie folgt verwenden:

$ ssh -X user1@remotey
$ echo $DISPLAY
localhost:10.0

Beachten Sie, dass Sie sich oben auf der Anzeige # befinden :10.0. Generieren Sie nun die xauth addfür diese Anzeige # erforderliche Nummer:

$ echo xauth add $(xauth list ${DISPLAY#localhost})
xauth add remotey.dom.com/unix:10 MIT-MAGIC-COOKIE-1 111ef940f6d75b4a9eb64ea3579ef67e

Melden Sie sich nun bei Benutzer2 an und fügen Sie ihn hinzu:

$ su - user2
$ xauth add remotey.dom.com/unix:10 MIT-MAGIC-COOKIE-1 111ef940f6d75b4a9eb64ea3579ef67e
$ xclock

Und die Zeiterfassung wird wie erwartet angezeigt.

NOTIZ:Sie können die Dinge auch in einer einzigen Befehlszeile erledigen, wenn Sie erst einmal verstanden haben, was oben beschrieben ist.

mit su 
$ xauth extract - ${DISPLAY#localhost} | \
    su - user2 -c "xauth merge -; xclock"
Verwenden Sie sudo 
$ xauth extract - ${DISPLAY#localhost} | \
    sudo su - user2 -c "xauth merge -; xclock"

Verweise

verwandte Informationen