私のメインホスト[ A
](画面あり)からssh
中継システム[ B
](画面あり-X
)に移動し、そこからターゲットシステム[ C
](もう一度画面あり-X
)にログインすると、X転送が機能するようです。しばらくは大丈夫です。 vimでターゲットコンピュータ[]で作業した後、突然X転送機能が利用できなくなり、C
ログアウトした後にSSHセッションを再開する必要があり、再び正常に動作しました。これは通常の日中に発生します。つまり、ホストが停止したり電源が切れたりすることはありません。C
B
X
すべてが期待どおりに機能すると、C
次のようになります。
$ echo $DISPLAY
localhost:10.0
同様のアプリケーションが画面にうまくxeyes
配信され、レンダリングされます。A
すると、突然次のように報告されます。
$ xeyes
Error: Can't open display: localhost:10.0
$ echo $DISPLAY
localhost:10.0
怪しい兆候も/var/log/syslog
なく、SSHセッションはアクティブなままで、再び正常に実行されますjournalctl
。C
問題が何であるかを知っている人はいますか?
ホストの詳細:
A
物理的なマンジャロボックスです(LANに接続されています)B
物理Ubuntu 21.04システム(LANに接続)C
Ubuntu 18.04を実行する仮想マシンB
(NAT経由で接続)。
答え1
ForwardX11Trusted
Debian's manのエントリにはこれについての説明があります。ssh_config
、UbuntuはDebianと同じように動作しますが、Manjaroとは異なります。
ForwardX11Trusted
このオプションが次に設定されている場合はい、(Debian 固有のデフォルト)、リモートX11クライアントは元のX11ディスプレイへのフルアクセス権を持ちます。
このオプションが次に設定されている場合いいえ(アップストリームのデフォルト)、リモートX11クライアントは信頼できないクライアントとして扱われ、信頼できるX11クライアントに属するデータは盗まれたり改ざんされたりするのを防ぎます。また、 セッションで使用される xauth(1) トークンは、20 分後に有効期限が切れるように設定されます。この時間が経過すると、リモートクライアントのアクセスは拒否されます。
これは、主にDebianベースのシステム(Ubuntuなど)を使用している場合に、以前にこの問題が発生していなかった理由を説明できます。
このオプションを有効にするショートカットはです-Y
。だからあなたは単に最初のものに-X
置き換えることができます-Y
SSH問題を「修正」するコマンドです。
しかし、X11ディスプレイを2回配信するのは最善のアプローチではありません。特に、-Y
これがマルチユーザーバスチャンシステムの場合、X11ディスプレイは中間システムBの他のユーザーに公開されます。ターゲットマシンCのポート22を転送し、他のすべてをそれにトンネルすることをお勧めします。幸いなことに、この目的のために特別に設計されたいくつかのオプションがあります。ProxyJump
オプションとショートカット-J
。最後に、マシンAで実行できます。
ssh -Y -J userb@computerB userc@machineC