SSHキーを90日ごとに期限切れにするシステムを持っている
GDPRの解釈が原因で、すべてのパスワードを90日ごとに変更する必要があるというお客様がいます。私たちがそれらのルールを実装するだけでよいので、私たちが彼らのために開発したWebベースのシステムにとってそれは問題ありません。ただし、サーバーへのアクセスに使用するSSHキーのパスワードを変更する必要もあります。これは問題ありません。
- 既存のSSHキーのパスワードを変更することはできますか？
そうでない場合、これを処理するために使用できるツールはありますか？考えている：
a。新しいキーを作成します。
b。すべての公開鍵を既存のサーバーに配布します。
c。既存の公開鍵を削除します。
d。古い秘密鍵をアーカイブします。ここでPuppetに関するいくつかの投稿を読みましたが、理解しているように、それらはサーバー間で公開鍵を配布することだけで問題を解決し、n日ごとに新しい鍵を作成しないことを目的としていますか？ Puppetの研究をさらに進める必要がありますか？
パスワードの保持とSSHキーに関するコミュニティ標準は何ですか？どうやってやるの？
顧客はここで間違っており、彼らが話していることを理解していません。秘密鍵のパスフレーズを変更することは非常に悪いの考えです。非常に直感に反するセキュリティプロパティがあるためです。
通常、ユーザーは、変更したパスワードを「もはや秘密ではない」と考えています。それらは、価値の低いサイト、オンラインハンドル/ニックネーム、ジョークへのパンチラインなどの使い捨てパスワードになる可能性があり、それらが書かれている紙は露出したスクラップになる可能性があります。
秘密鍵の暗号化に使用されるパスフレーズの場合、それはどのように機能するかではありません！パスフレーズは秘密にしておく必要がありますforeverキーに関連付けられたすべての権限が取り消されていない限り（および以下はsshキーに適用されませんが、パスフレーズが署名だけでなく使用されるキー用である場合、ただし、プライベートメッセージを受信する場合は、永久に永久に）になります。これは、暗号化された秘密鍵ファイルが攻撃者によって取得されたか、将来的に攻撃者によって取得される可能性がある場所（バックアップなど）に格納された可能性があるためです。パスフレーズが明らかにされた場合、それは侵害されます。
ある意味では、のいずれか1つのパスフレーズに関する知識があれば、鍵を危険にさらすのに十分であるため、有効期間中にN個のパスフレーズを通過した秘密鍵は1/Nと安全です。攻撃者は暗号化された秘密鍵ファイルにアクセスできました。
さて、あなたの問題に戻りましょう。
顧客がこの「sshパスワード」の誤解にとらわれず、それを掘り下げていなかった場合、正しいことは、それを決して彼らに知らせず、自分でキーを処理するためのベストプラクティスに従うことです。しかし、彼らが持っている今、あなたはおそらく彼らを満足させるために何かをしなければなりません。秘密鍵を暗号化するパスフレーズがパスワードとは異なるセキュリティプロパティを持っている方法を説明することを試みることができますが、ここで顧客が多くのことについて間違っていることを考えると（パスワードの有効期限は一般に悪い考えです）、うまくいくとは思えません。
これにより、新しいキーを配布するシステムを自動化するタスクが残ります。 強く推奨しない秘密キーはマシン間で移動しないでくださいなので、新しいキーを一元的に生成するシステムを自動化しないでください。代わりに、新しい秘密鍵を生成し、対応する公開鍵を公開するためにアクセスする必要がある従業員/請負業者が簡単にできるように、プロセス/リマインダー/スクリプトを用意し、公開鍵配布システム（Puppetまたはその他）を使用する必要があります。アクセスする必要があるシステムにこれらをプッシュして使用します。
さらに：これを削除するように顧客を説得する可能性があることの1つは、新しい秘密鍵が古いものとは異なるパスフレーズを持っていることを強制する方法が根本的にないこと、またはまったくパスフレーズ。
最初の質問への答え："既存のSSHキーのパスワードを変更することは可能ですか？"ははいです。 opensshを使用すると、ssh-keygen -p [-P old_passphrase] [-N new_passphrase] [-f keyfile]と同じくらい簡単です
問題は、パスワードが秘密鍵ファイルの内/上にあることです。これは、有効期限をサポートしない単純な形式です。また、sshでの鍵ベースの認証の概念の大部分は、秘密鍵が一元管理されないということです。秘密鍵はユーザーのワークステーションにのみ存在する必要があるため、秘密鍵にパスワードの有効期限ポリシーを適用することはほぼ不可能です。
代わりに、私が以前使用していたすべての環境で、パスワードポリシーがユーザーアカウントオブジェクトにあり、アカウントへのアクセスに使用するメソッドではありません。パスワードの有効期限が切れたり、アカウントがロックされると、sshキーを含むすべてのアクセス方法がロックアウトされます。
アカウントのセキュリティを強化する必要がある場合は、多要素認証を追加します。
しかし、私は他の人々があなたの正当な懸念に対処するために何をしたのか知りたいです。
AuthorizedKeysCommand を使用すると、サーバー側で有効期限メカニズムを実装できます。ファイルのタイムスタンプの単純なチェックから、より複雑なものまで。
十分な場合と十分でない場合がある1つの可能性は、SSHユーザーCAを使用することです。これにより、署名された鍵に有効期間を設定できます。鍵の署名に使用した自動化が90日を超えると、署名を拒否できます。次に、ユーザーCAの公開鍵を/ etc/ssh/sshd_configのTrustedUserCAKeysに追加し、AuthorizedKeysFileをnoneに設定します。
HashicorpのVaultを使用して、有効期間が短い署名済みのSSHキーを作成する のようなツールを使用できます。各ユーザーは毎日新しいキーを取得します。 LDAPサーバーなど、現在使用しているものを使用して証明書を取得するには、Vaultに対して認証します。
これを設定する努力は莫大ではありませんが、私の経験では、@ Markが彼のコメントで言及したものよりも大きいです。基本的に、1つの問題（無知なクライアント要件）を別の問題（ シャード管理 ）に置き換えます。
しかし、社内のX509証明書を簡単に生成したり、データベースのパスワードやテキストファイルのアプリケーションシークレットを管理したりするなど、他のいくつかのシナリオを可能にします。あなたは努力とROIを判断します。
また、オープンソースバージョンにはDR機能がないことにも注意してください（それ以外はすべてあります）。
時間ベースのワンタイムパスワード（TOTP）を組み込んだキーエージェントを使用できます。今、あなたの「パスワード」は毎分変わります。
ここにいる他のすべての人は正しいですが、これはばかげています。