追加サーバーを介したSSH X11転送を有効にする方法は?


33

ホストA、B、Cがあります。ホストAIからはsshのみを介してアクセスできます。BIからはCにアクセスできます。CでX11プログラムを実行し、表示をAに転送できるようにします。

私はこれを試しました:

A $ ssh -XB
B $ ssh -XC
C $ xclock
エラー:ディスプレイを開けません:

しかし、それは機能しません。

回答:


25

これを行うにはいくつかの方法がありますが、私が好むのはsshポートを転送することです:

最初に、マシンBに接続し、[localPort]をB経由でC:22に転送します

A$ ssh -L [localPort]:C:22 B

次に、[localPort]を使用してこの新しく作成されたトンネルを介してAからCに接続し、X11を転送します

A$ ssh -X -p [localPort] localhost

これで、CでX11プログラムを実行し、Aに表示させることができます。

C$ xclock

[localPort]は、Aでまだリッスンしていない任意のポートにすることができます。簡単にするために、2222をよく使用します。


3
正確ではありません...サーバーCでX11Forwardingが有効になっていない場合、機能しません。それはまた、この答えは全く受け入れられないサーバBにはいAllowTCPForwardingにし、GatewayPortsをyesを1セットしない限り動作しません
asdmin

X11ForwardingとAllowTcpForwardingがデフォルトで有効になっているdebianを使用しているので、良い点を指摘します。GatewayPortsは、無効にされてもSSHがlocalhostでリッスンし、それが接続先であるため、必要ありません。マシンAの外部IPを介して2番目の接続を行う場合にのみ必要になります
。– dave

ステップ1では、ホストBのパスワードを要求されず、ホストCに接続されました。別のウィンドウでステップ2を試してみると、「ssh_exchange_identification:Connection closed by remote host」が表示されます。
msb

ssh:ホストへの接続...ポート22:最初のコマンドの実行中に接続が拒否されました
ロドリゴ

7

これは、ポート転送を使用して簡単に実現できます。

A$ ssh -NL 2022:C:22 B &
A$ ssh -X -p 2022 localhost
C$ xclock

ポートlocalhost:2022はB経由でC:22に転送されますlocalhost:2022経由でCにSSH通常どおりXを使用します


2
これは、ケースB(ゲートウェイ)で正しいsshd転送オプションが有効になっていない場合に、他で説明した同じ理由で機能しません。
g33kz0r 14年

ホストBにパスワードを要求しませんでした。これは奇妙です。そして、それが機能しなかった、私はエラーメッセージました「:オープンに失敗しました:管理上禁止:オープンして失敗したssh_exchange_identification:チャンネル2の接続はリモートホストによって閉じ」
MSB

4

問題は、中央のマシンにはXがないが、そうでなければX11の転送を許可するように構成されていることで、xauthをインストールするだけです。

yumベースのシステム(fedora、redhat、centos):

B$ sudo yum install xauth

aptベースのシステム(debian、ubuntu):

B$ sudo apt-get install xauth

頭なしのラズベリーパイに最適です。
cmc

@cmcまたはvpnのようなsshを使用します。
ジェイエン

@cmcはyumpi を持っていますか?
ジェイエン

nope- sudo apt-get install xauth
cmc

3

新しいバージョンのopensshdではX11UseLocalhost、これを機能させるために無効にする必要があります。

ホストCでこれを実行し/etc/ssh/sshd_config、これを機能させるためにsshdを再起動する必要があります。

X11Forwarding yes
X11UseLocalhost no

2

使用しているsshdでX11Forwardingが無効になっている場合、X11ディスプレイを転送できません。

man sshd_config:

X11Forwarding
  Specifies whether X11 forwarding is permitted. The argument must be “yes”
  or “no”.  The default is “no”.

宛先および使用しているすべての中間sshdでX11Forwardingが有効になっていることを確認する必要があります。

ほんの小さなヒント:VNCを使用する必要があります。X11ディスプレイ転送は帯域幅を大量に消費します。


@AgentKおよび@daveの提案では、最終ホストでX11Forwardingを有効にするだけで済みます。これは、SSHトンネルを使用して中間ホストをバイパスするためです。あなたの提案はほとんど間違いなくOPの方法が最初は失敗した理由ですが、それは他の人の答えが「受け入れられない」という意味ではありません
ダニエル・ローソン

彼らの答えは不完全であり、問​​題を解決するのではなく解決した。正しく有用な答えは、元の質問を考慮して解決し、元の質問が解決できない場合にのみ他の方法を提供します。ところで、どちらもそれらの不可欠であるX11Forwardingを、言及
asdmin

一部のシステムでは、デフォルトは「yes」です。
ブラッドギルバート

BとCでX11Forwardingが有効になっており、BでAllowTcpForwardingがyesに設定されていることを確認しました。しかし、コマンドの結果は同じです。そして、デイブの答えは私にとってはうまくいきます。
lexsys 2009

その後、それを行いますが、それはただの救済策です。パラメーター '-v'でsshを開始するか、ネストされたsshコマンドをすべて$ DISPLAYでエコーして、$ DISPLAYが失われる場所を見つけることもできます
asdmin 09

2

AからCに頻繁に移動する場合、Bをプロキシとして構成できます。

A:~/.ssh/config

Host C
  ForwardX11   yes
  ProxyCommand ssh -W %h:%p B

それはただです:

A$ ssh C xclock

弊社のサイトを使用することにより、あなたは弊社のクッキーポリシーおよびプライバシーポリシーを読み、理解したものとみなされます。
Licensed under cc by-sa 3.0 with attribution required.