ローカル マシンからsshリモート サーバーへ、X ディスプレイに関する認証とともにアクセスします。このプロセスでは、MIT-MAGIC-COOKIESが使用され、認証プロセスを有効にするには、サーバーとクライアントの両方の値が同一である必要があることはわかっています。
しかし、リモート サーバーにログインし、X ディスプレイが正常に動作していることを確認した後 (たとえば、アプリケーションがローカル マシンにポップアップ表示されるxclockかどうかを確認するために実行するxclockなど)、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
ローカルマシンのクッキー値
chulhyun@chulhyun-Inspiron-3420:~$ xauth list
chulhyun-Inspiron-3420/unix:0 MIT-MAGIC-COOKIE-1 5ddd2ce92004eab53ceee8a64b7b88c0
ご覧のとおり、2 台のマシンの Cookie 値は異なります。X ディスプレイは機能しないのではないでしょうか?
ここで何が欠けているのでしょうか?
$XAUTHORITYPS: ファイルへのパスが含まれていると聞きました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 接続のプロキシを実行する方法と、マジック クッキーの一般的な動作について混乱していると思います。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).
したがって、リモート サーバー側で表示されるマジック クッキーは、実際にはローカル サーバー (ユーザー側) の真のマジック クッキーではないようです。リモート サーバーに SSH で接続すると、DISPLAY が次のように設定されることに注意してください。
$ echo $DISPLAY
localhost:11.0
そして、魔法のクッキーは次のように接続されます$DISPLAY:
$ xauth list
remotey.dom.com/unix:11 MIT-MAGIC-COOKIE-1 00f505f4c5731714d30f24a956d4cb8f
ヒントは です/unix:11。これは SSH 接続のローカル側のマジック クッキーであり、通常は であるローカル サーバーの X11 のマジック クッキーではありません:0。
.X権限
このファイルには確かに魔法のクッキーが含まれていますが、これはバイナリ ファイルであり、通常は コマンドを介して操作します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).
これは、2 番目のユーザーは、.Xauthority最初にログインしたときに SSH によって渡されたマジック クッキーについて何も知らないためです。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
そして、予想通りのクロッキングが表示されます。
注記：上記の内容が理解できれば、単一のコマンド ラインで操作を行うこともできます。
suを使用する$ xauth extract - ${DISPLAY#localhost} | \
su - user2 -c "xauth merge -; xclock"
$ xauth extract - ${DISPLAY#localhost} | \
sudo su - user2 -c "xauth merge -; xclock"