ジャンプホストでのSSH ForceCommandはどの程度安全ですか？

ネットワークに次の設定があります。

Internet <--> Bastion <--> Local Network

複数のユーザーがいて、各ユーザーが特定のマシンに割り当てられています。または言い換えると、各ユーザーはこれらのサーバーの1つにのみアクセスできなければなりません。例：User1-> Machine1、User2-> Machine2など。

これらのユーザーはネットワークの外部から接続します。要塞ホストを介して接続をネットワークに転送する方法については、多くのオプションを検討しました。

最終的に私は、Match Blocksとforcecommandを選択しました。

したがって、要塞の/ etc / ssh / sshd_configは次のようになります。

Match User User1
        ForceCommand ssh User1@Machine1 $SSH_ORIGINAL_COMMAND

User1は、Machine1との接続を自動的に確立する要塞ホストに接続します。

私がForceCommandを理解している限り、User1は要塞ホストに実際にアクセスできません。これは、彼のすべての操作が最初に一致ブロックによって処理され、Machine1に再ルーティングされるためです。しかし、これは本当に本当ですか？これで、安全なセットアップで十分ですか？ユーザーはとにかくMachine1で投獄されているので、そこでは多くの可能性はありません。

私は要塞ホストを使用する方法は、使用しているProxyCommandと-W、この例のようにフラグ。

ssh -o ProxyCommand='ssh -W %h:%p user@bastion' user@machine

セキュリティ上の理由から、このアプローチを使用しています。クライアントとターゲットマシン間の通信は暗号化され、エンドツーエンドで認証されます。つまり、要塞が侵害された場合でも、通信は保護されたままです。セキュリティが侵害された要塞ホストは、要塞なしでsshをエンドツーエンドで使用する場合と同等のセキュリティを提供します。

また、エージェント転送を使用する必要もなくなります。クライアントは、最初に要塞ベースの認証を使用して要塞にアクセスし、次にターゲットホストにアクセスすることができます。クライアントに存在する秘密キーを悪用するために使用できるエージェント接続が提供されていません。

また、要塞ホストに依存しているコードも制限されます。要塞でコマンドを実行する必要はまったくありません。-Wnoコマンドフラグと1つの単一ポート転送を意味します。このポート転送は、要塞ホストが許可する必要があるすべてです。

このアプローチを念頭に置いて、私の推奨は、上記の構造のコマンドのみを使用できるように、要塞ホストをできるだけロックダウンすることです。

~/.ssh/authorized_keys要塞上のファイルはルートによって所有される可能性があり（ファイルシステムのルートからそのパスへのパス上のすべてのディレクトリも同様）、これにより、誰かが権限のないユーザーとして侵入した場合でも、ファイルが変更されるリスクを軽減できます要塞ホスト。

ではauthorized_keys、クライアントの権限は、オプションを使用して制限することができcommand、no-agent-forwarding、no-pty、no-user-rc、no-X11-forwarding、だけでなく、使用したpermitopenだけで、このユーザーがアクセス許可されているホスト上のポート22へのアクセスを許可するように制限ポート転送に。

原則として、複数のユーザーが要塞で1つのユーザー名を共有している場合でも、このアプローチは安全です。ただし、要塞で別のユーザー名を使用することで、少し離れます。

ForceCommandは、シェルが起動したときに起動するため、簡単に回避できます。これは基本的に、シェルrcファイルが最初に処理され、次にそこに到達することを許可する場合はForceCommandが処理されることを意味します。exec shシェルのrcファイルで単純な場合、別のシェルが起動され、このシェルを終了するまでForceCommandが待機し続けます。

つまり、一番下の行。ユーザーが何らかの方法でftp、sftp、scp、またはその他の方法でシェルrc（たとえば.bashrc）を編集できる場合、ForceCommandは実際に依存するものではありません。

ほとんどの場合それで問題ないと思いますが、セキュリティに関する問題は、誰もまだ考えていないことです。保証はありません。

たとえば長い間、誰もがbashの環境変数から関数を作成する方法についてあまり熱心に考えていませんでしたが、最近人々はそれが破壊される可能性があることを認識し、その影響の1つはForceCommandが回避されることでした（ユーザーのシェルがbashの場合は、少なくともauthorized_keysファイルに実装されているとおり）。Bashは修正され、うまくいけばあなたのバージョンは最新ですが、このようなことが起こります。

ForceCommandを定義することが、authorized_keysファイルでこれらのコマンドを定義することと実質的に同じであるかどうかは、完全にはわかりません。私はそれをよく見ていません。

作り.bashrcが所有しているroot:usergrpユーザーが新しいファイルを作成する許可しない$ HOMEにまだログインしているユーザとして実行しているのsshdで読み取り可能。設定パーマ/所有者を。この方法でrootはの内容を制御し.bashrc、必要なことを実行できるようにしますが、ユーザー自身はそれらの設定、または間接的にの内容の変更を許可するファイル/ディレクトリの権限を変更できません.bashrc。

別のアイデアがあります。要塞サーバーのユーザーごとに、/ etc / passwdのシェルを、ssh user1 @ machine1、user2 @ machine2などを単に実行するbashスクリプトになるように定義できます。これにより、有効なユーザーがいないことを確認できますサーバー自体のシェルと、接続先のマシンに接続するだけです。