
2026/08/03 5:26
FamilyWild を用いたホスト間の X11 サーバー共有
RSS: https://news.ycombinator.com/rss
要約▶
Japanese Translation:
2026 年 8 月 2 日、隔離環境(コンテナや chroots など)内または非転送された SSH 接続上でグラフィカルな X11 アプリケーションを動作させる際に生じる「Authorization required, but no authorization protocol specified」というエラーを解決するための方法が詳述されました。根本原因は、
.Xauthority クッキーが family と hostname の双方で鍵付けされており、クライアントが自分のマシン名と一致しない hostname を持つクッキーを拒絶する点にあります。
解決策は、クッキーの family フィールドの最初の 2 バイトを
0100(FamilyLocal)から 0xffff(FamilyWild)に書き換えることです。これには以下のコマンドを使用します:xauth nlist :0 | sed 's/^..../ffff/' | xauth -f /tmp/portable.Xauthority nmerge -(:0 を $DISPLAY に置き換えてください)。family を FamilyWild に変更することで、クッキーは任意の hostname に対して有効となり、hostname が不一致のクライアントからの接続も可能になりつつ、ホストベースのアクセス制御を完全に無効にすることなく済みます。
これを使用するには、生成された
/tmp/portable.Xauthority ファイルを bind-mount または SCP でクライアント環境に移動し、$XAUTHORITY 変数を指すように設定します。ただし、厳格なセキュリティ上の注意が必要です:FamilyWild クッキーはローカルなものよりも特定の情報が少ないため、ソケットアクセスがありファイルを閲覧できるあらゆるユーザーが表示器に接続できるようになります。そのため、ファイルのパーミッションは必ず 0600 を維持し共有マシンにはコピーを残すべきではありません。このアプローチは、ホストベースのセキュリティを完全に無効にする xhost + の使用や、全クッキーをクリアしつつ無効なエントリを残そうとする危険な方法よりも優先されます。著者はこのトリックを、特別に非特権 LXC コンテナへの X11 転送のために適用しています。本文
解決策:X サーバーによる認証エラー「Authorization required」を FamilyWild クッキーで回避する
コンテナ内、chroot ディレクトリ、または
bind mount された .Xauthority を通じた SSH 接続から X11 アプリケーションを実行しようとする際によく直面する問題です。ファイルは存在し、読み取り専用としてマウントされていますが、「Authorization required, but no authorization protocol specified(認証が必要ですが、認証プロトコルが指定されていません)」 というエラーメッセージが表示されます。X サーバーが接続を拒否してしまうのは、クッキー自体が有効な場合でも、ホスト名の不一致によるクライアント側の挙動が原因です。この問題を解決するには、sed を使った単純な書き換えだけで済みます。
なぜクッキー(セッショントークン)が拒絶されるのか
.Xauthority ファイルは、ファミリー(family)とホスト名によって識別される複数のエントリで構成されています。クライアントは接続時に単に最初に見つかったクッキーを使うのではなく、実行されているマシンのホスト名と一致するエントリを探します。
- 致命的な弱点: クッキーが作成された場所(ホスト名)と異なる場所でクライアントを実行すると、ホスト名の不一致により利用できません。
- 例:コンテナ内のホスト名と、ホスト機上のホスト名が異なります。
- 例:転送されていないソケット経由の場合、クライアントは全く異なる名前を解決します。
- 結果: クッキーが存在し有効であっても、ホスト名が一致しないためクライアントはクッキーを提供しません。X サーバーはエラーメッセージにフォールバックします。
この問題を特定するために
xauth list を確認してみましょう:
$ xauth list myhost/unix:0 MIT-MAGIC-COOKIE-1 a1b2c3d4e5f6...
- 問題の所在: 先頭の
です。myhost/unix:0 - 理由: これはクッキーを
に固定(ピン留め)させてしまっているため、ホスト名が異なる環境では認識されません。myhost
FamilyWild が救援にやってくる
X サーバーには、ファミリーとして数値
0xffff を持つワイルドカードである**「FamilyWild」**が存在します。
- 特性: このファミリーに属するクッキーは、どのようなホスト名であってもマッチします。
- 解決策: クライアント側のホスト名に合わせてクッキーを調整する代わりに、クッキー自体を書き換えてすべてのホストに対応させます。
以下コマンドで対応可能です(
$DISPLAY を実際の値に置き換えてください):
: > /tmp/portable.Xauthority && xauth nlist :0 | \ sed 's/^..../ffff/' | xauth -f /tmp/portable.Xauthority nmerge -
※
は :0
$DISPLAY 環境変数の値に置き換えてください。
変更はたった一つのフィールドだけ
この編集が驚くほど最小限であることを確認できます。.Xauthority エントリは、以下の構造を持つパッキングされたバイナリレコードで構成されています。
- 2 バイトのファミリー
- 長さプレフィックス付きアドレス(ホスト名)
- ディスプレイ番号
- 認証名
- クッキー本体
元のファイルの内容をダンプすると、ファミリー情報は最初の 2 バイト(
0100)に存在します。これは FamilyLocal を意味します:
00000000: 0100 0006 6d79 686f 7374 0001 3000 124d ....myhost..0..M ...
一方、作成した FamilyWild バージョンの内容をダンプすると:
00000000: ffff 0006 6d79 686f 7374 0001 3000 124d ....myhost..0..M ...
- 比較結果: アドレス(ホスト名
)やクッキー内容は全く同じですが、最初の 2 バイトだけがmyhost
に書き換えられています。ffff - 仕組み: X サーバーはファミリー番号
は条件なくマッチするものとして認識するため、アドレスフィールドの不一致を気にしなくなります。0xffff
使用方法
をクライアントが実行する環境にどこにでも/tmp/portable.Xauthority
(またはbind mount
で転送)します。scp
環境変数をこのファイルへ指し示します。XAUTHORITY
ホスト名の不一致があっても接続は承認されます。
xhost + について
「ただ動作させる」ための解決策として
xhost + が提案される場合があります。確かに機能しますが、セキュリティリスクが極めて高いです。
- 機能: ホストベースのアクセス制御を完全に無効にします。
- リスク: クッキーを使わずに、あらゆるホストからディスプレイへの接続が可能になります。
- 単一ユーザーのマシンでは無害に見えますが、X サーバーはクライアント間の隔離機能を持っていません。
- キー入力を盗み見たり、任意のウィンドウの内容を取得したり、合成入力を行えるようになります。
- TCP リスニング中ならネットワーク全体に委ねることになり、より限定的な
でもマシンのすべての UID を信頼してしまいます。xhost +local:
推奨アプローチ
- FamilyWild クッキー: ドアの鍵はかけっぱなし(クライアントは秘密情報を提示)にし、単に邪魔だったホスト名の制約だけ除去します。
- 注意点:
は選ばず、この方法(FamilyWild)を採用してください。xhost +- 必ずクッキーファイルのアクセス権限を
に維持してください。0600
- 必ずクッキーファイルのアクセス権限を
注意点
FamilyWild クッキーは、意図的に元のクッキーよりも具体的な情報量を減らして設計されています。そのため、あなたの X ソケットに到達し、かつこのファイルを読むことができる誰しもが、あなたのディスプレイと通信できるようになります。
- このファイルを共有マシンなどにコピーを残さないでください。
- 実際には必要とする環境のみへ渡すよう心がけましょう。
- これはより大きな設定のうちの小さな一部分です。詳細は「LXC を用いた X11 アプリケーションのセキュリティ強化」の記事を参照してください。
Hacker News でもこの話題について議論されています。