ネストされた ssh で「警告: 信頼できない X11 転送の設定に失敗しました」

ネストされた ssh で「警告: 信頼できない X11 転送の設定に失敗しました」

悪質なワールド ワイド ウェブから SSH で接続できるゲートウェイがあります。問題なく、次の結果が得られます。

remote ~$ ssh -X ingo@gateway
Debian GNU/Linux 10 (buster)
0:ingo@gateway ~$

今では、ファイルサーバーなどの他のホストを管理しています。

0:ingo@gateway ~$ ssh -X ingo@fileserver
Warning: untrusted X11 forwarding setup failed: xauth key data not generated
Debian GNU/Linux 10 (buster)
0:ingo@fileserver~$

その警告は受け取りました。

しかし、ローカル ネットワーク上の管理ホストからファイル サーバーに直接 ssh すると、警告が表示されずに動作します。他のログインでもこれを確認しました。ssh から ssh する場合にのみ警告が表示されます。

なぜ私は
警告: 信頼できない X11 転送の設定に失敗しました: xauth キー データが生成されませんでした
ネストされた SSH ログインのみですか?

この警告を回避し、より安全な信頼できない X11 転送を正常に使用するにはどうすればよいですか?

-Yいいえ、信頼できる X11 転送に、使用されているオプションの代わりに、ssh で安全性の低いオプションを使用したくありません-X

答え1

X11サーバーへの唯一の接続が信頼できないそれ以上転送することはできません。

信頼できないX11転送は、SSHクライアントがローカルディスプレイに接続し、xauth generate $DISPLAY . untrustedコマンドを使用して信頼できないキー/クッキー。

ただし、そのためには、xauthコマンドはSECURITY拡張機能をディスプレイ上に表示する必要があります。これは、ほとんどの拡張機能と同様に、xauth信頼できない Cookie を使用してクライアントが認証された場合は非表示になったり無効になったりします。

以下の方法で簡単に確認できます:

$ touch /tmp/junk1 /tmp/junk2
$ chmod 600 /tmp/junk*
$ xauth -f /tmp/junk1 generate :0 . untrusted
$ XAUTHORITY=/tmp/junk1 oclock
   # get a square oclock because the Shape extension is disabled
$ XAUTHORITY=/tmp/junk1 xdpyinfo | grep -A2 extensions
number of extensions:    2
    BIG-REQUESTS
    XC-MISC
   # vs 28 or so on a trusted display
$ XAUTHORITY=/tmp/junk1 xauth -f /tmp/junk2 generate :0 . untrusted
xauth: (argv):1:  couldn't query Security extension on display ":0"

後者の手順では、ssh で警告が表示されます。

したがって、少なくとも最初の X11 転送は信頼される必要があります。そうでない場合は機能しません。


あるいは、中間ホストを「ジャンプ」して、単一の X11 転送を実行する必要があります。

ssh -X -o ForwardX11Trusted=no -J ingo@gateway ingo@fileserver

明示的な に注意してくださいForwardX11Trusted=no。Debianでは-X-Yオプションは同等であり、信頼できるどちらを使用していても、デフォルトで X11 転送になります。

関連情報