うまくいかないと思いますが、動作するsshd設定を理解しようとしています。前提は私が開発している本番システムから来ましたが、自己テストのために単純化しました。この単純な例が機能する理由を説明できないため、より複雑な反復が機能する理由も説明できません。
Auser、Buser、およびCuserユーザーを持つ2つのサーバーがあります。
私のクライアントコンピュータのIPアドレスは192.168.10.1です。
私のサーバーには、次のsshd設定があります。
AllowGroups Cuser
Match Address 192.168.10.1
AllowGroups Cuser Buser
Match Address 192.168.10.1
AllowGroups Cuser Auser
sshd_config(5) のマニュアルページによると
一致には条件付きブロックが導入されます。一致する行のすべての条件が満たされると、次の行のキーワードは、他の一致する行またはファイルの最後まで、構成ファイルのグローバルセクションで設定されたキーワードをオーバーライドします。条件を満たす複数の一致ブロックにキーワードが表示される場合、そのキーワードの最初のインスタンスのみが適用されます。
私の解釈は、クライアント（192.168.10.1）では、CuserとBuserだけがサーバーにSSHでアクセスできる必要があるということです。
ただし、これをテストしたとき、Auser、Buser、およびCuserの3人のユーザーすべてにアクセス権がありました。サーバーの sshd ログを見ると、一致する各ブロックがどこに適用されるかがわかります。
Jul 25 10:48:59 server1 sshd[3525]: debug3: Trying to reverse map address 192.168.10.1.
Jul 25 10:48:59 server1 sshd[3525]: debug2: parse_server_config: config reprocess config len 854
Jul 25 10:48:59 server1 sshd[3525]: debug3: checking match for 'Address 192.168.10.1' user buser host client addr 192.168.10.1 laddr 192.168.10.4 lport 22
Jul 25 10:48:59 server1 sshd[3525]: debug1: connection from 192.168.10.1 matched 'Address 192.168.10.1' at line 138
Jul 25 10:48:59 server1 sshd[3525]: debug3: match found
Jul 25 10:48:59 server1 sshd[3525]: debug3: reprocess config:139 setting AllowGroups cuser buser
Jul 25 10:48:59 server1 sshd[3525]: debug3: checking match for 'Address 192.168.10.1' user buser host fedora addr 192.168.10.1 laddr 192.168.10.4 lport 22
Jul 25 10:48:59 server1 sshd[3525]: debug1: connection from 192.168.10.1 matched 'Address 192.168.10.1' at line 140
Jul 25 10:48:59 server1 sshd[3525]: debug3: match found
Jul 25 10:48:59 server1 sshd[3525]: debug3: reprocess config:141 setting AllowGroups cuser auser
興味深いことに、マニュアルページの解釈によると、最初の「reprocess config：139」行だけが適用されると予想しました。これは、AllowGroups キーワードの最初のインスタンスであるためです。ただし、ログを見ると、「構成の再処理中：141 AllowGroups cuser auserの設定」が表示されるので、2番目のインスタンスを適用したいと思います。
ただし、3 人のユーザーがすべて接続できたため、これらの説明のどれも正しいようには見えません。
そのため、いくつかの追加テストでsshd_configを次のように変更しました。
AllowGroups Cuser
Match Address 192.168.10.1
AllowGroups Cuser Buser
Match Address 192.168.10.1
AllowGroups Auser
そして
AllowGroups Cuser
Match Address 192.168.10.1
AllowGroups Auser
Match Address 192.168.10.1
AllowGroups Cuser Buser
3人のユーザーすべてが引き続きログインできます。
もう一つの最終テスト
AllowGroups Cuser
Match Address 192.168.10.1
AllowGroups Buser
Match Address 192.168.10.1
AllowGroups Auser
最後に、AuserとBuserのみがアクセスできます。
これは、最初の一致ブロックがデフォルト設定をオーバーライドするのとほぼ同じですが、後続の一致ブロックは前の一致ブロックに追加されます。
ベストアンサー1
コードを好きなだけ詳細に追跡することはできませんが、何が起こっているのかがわかります。非常に重要な手がかりは、コマンドライン引数、sshd_configファイル、およびここに含まれるファイルを解析するルーチンのソースコードファイルです。
/*
* The strategy for the Match blocks is that the config file is parsed twice.
*
* The first time is at startup. activep is initialized to 1 and the
* directives in the global context are processed and acted on. Hitting a
* Match directive unsets activep and the directives inside the block are
* checked for syntax only.
*
* The second time is after a connection has been established but before
* authentication. activep is initialized to 2 and global config directives
* are ignored since they have already been processed. If the criteria in a
* Match block is met, activep is set and the subsequent directives
* processed and actioned until EOF or another Match block unsets it. Any
* options set are copied into the main server config.
*/
基本的には、3つの構文解析ステップ（コマンドラインパラメータ、ブロックをスキップする最初のパス、ブロックを読み取る2番目のパス）を介して設定キーワードとパラメータ（たとえば、およびCompression no）を読み取るルーチンがあります。解析がどの段階にあるかを追跡するいくつかのフラグ変数があります。 1つはコマンドラインの解析用で、もう1つは最初と2番目のファイル配信用です。AllowGroups foo bar bazMatchMatch
AllowGroups、DenyGroups、AllowUsers、および DenyUsers は、単一の値ではなく複数の値を使用するパラメータです。したがって、ルーチンはその行の引数リストを解析し、各引数を文字列配列に追加します。最初と2番目のファイルパスのフラグはありますが、「新しい一致ブロックです」というフラグはありません。
つまり、最初のMatchブロックが解析され（2回目のパスの開始）、AllowGroupsパラメータが含まれている場合は、既存の値のリスト（Matchブロックの前）が削除され、Matchブロックの新しいパラメータに置き換えられます。ただし、2 番目の Match ブロックも一致して解析された場合、ルーチンにリストを再度クリアするようなシグナルはありません。 AllowGroupsが単一値パラメータの場合、最初のインスタンスのために各新しいインスタンスは無視されます。ただし、複数値パラメータなので、新しいパラメータがリストに追加されます。これは発見したときに混乱する行動です。 （私も）
私の考えでは、解析ルーチンの作成者はテストサーバーのような設定を想定していないようです。つまり、同じ複数値パラメータを設定する複数の有効な一致ブロックを持つことになります。通常、1つのMatchブロックのみが成功し、解析されます。なぜなら、異なるアイテムと一致するからです。あるいは、複数のブロックが成功した場合に複数のブロックが発生するのは、各ブロックが異なるパラメータを設定するためです。
数日前のコメントで、これら4つのパラメータがどのように機能するかが直感的ではないと述べたことがあります。これは質問に対する直接的な答えではありませんが、ここに（子孫のために）私が見つけたものを追加します。
接続が確立され、構成解析の2番目のステップが完了すると、コードは許可/拒否グループを調べて、適用されているグループを確認します。 DenyUsers、AllowUsers、DenyGroups、AllowGroups の順で確認されます。許可/拒否のテストと決定は、次の擬似コードと同様に機能します。
if DenyUsers has > 0 items and user is one of them
deny
if AllowUsers has > 0 items and user is not one of them
deny
if DenyGroups has > 0 items and user is member of one of them
deny
if AllowGroups has > 0 items and user is not a member of any of them
deny
allow
「拒否」決定が行われると、ルーチンは追加の確認を停止します。したがって、「AllowUsers」リストは直感的な方法では機能しません。 「AllowUsers」リストに名前を入力すると、リストにない他のすべてのユーザーが拒否されます。他のユーザーが「AllowGroups」リストにあるかどうかは問題ではありません。これは、「AllowGroups」を参照する前にコードが確認を停止するためです。 「AllowGroups」リストのすべてのグループは、そのグループに属していないユーザーが「AllowUsers」にリストされていても拒否されます。