リモートポート転送によるJumphostによるSSHセッション

リモートポート転送によるJumphostによるSSHセッション

リモートポート転送を介してSSHを介して接続する際に問題があります。

シナリオは企業ネットワークであり、内部ネットワークのサーバー(「ソース」と呼ばれる)はSSHを介してDMZ(「ターゲット」)にあるサーバーにログインする必要があります。 DMZのターゲットサーバーは内部ネットワークからの接続のためにロックされている(内部ネットワークでも見えない)、DMZにジャンプホスト(「jumphost」)があります。ジャンプホストでリモートポート転送を設定してこれを実現します。

内部ネットワークのソースサーバーからジャンプホストにこのコマンドを実行します。

origin> ssh -R *:1234:target:22 myusername@jumphost

これは、ジャンプホストでSSHセッションを確立してポート1234(任意のポート番号の例)でリッスンを開始し、そのポートの接続を宛先サーバーポート22(SSH)に転送することです。

次に、ソースサーバーからジャンプホストまでポート1234で2番目のSSHセッションを確立し、そのセッションは実際にはポート22のターゲットサーバーに接続します。これは「実際の」SSHセッションであり、操作を完了できます。ターゲットサーバーから:

origin> ssh jumphost -P 1234

構成

ジャンプホストは、リモートポート転送を許可するように構成されています。 sshd_config で以下を設定します。

AllowTcpForwarding yes
GatewayPorts yes

また、送信元サーバーとジャンプホストの間に、ポート22(リモートポート転送を設定するための初期SSH接続用)とポート1234(転送ポートの後続のSSH接続用)のファイアウォールオープンが設定されています。ジャンプホストとポート22が開いているターゲットの間にもファイアウォールがあります。

結果

2番目の接続(転送されたポートを介した接続)を設定すると、接続はすぐに閉じます(「リモートホストによって接続が閉じられました」)。

ターゲットサーバーでtcpdumpを実行すると、アクティビティは表示されません。つまり、接続がブロックされているように見えます。

ただし、ジャンプホストからターゲットに通常のSSHセッションを正常に確立できました。どちらもポート22の宛先に接続されているが、転送されたポートを介して着信している場合にのみ接続が閉じられます。

さらに重要なのは、内部ネットワークのサーバーへのポート転送を指定した場合(つまり、内部ネットワークのソースからDMZのジャンプホストに接続してから内部ネットワークの3番目のサーバーに再接続する)、SSHはセッションを正常に構築しました。

推測と質問

これはすべて、いくつかのネットワークセキュリティ設定が機能し、ジャンプサーバーの転送ポートを介してDMZ内のターゲットサーバーへの接続を妨げていると信じています。残念ながら私は知るのに十分ではありません:

(1)ネットワークセキュリティポリシーの観点から、ソースサーバーからジャンプサーバーの転送ポートを介したSSH接続が「異なる」と技術的にブロックできますか?では、どうやって停止しますか?この制限を解除するにはどうすればよいですか?

(2)この接続を許可しない他の理由(ファイアウォール構成、ルーター構成、ソースまたはジャンプホストのSSH設定)、他の理由はありますか?

(3) ソースサーバがターゲットサーバを知らないため、最初の ssh コマンドが失敗し、最初の ssh コマンドが期待どおりに動作しないことがありますか?つまり、最初のsshコマンド(「destination」)で指定されたホスト名は、クライアント(ソース)またはトンネルを生成するために接続しているサーバー(ジャンプホスト)から解釈されますか?

私を最も混乱させることは、ジャンプホストからターゲットに通常のSSHセッションを確立することが可能であるということです。転送されたポートを介して入ってくるSSH接続も同じだと思いましたが、それはそうではありません。

どんなアドバイスも本当にありがとうございます。

ベストアンサー1

リモートポート転送の代わりにローカルポート転送を使用する必要があるようです。 Dirk Lossの次の便利なブログ記事を参照できます。

これには次の図が含まれます。

SSHポート転送:ローカル対リモート

この図を読むには、SSHトンネルの作成と使用に関連する4つの役割間の関係を説明することに注意してください。

  • トンネル設定用のSSHクライアント(例:sshOpenSSHコマンドラインクライアント)
  • sshdトンネルのもう一方の端(OpenSSHサーバーデーモンなど)でSSHサーバーを維持するために使用されます。
  • アプリケーションサーバー(例:他のSSHサーバーまたはhttpサーバー)
  • アプリケーションサーバーにトンネリングするアプリケーションクライアント(たとえば、他のSSHクライアントやWebブラウザ)。

2つの配信タイプが2つのユースケースに対応することを理解することも重要です。

  • ローカル転送:アプリケーションクライアントがSSHクライアントを介して接続する場所

  • リモート転送:アプリケーションクライアントがSSHサーバーを介して接続

転送はローカル(sshクライアント)ではなくリモート(sshサーバー)で実行されるため、リモート転送と呼ばれます。また、「リモートフォワード=リバースフォワード」が便利なニーモニックであることがわかりました。

ご覧のとおりssh、ホストのクライアントからプロキシのサーバーを介して3番目のホストに接続を開始するには、ローカルポート転送を使用する必要があります。リモートポート転送は、トンネルのエントリポイントがクライアントを実行しているホストではなく、サーバーを実行しているホストにある場合に便利です。originsshdjumphosttargetsshdssh

マニュアルページでは、ローカルポート転送構文は次のように書かれています。

ssh -L [bind_address:]port:host:hostport user@remote

より直感的に次のように書くことができます。

ssh -L [local_bind_address:]local_port:remote_host:remote_host_port user@proxy_host

または、次の命名規則を使用してください。

ssh -L [origin_bind_address:]origin_port:target_host:target_host_port user@jump_host

ローカルポート転送を使用するようにコマンドを変更すると、次のようになります。

user@origin:~$ ssh -L *:1234:target:22 myusername@jumphost

おすすめ記事