☰

ネストされたSSHで「警告：信頼できないX11転送設定が失敗しました。」

tag-icon • tag-icon debian login openssh
ネストされた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=noDebian では、オプション-Xと-Yオプションが同じであるため、次のようになります。信頼できるどちらを使用しても、デフォルトでX11転送が発生します。

おすすめ記事