リバースSSHトンネルを確立し、中間サーバーを介して作業しています。私はこことリモートコンピュータでKubuntu 12.04を実行しています。
リモートデスクトップセッションを開きたいです。これまでは、Team Viewerを使用してリモートデスクトップにログインしていました。 Team Viewerがなくても同様の結果が得られることを願っています。私はSSHを介してXがこれを達成することを知っています。 vncが必要な場合はそれも大丈夫です。
これが私の現在の問題です。トンネルを介してリモートシステムに接続すると、次のエラーが発生します。
$ startkde &
$ $DISPLAY is not set or cannot connect to the X server.
-Y SSHオプションを使用し（パスワードの代わりに）キーを使用して接続します。 SSHに関連するすべてが正常に動作しているようです。私が見る唯一の問題はXです。別の例は次のとおりです。
$ xeyes &
$ Error: Can't open display:
そして
$ echo $DISPLAY
$
(何も返さない)
これらの答えは関連性があるようですが、私の状況に対する解決策を定式化するのに十分なほど理解することはできません。
ベストアンサー1
中間サーバーを使用して両方のシステムを相互接続する場合、少なくとも1つの回線が非常に遅くなる可能性があります。この場合、VNCは帯域幅/パフォーマンス要件/品質比をよりよく調整できるため、おそらくより良いパフォーマンスを提供します（これは、堅牢な100Mbit +ネットワークを使用しない限り、ほとんどの設定で実際に機能します）。
私は個人的に好きですx11vnc、実行中のXサーバーに接続し、VNCプロトコルを介して入力/出力を渡します（これはXサーバーの実行中に実行できるため、ディスプレイマネージャと対話することもできます）。問題のXサーバーは通常のサーバー（実際のモニターに出力）またはフレームバッファーベースのサーバーですXvfb。その後、VNCクライアントを使用してエクスポートしたXサーバーに接続できます。もちろん合格したいかもしれませんしssh、stunnel。マニュアルページはx11vnc非常に徹底しており、最初は一般的に使用されるコマンドラインの例も含まれています。
これにより、実行中のセッションにリモートで接続して、誰かがリモートで問題を解決するのに役立ちます。重要な利点は、Xプロトコル自体ではなく入力と出力のみを渡すため、ネットワーク切断はセッションのみを中断し、すべてのプログラムは実行を続けることです。SSH経由のXの場合はそうではありません。。
何らかの理由でSSH経由でX11をトンネリングする場合は、DISPLAY環境変数が正しく設定されていることを確認する必要がありますssh。そうしないと、アプリケーションがどのサーバーに接続するのかわからないため、続行できません。X11Forwardingこのディレクティブが構成に設定されていることを確認してください。yessshd
startkde4最後に重要なのは、おそらくSSH（または他のXセッション）を介して実行したくないことです。ネットワーク負荷がかなり重くなる可能性があるため、VNCはより良いサービスを提供します。