これは、Windows-Subsystem for Linux固有の情報で他の回答を補完しています。受け入れ答えは正しいです:あなたのDISPLAY変数が正しく設定されていません。ただし、その答えだけでそれが当てはまる理由は明確ではないため、この答えで修正しています。
あなたがLinux用のCygwin、またはWindowsサブシステムを実行している、とあなたのX11サーバーがWindowsベースの(例えばある場合VcXsrv、またはXMing)、それは可能性が高いあなたのX11サーバがTCPポートでリッスンしていること(例えばある127.0.0.1TCPポート上6000-6010)よりもデフォルトのUnixドメインソケット(/tmp/.X11-unix/X0)。Unixソケットは、WSL内であっても、現時点ではWindowsで十分にサポートされていません。Linuxライクな環境のプログラムとWindowsホストで直接実行されているプログラム間の通信も、一般にIPソケットよりも簡単です。
グラフィカルアプリケーションをローカルで(ホストのCygwinまたはWSL環境から)実行し、DISPLAY変数がデフォルト(つまりDISPLAY=:0.0)に設定されている場合、アプリケーションはまずUnixソケットを介してXサーバーへの接続を試みます/tmp/.X11-unix/X0。これは失敗localhostしますが、Xサーバーがデフォルトで設定されていると仮定すると、ほとんどのアプリケーションはTCP接続にフォールバックし、サーバーへの到達に成功するはずです。
connect()グラフィカルアプリケーションの実行からstraceログで呼び出しを探すことで、これが起こっていることを確認できます。これらは通常、アプリケーションのメインウィンドウが表示される前の早い段階で発生します。
sshがリモート側から接続をリダイレクトしている場合、そのフォールバック動作は発生しないため、そのエラーが発生します。sshd実際に接続をローカル側に転送していますが、sshクライアントのローカル接続は、Unixソケットを介してサーバーに到達できないために行き詰まります。その後、ENOENTエラーが発生します。
このような場合、DISPLAY構文の代わりにTCP構文を使用するように変数を変更:0.0すると、問題を修正できます。
DISPLAY=127.0.0.1:0 ssh remote some-gui-application
他の回答で言及したように、シェルプロンプトからその変数をインタラクティブにエクスポートすることもできます。
$ export DISPLAY=127.0.0.1:0
...
$ ssh remote some-gui-application
ログインシェルプロファイル初期化スクリプトにその行を追加することにより、この設定をより永続的に保存することもできます(例:)~/.bash_profile。
注:一部のシェルには、ログインセッションと非ログインセッション用に異なる初期化スクリプトがあります。たとえば、bashを使用すると、その行を非ログインスクリプト、つまりの~/.bashrc代わりに書き込むことができます~/.bash_profile。その場合、sshによって設定されたカスタム値を上書きしないように注意してください。最初にsshを介してホストにホッピングし、次に別のホストに再びホッピングする場合(X11フォワーディングをネストする場合)に該当します。
strace -fo /tmp/trace ssh....Unixドメインソケットに接続しようとするかどうかを確認するために使用します。