web-dev-qa-db-ja.com

ネストされた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
Ingo

X11サーバーへの唯一の接続がntrustedの場合、それ以上転送することはできません。

信頼できないX11転送は、ローカルディスプレイに接続するsshクライアントによって機能し、xauth generate $DISPLAY . untrustedコマンドを使用してntrusted key/cookieを生成します。

ただし、そのためには、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

DebianではForwardX11Trusted=no-Xオプションは同等であるため、明示的な-Yに注意してください。デフォルトではtrusted X11転送が行われます。あなたが使っているもの。

2
mosvy