更新

更新

從我的本機電腦ssh到遠端伺服器以及有關 X 顯示的身份驗證。我知道在此過程中MIT-MAGIC-COOKIES使用了 ,並且伺服器和客戶端中的值需要相同才能使身份驗證過程有效。

但是,當我登入遠端伺服器並確認 X 顯示內容運作良好(例如執行xclock以查看xclock應用程式是否在我的本機電腦中彈出)時,當我檢查 cookie 的值時,本機電腦中的值而遠端伺服器中的情況似乎有所不同。這是命令列:

遠端伺服器中的cookie值

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 值

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

正如你所看到的,兩台機器中的cookie值是不同的。那麼X顯示器不應該不工作嗎?

我在這裡缺少什麼?

PS 我聽說其中$XAUTHORITY包含文件的路徑xauthority,我已經在本地計算機中檢查了該路徑:

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

當我查看“資料庫”文件時,內容不可讀,因為內容由奇怪的字元組成。

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

這可能與問題有關嗎?


更新

遠端伺服器中xhost的結果$XAUTHORITY

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

Black@Black-PC ~
$ echo $XAUTHORITY

*事實證明$XAUTHORITY未定義...這是正常的嗎?

xhost在本地機器上的結果

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

答案1

我相信您對 SSH 如何透過在遠端伺服器端建立的隧道執行 X11 連接的代理以及 magic cookies 通常的工作方式感到困惑。從 SSH 手冊頁:

摘抄
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).

因此,看起來在遠端伺服器端向您顯示的魔法 Cookie 實際上並不是本地伺服器(您端)上真正的魔法 Cookie。請記住,當您透過 SSH 連接到遠端伺服器時,DISPLAY 的設定如下:

$ echo $DISPLAY
localhost:11.0

魔法餅乾是這樣連接的$DISPLAY

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

告訴我們的是/unix:11。這是 SSH 連接本地端的神奇 cookie,而不是本地伺服器的 X11,通常是:0.

.X權威

確實,該文件包含神奇的 cookie,但它是一個二進位文件,您通常會透過命令與其進行互動xauth。有關這方面的更多信息,請參閱xauth的手冊頁。

手動進行

如果執行以下操作,您通常會看到此訊息出現:

$ 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).

這是因為第二位使用者對.Xauthority您最初登入時透過 SSH 傳遞的 magic cookie 一無所知。您可以xauth add在作為 user1 時產生所需的內容並作為 user2 使用它,如下所示:

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

請注意,上面您正在顯示 # :10.0。現在產生xauth add該顯示所需的#:

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

現在成為 user2 並添加它:

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

我們得到了預期的時鐘顯示。

筆記:一旦您掌握了上述內容,您也可以在單一命令列中執行操作。

使用蘇
$ xauth extract - ${DISPLAY#localhost} | \
    su - user2 -c "xauth merge -; xclock"
使用須藤
$ xauth extract - ${DISPLAY#localhost} | \
    sudo su - user2 -c "xauth merge -; xclock"

參考

相關內容