☰

MIT-MAGIC-COOKIE-1 keyxhostが無効です。ディスプレイ「：0」を開けません。

tag-icon • tag-icon x11 display x-server
MIT-MAGIC-COOKIE-1 keyxhostが無効です。ディスプレイ「：0」を開けません。

新しいコンソールを開くたびにエラーメッセージが表示されます。

ここに画像の説明を入力してください。

ここに画像の説明を入力してください。

xxd   ~/.Xauthority
00000000: 0100 0006 6465 6269 616e 0002 3130 0012  ....debian..10..
00000010: 4d49 542d 4d41 4749 432d 434f 4f4b 4945  MIT-MAGIC-COOKIE
00000020: 2d31 0010 1fba cba8 1f6a f8b6 e00d 8c1a  -1.......j......
00000030: c7cb 7d86 0100 0006 6465 6269 616e 0001  ..}.....debian..
00000040: 3000 124d 4954 2d4d 4147 4943 2d43 4f4f  0..MIT-MAGIC-COO
00000050: 4b49 452d 3100 1050 f7f6 b85b 77e1 49e4  KIE-1..P...[w.I.
00000060: a0c6 470d 7b11 a9                        ..G.{..

どうすれば修正できますか？

ベストアンサー1

Invalid MIT-MAGIC-COOKIE-1 keyxhost: unable to open display ":0"

実際、同じ行に2つのエラーメッセージが表示されます。

Invalid MIT-MAGIC-COOKIE-1 key
xhost: unable to open display ":0"

X11 GUIを使用してログインすると、セッションは自動的にDISPLAY環境変数とセッション固有のアクセスキー（~/.Xauthority環境変数で指定されたファイルに保存されますXAUTHORITY）を取得します。

コンソールログインはGUIログインとは別のものであるため、コンソールログインセッションは自動的にログインを選択しません。xhostまず、GUIセッションへのアクセス権がないと、GUIセッションへのアクセス制御を構成できません。

GUI セッションが終了し、X11 サーバーが再起動すると、X11 サーバー側は、古いキーを自動的に無効にする新しいセッションキーを生成します。ただし、以前のセッションキーはユーザー.Xauthorityファイルに残ることがあります。次にGUIにログインすると、自動的に交換されます。したがって、ファイルにMIT-MAGIC-COOKIE-1キーがあるとしても、必ずしもMIT-MAGIC-COOKIE-1キーが必要で.Xauthorityあるという意味ではありません。現在のキー。

を実行している場合pgrep -a Xorgと同様のXサーバープロセスのコマンドライン引数が表示されることがありますXorg -nolisten tcp -auth <some path> <other options...>。この-authオプションで指定されたパスは、現在のサーバーサイドセッションキーファイルです。 rootアクセス権がある場合は、egを使用してそれらを表示して自分のファイルの内容と比較できます。xauth -f <some path> list出力は次の行または複数行になります。.Xauthorityxauth list

debian/unix:0  MIT-MAGIC-COOKIE-1  <actual key in hexadecimal>

サーバー側のキーファイルは常に1行でなければなりませんが、X11転送でSSH接続を使用している場合は、独自のファイルにegまたはより高い表示番号で始まる追加の行がある可能性があります.Xauthority。debian/unix:10

ファイルxauth list出力.Xauthorityに表示される単一の行と正確に一致する行が含まれている場合は、xauth -f <some path> listXサーバーにアクセスできます。一致する行がない場合、Xサーバーはエラーとともに要求を拒否しますInvalid MIT-MAGIC-COOKIE-1 key。

あなたまたは同様のログインスクリプトにコマンドがある可能性があると思いますxhost。実行する前に、変数が存在するかどうかをテストするテストにラップする必要があります。たとえば、次のようになります。~/.profile~/.bashrc$DISPLAYxhost

xhost +local:

例えば

if [ "$DISPLAY" != "" ]
then
    xhost +local:
fi

~/.Xauthorityしかし、ファイルのデフォルトの場所を使用していてこれを行う場合ただGUI管理ツールを使用するときにsudorootアクセスを許可するためのより安全な方法があるかもしれません。xhost +local:に以下を追加できます~/.bashrc。

if [ "$SUDO_USER" != "" ] && [ "$DISPLAY" != "" ]
then
    export XAUTHORITY=$(grep "^${SUDO_USER}:" /etc/passwd | cut -d : -f 6)/.Xauthority
fi

これは、GUIセッションのセキュリティを軽減せずにルートがすべてを読むことができるという事実を利用します（したがって、ホームディレクトリがオプションとしてエクスポートされたNFSマウントの場合は機能しませんroot_squash）。これにより、変数は個人ユーザーアカウントのホームディレクトリにあるファイルを直接指すように設定されsudoます。XAUTHORITY.Xauthority

（また、このトリックはを使用している場合は機能しませんsudo su -。代わりに使用し、同様のsudo -iスニペットをまたはに追加します。しかし、これらのファイルを編集するときは注意してください。あります）/root/.bashrc/root/.profile

おすすめ記事