web-dev-qa-db-ja.com

リモートポートフォワーディング経由のジャンプホストを介したSSHセッション

リモートポートフォワーディングを介したSSH接続の実行に問題があります。

シナリオはエンタープライズネットワークで、内部ネットワーク上のサーバー（ "Origin"と呼びます）は、DMZ内のサーバー（ "target"）にSSH経由でログインする必要があります。 DMZのターゲットサーバーは、内部ネットワークからの接続に対してロックダウンされているため（内部ネットワークからも確認できないため）、DMZにジャンプホストがあり（ "ジャンプホスト」）。これを行うには、Jumphostにリモートポート転送を設定します。

このコマンドは、内部ネットワークのオリジンサーバーからジャンプホストに実行されます。

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

これは、JumphostでSSHセッションを確立し、ポート1234（単なる任意のポート番号の例）でリッスンを開始し、そのポートの接続をターゲットサーバーのポート22（SSH）に転送するためです。

次に、2つ目のSSHセッションを、まだOriginサーバーからjumphostへ、ポート1234で確立します。このセッションは、実際にポート22でターゲットサーバーに接続されます。これが、実際のSSHセッションであり、ターゲットサーバー：

Origin> ssh jumphost -P 1234

構成

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

AllowTcpForwarding yes
GatewayPorts yes

また、ポート22（リモートポート転送を設定するための最初のSSH接続用）およびポート1234（転送されたポートでの後続のSSH接続用）について、オリジンサーバーとジャンプホストの間にファイアウォールの開口部が設置されています。ジャンプホストとターゲットの間にもファイアウォールがあり、ポート22で開かれています。

結果

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

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

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

さらに、内部ネットワーク上のサーバー（つまり、内部ネットワーク上のOriginからDMZ内のジャンプホストへの接続、および内部ネットワーク上の3番目のサーバーへの接続）にポート転送ポイントを作成すると、SSHセッションが正常に確立されました。

憶測と質問

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

（1）ネットワークセキュリティポリシーの観点から、SSH接続は、ジャンプサーバーの転送ポートを介して、オリジンサーバーから「異なる」ものであり、技術的にブロックされる可能性がありますか？そして、その制限を解除するために何をする必要があるでしょうか？

（2）この接続が許可されない他の理由-ファイアウォール構成、ルーター構成、OriginまたはジャンプホストでのSSH設定、他に何かありますか？

（3）オリジンサーバーがターゲットサーバーを認識せず、最初のsshコマンドが意図したとおりに機能しないため、失敗する可能性がありますか？つまり、最初のsshコマンドで指定されたホスト名（ "ターゲット"）は、トンネル（ジャンプホスト）を作成するために接続しているクライアント（起源）またはサーバーで解釈されますか？

最も困惑しているのは、ジャンプホストからターゲットへの通常のSSHセッションを確立できることです。転送されたポート経由で着信するSSH接続は同じだと思いますが、どういうわけかそうではありません。

どんな入力でも大歓迎です。

sshfirewallssh-tunnelingport-forwarding
6
johnyzee

リモートポート転送の代わりにローカルポート転送を使用する必要があるようです。 Dirk Lossによる次の役立つブログ投稿を参照することをお勧めします。

次の図解が含まれています。

ssh port forwarding: local vs remote

図を読むには、SSHトンネルの作成と利用に関連する4つの異なる役割間の関係を説明していることを理解する必要があります。

  • トンネルを確立するために使用されるsshクライアント（つまり、ssh-OpenSSHコマンドラインクライアント）。
  • トンネルのもう一方の端を維持するために使用されるsshサーバー（つまり、sshd-OpenSSHサーバーデーモン）。
  • アプリケーションサーバー（別のsshサーバーやhttpサーバーなど）
  • トンネル経由でアプリケーションサーバーにアクセスするアプリケーションクライアント（別のSSHクライアントやWebブラウザーなど）。

2つの異なるタイプの転送が2つの異なる使用例に対応していることを理解することも重要です。

  • ローカル転送：アプリケーションクライアントがSSHクライアント経由で接続する場所

  • リモート転送：アプリケーションクライアントがSSHサーバー経由で接続する場所

リモート転送は、転送がローカル（sshクライアント）ではなくリモート（sshサーバー）で実行されるため、このように呼ばれます。 「リモート転送=リバース転送」も便利なニーモニックだと思います。

ご覧のように、sshホストのOriginクライアントからプロキシ上のsshdサーバーを経由してjumphostへの接続を開始するには3番目のtargetホストは、ローカルポート転送を使用する必要があります。リモートポート転送は、トンネルへのエントリポイントを、sshdクライアントを実行しているホストではなく、sshサーバーを実行しているホストに配置する場合に使用します。

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

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
8
igal