web-dev-qa-db-ja.com

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）を割り当てた場合、同じプロセスが繰り返されます。早い段階で起動したX11アプリケーションは、開いたままにしておく限り（日数） ）、しかし数時間後、そのシェルから新しいものを開始できなくなります。

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

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

リモートマシン（sshdサーバー）で「LogLevel DEBUG3」を設定し、クライアント接続に私が変更を加えなかった場合、/ 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で使用されているポート番号を除いて、ステータスレポートの内容はすべて同じです。それは、これらの一連のレポートから一晩で判断すると、時間とともに増加し続けます。

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

-マイク

sshmac-osxx11display
10
mklein9

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

ForwardX11Timeout 596h

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

13
mklein9

man ssh_config

ForwardX11Trusted

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

3
Isabella

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

ForwardX11Timeout 596h

...しかし、タイムアウトは今から3〜1/2週間は発生します。」

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

ForwardX11Timeout 0

...

1
AB.