web-dev-qa-db-ja.com

ネットワーク名前空間、ssh、X11

マシン（=クライアント）から別のマシン（=サーバー、実際にはLAN内にありますが、関係ありません）に（ssh -Y ...を介して）接続します。次に、サーバーで新しいネットワーク名前空間（略してNNS）を開始し、クライアントに完全に表示されるxterm（デフォルトの名前空間から）を開始し、最後に、xterm内からデフォルト以外のNNSに参加します、

ip netns exec NNSName bash

新しいNNSにいることを確認できます。

ip netns identify $$

新しいNNS内からOpenVPNなどの複雑なプログラムを実行できます。

こすりはここにあります：新しいNNS内からグラフィカルアプリケーション（今のところxeyesだけでも）を開始したいのですが、できません。常に次のように言われます：Unable to open DISPLAY=...

確かに、私は明白なことだけを試しました：

DISPLAY=:0.0
DISPLAY=:10.0
DISPLAY=localhost:10.0
DISPLAY=localhost:20.0
DISPLAY=ClientName:10.0
DISPLAY=ClientIPAddress:10.0

純粋なデバッグの目的で、クライアントでは常にxhost +を使用します。

私は問題ありません：

  1. ssh -Y ....を介してクライアントからサーバーに接続し、サーバーでxeyesを実行して、クライアントに表示します。

  2. サーバーで新しいNNSを開始し、サーバーに表示されるNNS内のグラフィカルアプリケーションを開始します（つまり、この場合はクライアントを忘れます）。

サーバーの新しいNNSで実行されているクライアントアプリケーションに表示できないのは、これら2つのもの（sshと名前空間）を組み合わせたときです。

標準のTCPポート6010はデフォルトのNNSのsshセッションに属しているようですが、新しいNNSは独自のものを取得する必要があります。新しいNNSでsshサーバーを起動して、直接接続できます。クライアントからサーバーの新しいNNSに移動しますが、疑問に思っていました。これを行う簡単な方法はありますか？ieサーバーの新しいNNSで実行されているグラフィカルアプリケーションをクライアントのX11サーバーに表示しますか？

sshx11xorgnetwork-namespaces
7
MariusMatutiae

私も同様の状況にありました。これが私がそれを回避する方法です。

いくつかの背景：異なるIPアドレスでそれらをバインドするために、名前空間内のいくつかのSeleniumFirefoxインスタンスにまたがる必要がありました。しかし、ご存知のように、私はエラーを抱えていました：

Error: Can't open display: localhost:10.0

Mariusが提案したように、UNIXソケットを使用する代わりに、ローカルホストではなくSSHD X11Forwardingを*にバインドし（構成に「X11UseLocalhostno」を追加）、socatを使用して単純なTCP接続をリダイレクトしました。

これを行うことによるセキュリティへの影響に注意してください!!!!

Sshdでのこの変更後、これからログインすると、DISPLAYが自動的に変更されます。

 DISPLAY=localhost:10.0

次のようなものに：

 DISPLAY=10.0.0.1:10.0

その後、リダイレクトする必要があります：

ip netns exec my-NNS socat tcp-listen:6010,reuseaddr,fork tcp:192.168.5.130:6010 &

そうすれば、xeyes、firefox、x-whatever-you-wantで作業できるはずです...：

ip netns exec my-NNS xeyes &

そして、ボイラ！

3
Marco Bicudo

実際、標準的な方法はないようです。

最も明白な解決策があります。ネットワーク名前空間内から、sshサーバーを起動し、通常のオプションを使用して任意のリモートマシンからサーバーに接続します。

ssh -Y [email protected]

その後、任意のグラフィカルプログラムをリモートマシンのX11サーバーで起動できます。 vncなど、同じテーマのあらゆる種類のバリエーションも機能します。

または、通常の楽器を使用できます：iptables、netcat、socat。これがsocatでそれを行うoneの方法です：トリックは、サーバー上のlocalhostスペースがまた、新しいネットワーク名前空間は分離されていますが、X11UNIXソケットは分離されていません。実際、ネットワーク名前空間から、親マシンのXサーバーに表示されるグラフィカルアプリケーションをすぐに開くことができます。したがって、ネットワークネームスペースに親マシンの新しいunixソケットへの書き込みを強制することで、通常のssh X11を使用して、新しいソケットに送信されたデータをclient Xサーバーにリダイレクトできます。サーバーマシンは、新しいネットワークネームスペースに接続することなく、よりシンプルなソリューションを提供します。

これは次のように行われます。新しいネットワーク名前空間では、

export DISPLAY=:1

これにより、まだ何にも接続されていない新しいUnixソケット/tmp/.X11-unix/X1に書き込まれます。リモートクライアントで、コマンドを使用します

socat exec:'ssh me@remoteserver socat unix-l\:/tmp/.X11-unix/X1 -' unix:/tmp/.X11-unix/X0

（のエスケープに注意してください :）。上記のコマンドは、サーバーのunix/:1ソケットの入力をクライアントのunix/:0ソケットに送信します。ローカル（=クライアント上）xhostコントロールを緩和し、unix/:1（= :1 = /tmp/.X11-unix/X1）ソケットの所有権を確認する必要がある場合があります。これは、以前の方法よりもかなり簡単です。新しいネットワーク名前空間にsshサーバーを設定する必要も、IPアドレスを取得する必要もありません。また、xhostを使用して一部のリモートユーザーを許可したり、MITマジッククッキーとsocatを使用したりするなど、X11認証のすべての問題をバイパスします（私もそうではありません）これができることを確認してください）。

これを行う方法は他にもあります（たとえば、クライアントXサーバーで-nolisten tcpオプションを抑制し、socatを使用して:1 unixソケットをクライアントのポートTCP6000に転送するなど）が、それらが深刻なセキュリティ問題を引き起こすことを無視すると、それらは想像力の範囲によって標準ではありません。

1
MariusMatutiae