web-dev-qa-db-ja.com

ssh -X "Xtエラー:ディスプレイを開けません::0.0"

リモートサーバー(Ubuntu Server 10.04)でsshでxtermを開こうとしています:

ssh -X name@machine xterm

ただし、返されるエラーは次のとおりです。

xterm Xt error: Can't open display: :0.0`

私はグーグルで見つけたすべてのものを試しました。まだこのエラーが発生しています。 DISPLAY変数は自動的に設定されるはずですよね?

sshd_configの一部:

X11Forwarding yes
X11DisplayOffset 10
PrintMotd no
PrintLastLog yes
TCPKeepAlive yes

何かアドバイス?

8
Fabian

Sshが接続を確立できる場合、DISPLAYを適切な値に設定します。 X11DisplayOffsetが10(デフォルト値)に設定されているため、sshは10から始まる最初の使用可能なディスプレイを使用します。10¹未満の値が表示される場合は、少なくともDISPLAYをオーバーライドすることにより。値:0(または:0.0、ドットの後の部分は無関係)は、マシンで開始された最初のディスプレイを示します。これは通常、アクティブセッション(またはグラフィカルログインプロンプト)です。マシンのコンソール。

観察される動作の最も可能性の高い説明は、シェル構成ファイルの1つがDISPLAYを設定していることです。最も明らかな原因は~/.bashrcです(シェルがインタラクティブではない場合でも、bashの親がrshdまたはsshdである場合は常にbashの癖のために実行されます)。環境変数を定義する別のファイルは/etc/environmentです。その場合、解決策は明らかです。DISPLAYを設定しないでください。 (DISPLAYを手動で設定する必要がある場合はほとんどありません。)

他にもエキゾチックな説明があります。これは、ログインシェルをscreen(理論的にはかわいいアイデアですが、実用的ではない)に変更し、画面内でDISPLAYを強制的に設定するシェル初期化ファイルがある場合に起こりますアイデア)。これは、クライアントが送信した環境変数(sshd_configAcceptEnvディレクティブ)を受け入れるようにサーバーを構成し、クライアントがDISPLAYを送信しており、X接続ができない場合にも発生する可能性があります設立。または、~/.ssh/authorized_keyscommandディレクティブを介してサーバーに環境変数を設定すると発生する可能性があります。または、xtermをスクリプトにすることもできます。

¹ または、X11DisplayOffsetの値がサーバー構成に含まれていても、デフォルトからほとんど変更されていません。

7
Gilles

あなたのコマンドは動作するはずです、または少なくともそれは私のために動作します。代わりにこれを試してください:

ssh -Y user@machine xterm

編集(1):

これを試して:

ssh -X user@machine env

すべての環境が表示されるはずです。そこにはさまざまなSSHのものと、DISPLAYも必要です。 DISPLAYは10.0でなければなりません。

これを試すこともできます:

ssh -X user@machine DISPLAY=10.0 xterm
3
ed.

X11Forwarding yesに加えて、追加する必要もありました

X11UseLocalhost no

/etc/ssh/sshd_config

here のように説明します。

2
user2400538

Xのアクセス制御はおそらく邪魔です。

xhost +(パッケージx11-xserver-utilsから)を実行して、アクセス制御を完全に無効にします。

2
Geert

Xauthがインストールされていないことがわかりました。

1
allen

また、クライアントエンドにX11がインストールされていることを確認してください。 MacをOS X Mountain Lionにアップグレードしたときにこの問題が発生していました。 Mountain LionはX11を削除するため、オープンソースのX Quartzプロジェクトを介して再度インストールする必要があります。 http://xquartz.macosforge.org/landing/

0
Paul Maunders