共通サーバーを共有するサーバーがたくさんありますTrustedUserCAKeys。すべてのサーバーではなく、特定のサーバーに特定のアクセス権を付与するようにユーザー証明書に署名したいと思います。
たとえば、次のコマンドは、すべてのサーバーでrootとしてログインするために使用できる証明書を生成します。
ssh-keygen -s ca -I example -n root id_rsa.pub
次のコマンドを試しましたが、役に立たない証明書が生成されました。
ssh-keygen -s ca -I example -n root@server1 id_rsa.pub
server1にはrootとしてのみログインでき、他のサーバーにはログインできない証明書を生成する予定です。これがそのサーバーのserver1FQDN（またはの完全な内容）であることを確認しました。/etc/hostnameホストに触れることなくこれを達成する方法はありますかsshd_config？
答え1
ファイルを変更しない場合、通常、sshd_config答えは「いいえ」です。これを達成するメカニズムはAuthorizedPrincipalsFile（またはAuthorizedPrincipalsCommand）を設定することです。このディレクティブがない場合、デフォルトの動作sshd_configは、認証試行のユーザー名を文字通り証明書に含まれるサブジェクトの1つとしてリストする必要があることです。これが「root」は機能しますが、「root@server1」が機能しない理由です。
'root@server1'を使用する証明書が機能するには（エントリを追加する必要はありません/root/.ssh/authorized_keys）AuthorizedPrincipalsFile、rootユーザーの証明書を設定し（以降、OpenSSHバージョンではMatchブロック内でこのディレクティブを受け入れる）、 'root@server1'を一覧表示するします。 、他のサーバーでも同様の操作を行います。また、それを拡張して、「root @ dev」や「root @ *」などのサーバーグループに適した証明書を許可することもできますAuthorizedPrincipalsFile。
.ssh/authorized_keysこれを行うもう1つの方法は、cert-authorityオプションを使用してファイルにCAキーと許可されたプリンシパルを明示的に一覧表示することですprincipals= 。これは、sshdAuthorized_Keysファイル形式のマニュアルページの説明に含まれています。
答え2
問題は、SSH証明書の発行時に直接入力すると、CAを信頼するすべてのサーバーへのアクセス権が付与されることroot
です。Principals
これを防ぐために問題を引き起こさないでくださいusername。代わりにアクセスポリシーを開発してください。一般的なシナリオは、一部の人はテストサーバーにアクセスする必要があり、一部の人はデータベースサーバーにアクセスし、一部の人はすべてのサーバーにアクセスする必要があります。それで、いくつかの原則を作りました。
project-dev- 開発/テストサーバーへのアクセスproject-databases- データベースサーバーに接続するproject-super- すべてのサーバーに接続
これを達成するには、AuthorizedPrincipalsFile /etc/ssh/auth_principals/%uファイルを追加してくださいsshd_config。
したがって、誰かがユーザー名を使用してサーバーにログインしようとすると、rootファイルを確認します/etc/ssh/auth_principals/root（%uユーザーに代わって通知）。
したがって、ユーザーの証明書にこのファイルに記載されている原則がある場合、ユーザーにアクセス権が付与されます。
このシナリオの承認ポリシーファイルは次のとおりです。
- 開発サーバー -
project-dev\nproject-super - データベースサーバー -
project-dev\nproject-super - 本番サーバー -
project-super
したがって、あなたのニーズに応じて戦略を開発してください。
root注：inを使用して証明書を発行しても、引き続き機能Principlesします。だから、このような状況を避けてください。
私は完全なSSH証明書インフラストラクチャを設定するためのブログを作成しました。