キーペアを管理するための一般的な実用的な戦略は何ですか？
SSHを使用して多数のサーバーに接続するために使用する少数の異なるワークステーション（およびiPhoneなどのクライアントデバイス）があります。
最初にPKIについて知ったとき、私は自分のワークステーションに単一のキーペアを作成し、それをどこからでもすぐに使い始め（つまり、自分のラップトップにコピーしたことを意味します）、すべてのサーバーアカウントへの接続に使用しました。
それ以来、これはどこでも1つのパスワードを使用するのと同じであり、アクセスを選択的に取り消す必要があるかもしれないという意見が出てきました。ワークステーションの1つが侵害された場合。
基本的に私はキーペアを扱うための個人的な戦略を開発しようとしています：
使いやすさのために実用的でありながら、一般的な使用のためにキーペアを安全に考える正しい方法は何ですか？ （つまり、すべての接続ポイントの使い捨てキーペアが必ずしも意味があるとは思わない）。
過去に行ったように、キーペアがすべてのアクセスポイント（ "me-everywhere-id_rsa"）からグローバルに個人のIDを表すのは間違っていますか、それとも、一意のクライアントとユーザーの組み合わせは常に独自のキー（ "me-on-my-personal-laptop-id_rsa"）の方が適切ですか？
すべてのサーバーに接続するために同じキーを再利用しますか、またはどのような条件下で別のキーを作成することを検討しますか？
認証レルムごとに1つのキーを持つことを好みます。したがって、仕事中のすべてのデスクトップまたはサーバーマシン（すべて非常に物理的に安全で、単一の管理者グループの制御下にある）に対して、私は1つの秘密鍵を持っています。新しい自宅のPCでも、古い自宅のPCと同じ秘密鍵を使用しています。ラップトップや他のモバイルデバイスで別のキーを使用しています。このアプローチにより、きめ細かなリスク管理が可能になります。キーを個別に取り消すことができ、特定のマシンで特定のキーを承認しないことにより、アカウントがエスカレートされた侵入に関与する可能性を制限できます（私はそれほど多くありませんが、オプションです）偏執狂のために）。
複雑なことを何もしない限り、公開鍵のコピーはそれほど難しくありません。承認されたキーの1つの大きなリストを保持し、どこでも同期できます。デバイスの登録とは、そのリストに1つのアイテムを追加し、変更をプッシュすることを意味します。そもそも中央データリポジトリがある場合は、秘密鍵を取得する以上の作業はありません。
個別の秘密鍵を使用することの最も明白な利点は、1つを個別に取り消すことができることですが、それらには可用性の利点もあります。マシンAのシステム管理者が、使用しているCマシンのキーを取り消す場合、まだCのキーを受け入れ、そのキーがAに受け入れられているマシンBを見つけることができるかもしれません。これはかなり難解なように見えますが、これは（ の後で一度起こりました） RNGをシードしない 、ブラックリストに登録されたキーだけに依存する必要がなかったことを嬉しく思います）緊急時にキーを取り消す必要はありませんでした。
個別の失効を許可するという点で、マシンペアごとに個別のキーペアを維持することには理論的な利点さえあります。しかし、メリットは非常に小さく、管理ははるかに困難です（承認リストをブロードキャストすることはできなくなります）。鍵管理の簡素化は、共有シークレットよりも公開鍵暗号が重要な利点です。
すでに要点を確認しました。マシンの1つが危険にさらされた場合、このマシンに含まれる秘密鍵を「取り消す」必要があります。接続するすべてのサーバーを設定して、その鍵を使用した以降の認証試行を拒否する必要があります（つまり、サーバーの.ssh/authorized_keysからの対応する公開鍵）。秘密鍵をパスワード（またはパスフレーズ）で保護することからなる緩和手法があります。これには代償が伴います。つまり、パスワードを入力する必要があります（ ssh-agent はそのために非常に便利です）。一方、これは攻撃者が秘密鍵を取得するのを一時的に阻止する可能性があります（これは侵害の種類によって異なりますが、それが完全なマシンの盗難（モバイルデバイスでのもっともらしいシナリオ）の場合は、パスワードによって阻止されます）秘密鍵に即座にアクセスし、サーバーを再構成するための時間を提供します）。
「PKI」は「公開鍵インフラストラクチャ」を意味し、SSHはその点で初歩的であることに注意してください。本格的なPKIでは、委任と失効の集中化を伴う certificates が使用されます。証明書付き：
- どこかに安全に保存された1つのCAキーペアを作成します。
- クライアントマシンごとに、新しいキーペアを取得します。公開キーはCAによってsignedになります。
- サーバーは、CAによって署名された公開キーanyを自動的に受け入れるように構成されます（サーバーはCA公開キーを認識しますが、個々のクライアントマシンキーは認識しません）。
- cAは失効情報を維持し、定期的に公開します。つまり、受け入れられなくなった公開キーのリストただしこれらのキーはCAによって署名されています（失効情報はサーバーにプッシュするか、プルする必要があります）オンデマンド）。
証明書の優れた点は、決定を一元化できることです。つまり、クライアントマシンから20台のサーバーに接続し、新しいクライアントマシンを追加する場合、新しい公開キーを手動でプッシュする必要がないということです20サーバーすべて。
OpenSSH 、バージョン5.4（2010年3月8日リリース）以降、証明書をある程度サポートしています。 ssh-keygen については、manページの同名のセクションを参照してください。 OpenSSH証明書の形式は、「通常の」X.509証明書（SSLで使用される）よりもはるかに単純です。簡素化には代償もあります。一元化された失効サポートはありません。代わりに、秘密鍵が危険にさらされている場合でも、すべてのサーバーで対応する公開鍵をブラックリストに登録する必要があります。ブラックリストは、OpenSSHではホワイトリスト（sshd_configのオプションAuthorizedPrincipalsFile）です。 、通常、rootの管理下にあります。そのため、失効はうまく機能せず、キーを作成または失うたびに各サーバーで手動で構成する必要があります。これは、PKIが廃止するはずだった正確な不便さです。
OpenSSH証明書は時間制限のあるキーを埋め込むことができるため、あなたはcouldでも時間制限のあるキーを作成します。その場合、各クライアントマシンに、たとえば1週間有効なキーを与えます。 1週間後に無効になるキーと、サーバーに既知のCA公開キーがあれば、CAの主な利点（新しいマシンがクライアントプールに追加されたときにすべてのサーバーに何かをプッシュする必要がない）、およびプライベートキーが危険にさらされている場合、おそらく1週間のクラッキングに抵抗するキーパスワードがあったとしても、ダメージは「限定的」です（ただし、危険がキーロガーによる敵対的買収である場合、これは機能しません）。時間制限のあるキーは時間の経過とともに退屈になる可能性があり、すべてのサーバーにクロックが正しく設定されていると想定していますが、これは常に与えられているわけではありません（サーバーのクロックが大幅にオフでリセットされているため、サーバーからロックアウトされるのは残念です）クロックはサーバーへのSSHアクセスを必要とします...）。
SSHのもう1つの問題は、各サーバーに公開鍵を簡単に追加できることです。これは、攻撃者が秘密キーを危険にさらしてサーバーへのアクセスを取得した場合once、攻撃者は自分の公開キーをそのサーバーの.ssh/authorized_keysに追加できるため、取り消しによる修正はありません。それ。失効は、本来、非同期プロセスです。したがって、十分に厳密な損傷制御は実装されていません。
証明書に対するSSHサポートの欠点を考えると、状況によっては、すべてのサーバーで構成を行う必要がないようにする合理的な方法はありません。新しいクライアントマシンを追加するときは、基本的に次の選択肢があります。
別のクライアントマシンから秘密鍵をコピーします（これが現在行っていることです）。これは、サーバー上で追加の構成を必要としません。
そのマシンの新しい鍵ペアを作成します。すべてのサーバーに公開鍵をプッシュする必要があります。
キーの侵害が発生した場合は、すべてのサーバーに接続して、すべての.ssh/authorized_keysから対応する公開キーを削除する必要があります。これは避けられません（回避するには、証明書を使用する必要があり、SSHは証明書が得意ではありません。上記を参照してください）。次に、if選択肢1を使用し、次にalso新しい鍵ペアを作成して、それを使用していたすべてのclientマシンにプッシュする必要があります侵害された秘密鍵のコピー。
したがって、通常の場合、選択肢1は選択肢2よりも構成作業が少なくなりますが、キーの侵害が発生した場合は逆になります。妥協は通常まれなイベントであるため、これは選択1を優先します（これは既に行っていることです）。したがって、秘密鍵を強力なパスワードで保護し、それをすべてのクライアントシステムにコピーすることをお勧めします。
注：上記のすべてにおいて、SSHを使用してサーバーのリストに接続する必要があり、任意のサーバーにアクセスする必要があると想定しました任意のクライアントマシンから。 might 1つまたは2つの特定のクライアントマシンからのみ特定のサーバーにアクセスするなど、アクセスを制限したい。これは複数のクライアントキーで実行できますが、構成の複雑さが2次式で増加します。
基本的に私はキーペアを扱うための個人的な戦略を開発しようとしています
問題のサーバーを主に担当している場合は、puppet/chefなどの構成管理ツールを探すことを強くお勧めします。どちらにも、SSHキーをマシンに配布する方法があります。
パペットを使い始めたのは、スタッフが変わったときに〜60台のLinuxサーバーのキーをすばやく取り消すための良い方法が欲しかったからです。
キーを管理するための構成管理ツールを配置すると、多くのキーペアを持つことがはるかに容易になります。すべてのボックスのキーを手動で取り消すか、すべてのボックスに新しいキーを追加する代わりに、構成マスターに公開キーを追加するだけで、クライアントは、構成管理に設定したポーリング間隔内で認証リストを更新しますツール。
これは、構成管理ホストが危険にさらされていないことに多くの信頼を置いていることを意味します。通常、構成先のすべてのマシンでroot権限でタスクを実行するため、多くの監査を行い、厳重にロックダウンされていることを確認する必要があります。攻撃者が構成マスターを危険にさらした場合、新しいキーの追加、新しいアカウントの追加など、何でもできるようになります。
レルムごととマシンごとに1つのキーを使用しています。 2つのワークステーションからアクセスされる4つのリモート=> 8つの秘密鍵。ホストから別のホストに秘密鍵をコピーしないでください。 1つのワークステーションが危険にさらされている場合は、それらのキーをすべて取り消します。
キーを作成し、それらを使用するようにSSHを構成するのは非常に面倒なので、Githubアクセス用の私のSSHキーを管理するための専用ツールを作成しました： github-keygen 。