LinuxからMacにSSH転送されたX11ディスプレイがしばらくして失われる

Mac（10.7.2）からLinux（Ubuntu 8.04）にログインするときに、X11接続をssh転送することで、新たな厄介な問題が発生します。ssh -Xを使用してリモートマシンにログインし、そのシェルからX11ベースのアプリケーションを起動しても問題はありません。

最近起こったのは、転送されたディスプレイがブロックされているため（おそらく）、同じシェルからのX11アプリケーションの追加の呼び出しが、しばらく（数時間程度）後に開始できないことです。たとえば、xtermを起動しようとすると、次のような、不適切なDISPLAY設定に関する通常のメッセージが表示されます。

xterm Xtエラー：ディスプレイを開けません：localhost：10.0

しかし、ログインしてすぐに開始したX11アプリケーションは、以前に開始したものとまったく同じディスプレイ（localhost：10.0）を使用して、問題なく実行されています。

sshd_configで詳細ログをオンにしましたが、xtermの起動試行の失敗に応じて、/ var / log / auth.logファイルにこれが表示されます。

sshd [22104]：チャネル8：オープン失敗：管理上禁止：オープン失敗

サーバーに再度ssh -Xを実行して、新しいシェルを開始し、新しいディスプレイ（localhost：11.0）を割り当てた場合、同じプロセスが繰り返されます。 ）、しかし数時間後、そのシェルから新しいものを開始できなくなります。

詳細：Ubuntu 8.04で実行されているOpenSSH sshdサーバー、ディスプレイは、デフォルトのApple XサーバーでLion（10.7.2）を実行しているMacに転送されます。システムは、1つのスイッチを介してイーサネットLANに接続されています。どちらのマシンもファイアウォールを実行していません。最近（数日前）まで、このセットアップは完全に機能したので、次にどこを見ればいいのか迷っています。私は決してX11やSSHの専門家ではありませんが、UNIX / Linuxの経験は豊富です。sshd_configのTCPKeepAliveをnoに設定したり、「host + localhost」を設定したり（私がグーグルしていることがわかります）など、これをデバッグするためにいくつかのオプションを変更しようとしましたが、クライアントまたはサーバーの構成に明らかな変更はありません。

Linux 11.10ラップトップから同じネットワークとスイッチを介して同じリモートホストにログインする場合、この問題は発生しません。Macからの同じ実験が失敗しても、同じsshログインシェルからxtermを数時間後に呼び出すことができます（確認のために今朝テストしました）、Mac固有の問題のようです。

「LogLevel DEBUG3」がリモートマシン（sshdサーバー）で設定されており、クライアント接続に変更が加えられていない場合、/ var / log / auth.logは、使用されているポート番号である接続ステータスレポートにわずかな変更を一晩表示します。 Linuxマシンからの1つの成功したsshセッション（私は思う）によって、以下の接続＃7：

sshd [20173]：debug3：チャネル7：ステータス：次の接続が開いています：\ r \ n＃0 server-session（t4 r0 i0 / 0 o0 / 0 fd 14/13 cfd -1）\ r \ n＃3 127.0.0.1ポート57564からのX11接続（t4 r1 i0 / 0 o0 / 0 fd 16/16 cfd -1）\ r \ n＃4 127.0.0.1ポート57565からのX11接続（t4 r2 i0 / 0 o0 / 0 fd 17 / 17 cfd -1）\ r \ n＃127.0.0.1ポートからのX11接続57566（t4 r3 i0 / 0 o0 / 0 fd 18/18 cfd -1）\ r \ n＃6 127.0.0.1ポートからのX11接続57567（t4 r4 i0 / 0 o0 / 0 fd 19/19 cfd -1）\ r \ n 127.0.0.1ポート59007からの＃7 X11接続

このレポートでは、接続＃7で使用されているポート番号を除いて、ステータスレポートのすべてが同じです。これらのレポートのシーケンスから判断すると、時間の経過とともに増加し続けています。

助けてくれてありがとう、

-マイク

Macクライアントの/ etc / ssh_configを次の行を含むように変更した後、sshセッションが開始しました。

ForwardX11Timeout 596h

すべて正常に動作しており、一日中働いています。今では、彼ら全員が新しいxtermの開始を拒否しているでしょう。だから私はこれが答えであり、幸いにも簡単な解決策であると信じていますが、タイムアウトは今からまだ3週間半かかります。

man ssh_config

ForwardX11Trusted

このオプションが「はい」に設定されている場合、リモートX11クライアントは元のX11ディスプレイに完全にアクセスできます。このオプションを「いいえ」に設定すると、リモートX11クライアントは信頼されていないと見なされ、信頼されたX11クライアントに属するデータを盗んだり改ざんしたりできなくなります。さらに、セッションに使用されるxauth（1）トークンは、20分後に期限切れになるように設定されます。この時間を過ぎると、リモートクライアントはアクセスを拒否されます。デフォルトは "no"です。信頼されていないクライアントに課される制限の詳細については、X11 SECURITY拡張仕様を参照してください。

「12年1月7日0:11 mklein9 28129で回答済み」に追加するには「Macクライアントの/ etc / ssh_configを次の行に含めるように変更した後、sshセッションが開始します。

ForwardX11Timeout 596h

...しかし、タイムアウトは今から3週間半後に発生します。」

どうやらあなたは0を使用することができ、これは（接続がオンである限り）タイムアウトを無限に設定します。

ForwardX11Timeout 0

...