web-dev-qa-db-ja.com

リモートXディスプレイでウィンドウを開く（なぜ「ディスプレイを開けない」のですか）？

昔々、

DISPLAY=:0.0 totem /path/to/movie.avi

ラップトップからデスクトップにsshすると、トーテムが再生されますmovie.aviデスクトップ上。

今それはエラーを出します：

No protocol specified
Cannot open display:

両方のコンピュータで安定したときにDebian squeezeを再インストールしましたが、設定を壊したようです。

私はこれをググってみました、そして私の人生のために私がしていることになっていることを理解することはできません。

（VLCには機能するHTTPインターフェースがありますが、sshほど便利ではありません。）

これをcronジョブから実行しようとすると、同じ問題が発生します。

sshx11cron
83
justin cress

（ Linux：wmctrlはssh + screenを介してセッションを開始するとディスプレイを開くことができません）から変更 ）

表示と権限

XプログラムがXディスプレイに接続するには、2つの情報が必要です。

  • ディスプレイのアドレスが必要です。これは通常、ローカルにログインしている場合は:0、リモートでログインしている場合は:10、:11などです（ただし、アクティブなX接続の数に応じて数は変化します）。ディスプレイのアドレスは通常、DISPLAY環境変数で示されます。

  • ディスプレイのパスワードが必要です。 Xディスプレイのパスワードはmagic cookiesと呼ばれます。マジックCookieは直接指定されていません。それらは常にX権限ファイルに格納されます。これは、「display :42 has cookie 123456」という形式のレコードのコレクションです。 X権限ファイルは通常、XAUTHORITY環境変数で示されます。 $XAUTHORITYが設定されていない場合、プログラムは~/.Xauthorityを使用します。

デスクトップに表示されているウィンドウを操作しようとしています。デスクトップマシンを使用しているのがあなただけの場合は、表示名が:0である可能性が非常に高くなります。 X権限ファイルの場所を見つけるのはより困難です。これは、gdmがDebian squeezeまたはUbuntu 10.04で設定されている場合、ランダムに生成された名前のファイルにあるためです。 （以前のバージョンのgdmはデフォルト設定、つまり~/.Xauthorityに保存されたCookieを使用していたため、以前は問題がありませんでした。）

変数の値を取得する

DISPLAYとXAUTHORITYの値を取得するいくつかの方法を次に示します。

  • デスクトップから画面セッションを体系的に開始できます。おそらくログインスクリプトで（~/.profileから）自動的に開始できますが、Xでログインしている場合にのみ実行できます。DISPLAYが:で始まる値に設定されているかどうかをテストします（あなたが遭遇する可能性が高いすべてのケースをカバーしてください））。 ~/.profile内：

    case $DISPLAY in
  :*) screen -S local -d -m;;
esac

    次に、sshセッションで：

    screen -d -r local

  • DISPLAYおよびXAUTHORITYの値をファイルに保存して、値を呼び出すこともできます。 ~/.profile内：

    case $DISPLAY in
  :*) export | grep -E '(^| )(DISPLAY|XAUTHORITY)=' >~/.local-display-setup.sh;;
esac

    Sshセッションで：

    . ~/.local-display-setup.sh
screen

  • 実行中のプロセスからDISPLAYおよびXAUTHORITYの値を検出できます。これは自動化が困難です。対象のディスプレイに接続されているプロセスのPIDを把握し、/proc/$pid/environ（eval export $(</proc/$pid/environ tr \\0 \\n | grep -E '^(DISPLAY|XAUTHORITY)=')¹）から環境変数を取得する必要があります。

クッキーのコピー

別のアプローチ（ Arrowmaster による提案に従う）は、sshセッションで$XAUTHORITYの値を取得しようとせず、Xセッションでcookieを~/.Xauthorityにコピーすることです。 Cookieはログインするたびに生成されるため、~/.Xauthorityに古い値を保持しても問題ありません。

リモート管理者がその内容を表示できるようにするNFSまたはその他のネットワークファイルシステムを介してホームディレクトリにアクセスできる場合、セキュリティの問題が発生する可能性があります。 X TCP接続（Debianはデフォルトでオフになっている）を有効にしていない限り、彼らはまだあなたのマシンに何らかの方法で接続する必要があります。そのため、ほとんどの人にとって、これは適用されません（いいえNFS）または問題ではありません（X TCP接続なし）。

デスクトップXセッションにログインするときにCookieをコピーするには、~/.xprofileまたは~/.profile（または、ログイン時に読み取られるその他のスクリプト）に次の行を追加します。

case $DISPLAY:$XAUTHORITY in
  :*:?*)
    # DISPLAY is set and points to a local display, and XAUTHORITY is
    # set, so merge the contents of `$XAUTHORITY` into ~/.Xauthority.
    XAUTHORITY=~/.Xauthority xauth merge "$XAUTHORITY";;
esac

¹ 原則として、これには適切な引用がありませんが、この特定のインスタンスでは、$DISPLAYおよび$XAUTHORITYにはシェルメタキャラクターが含まれません。

81
Gilles 'SO- stop being evil'

私はこの問題を追加して解決しました

xhost +si:localuser:$USER

~/.xprofile。これが完全に安全であるかどうかはわかりませんが（より知識のある人々の意見を聞いて非常に興味があります）、アクセス制御をオフにするよりもはるかに優れていると思います（xhost +）この問題についてグーグルするときに一般的に推奨されるように。

20
edam

必要がある export DISPLAY=:0.0

7
asoundmove

私にはうまくいきます、debian wheezy-> ubuntu trusty。

注：この場合、サーバーはディスプレイマネージャーを実行していません。グラフィックカードやモニターが接続されていない「ヘッドレス」仮想マシンです。

bob@laptop:~$ grep -iB 1 tcp /etc/gdm3/daemon.conf
[security]
DisallowTCP = false
bob@laptop:~$ ssh -C -R 6000:127.0.0.1:6000 alice@server
X11 forwarding request failed on channel 0
alice@server:~$ export DISPLAY=:0.0
alice@server:~$ xterm

ラップトップのXディスプレイには、サーバーで実行されているxtermの出力が表示されます。

使用してデバッグ：

bob@laptop:~/tmp$ nc -v 127.0.0.1 6001
localhost [127.0.0.1] 6001 (x11-1) : Connection refused
bob@laptop:~/tmp$ nc -v 127.0.0.1 6000
localhost [127.0.0.1] 6000 (x11) open
alice@server:~$ nc -v 127.0.0.1 6000
Connection to 127.0.0.1 6000 port [tcp/x11] succeeded!*
alice@server:~$ strace xterm

straceは、何が行われているのかについての多くの悲惨な詳細情報をこぼします。接続がどこで停止しているのかを推測できるはずです-接続を待っているなど。

一行で..

ssh -C -R 6000:127.0.0.1:6000 alice@server "DISPLAY=:0.0 xterm"
3
jmullee