SSHキーを管理するのに最適なシステムですか？[閉まっている]

42

複数のクライアントコンピューター（ラップトップ、デスクトップなど）があり、管理している複数のサーバーマシンに接続して、すべてSSH経由でログインします。意味のあるsshキーを管理するいくつかのスキームを想像することができ、他の人が何をするのか興味があります。

オプション1：1つのグローバルな公開/秘密キーペア。

1つの公開/秘密キーペアを生成し、すべてのクライアントマシンに秘密キーを配置し、すべてのサーバーマシンに公開キーを配置します。

オプション2：サーバーマシンごとに1つのキーペア。

各サーバーマシンで1つのキーペアを生成し、クライアントマシンに各プライベートキーを配置します。

オプション3：クライアントマシンごとに1つのキーペア。

各クライアントマシンには一意の秘密鍵があり、各サーバーマシンには、接続するすべてのクライアントマシンの公開鍵があります。

オプション4：クライアント/サーバーのペアごとに1つのキーペア

完全に船外？

どれが最適ですか？他のオプションはありますか？適切な構成を評価するために使用する基準は何ですか？

ssh authentication

— 怠acyな
ソース

33

オプション3：クライアントマシンごとに1つのキーペアを使用します。いくつかの理由があります。

クライアントが侵害された場合、そのキー（およびそのキーのみ）をサーバーから削除する必要があります。
すべてのクライアントからすべてのサーバーへの包括的なアクセスを許可することなく、どこからアクセスできるかを決定するのに十分な柔軟性があります。
とても便利。ssh-addには1つのキーしかなく、混乱はありません。
オプション4のセットアップと管理が簡単

オプション4は便利ですが、手間がかかりすぎます。オプション3を使用すると、98％の手間が大幅に削減されます。

— dwc
ソース

4

オプション4の要点がわかりません。それは何の目的もありません。

— niXar 2009年

26

ホームネットワークサーバー、オフィスサーバー、コンサルティングクライアントネットワークサーバー、およびアカウントを持っている他のさまざまなシステムに使用されるSSH IDキーの分離を維持したいので、もう少し複雑なソリューションを使用します。

Linuxワークステーションからほぼ排他的に作業するため、LUKS暗号化を使用してセットアップされたUSBキーがあり、X11ウィンドウマネージャーとHALデーモンがLUKS暗号化ドライブを検出し、挿入されて復号化パスフレーズを入力しようとするとプロンプトが表示されますマウントされます。これを暗号化されたドライブに保存することで、SSHキーをワークステーションに保存することはありません。

次に、~/.ssh/configファイルに次の構成があります。

Host *
    Protocol 2
    IdentityFile %d/.ssh/keys.d/id_rsa.%l
    IdentityFile %d/.ssh/keys.d/id_dsa.%l
    IdentityFile %d/.ssh/keys.d/%u@%l

％dは、 OpenSSHのことで、ユーザーのホームディレクトリであることを翻訳されており、中の〜/ .sshディレクトリに私が作成したkeys.dを、それが適切に装着された場合、暗号化USBドライブ上のディレクトリパスへのシンボリックリンクとして。

％のLの式はクライアントマシンのホスト名とローカルであると翻訳されuは％ローカルクライアントのユーザ名に変換されます。

この構成では、SSHで3つの異なる式を使用してキーを検索できます。たとえば、ローカルクライアントのユーザー名がjdoeローカルクライアントマシン名であったexamplehost場合、リモートサーバーによって存在し受け入れられたキーが見つかるまで、次の順序で検索されます。

/home/jdoe/.ssh/keys.d/id_rsa.examplehost
/home/jdoe/.ssh/keys.d/id_dsa.examplehost
/home/jdoe/.ssh/keys.d/jdoe@examplehost

％r式を使用して、リモートサーバーのユーザー名に固有のキーを検索したり、％uと％lが使用されたようにリモートサーバーのホスト名に％hを検索したりすることもできます。

更新：GnuPG gpg-agentとssh-agentの互換性を実際に利用して、OpenPGP v2スマートカードから認証キーを読み取って使用するだけです。

— ジェレミー・ブーズ
ソース

うわー、素晴らしいソリューション、ありがとう！私は、の〜/ .ssh / configにユニバーサル設定愛する

— slacy

仕事用、個人用、コンサルティング用のクライアントネットワークサーバーで物事を分けておくことは非常に便利であることが証明されています。

— ジェレミーブーゼ2009年

すごい！私はこれが大好きです。

— バル

クライアントマシンごとに異なるUSBキーを使用していると思います。それ以外の場合、それらのすべてが同じ場所に保存されている場合、別々のキーのポイントは何ですか？違反が発生した場合は、それらすべてを取り消す必要があります。（そしておそらく）私が何かを逃さない限り、これは物事を複雑にするようです。

— ハリルÖzgür13年

@HalilÖzgür、はい、コンサルティングを行っていますが、常に同じキーを使用したいとは限りません。USBキーは暗号化されており、接続する必要がない限りコンピュータに接続されていないため、サーバーが侵害される心配はなく、ドライブファイルシステムを復号化するためのパスフレーズは十分に長く、キーを簡単に取り消すことができます。

— ジェレミーブーズ

6

秘密鍵は機密データであり、可能な限り少ない場所に保管するのが理にかなっているため、オプション1（オプション2であると思われるもの）の両方を削除します。個人的には、バックアップを作成する場合を除いて、あるコンピューターから別のコンピューターに（または同じコンピューター上の1つのファイルから別のファイルに）秘密キーをコピーすることはありません。ほとんどの暗号化キーとは異なりますが、SSHキーが失われても、それは世界の終わりではありません（新しいキーを作成するだけで、データは失われません）。

— デビッドZ
ソース

ええ、適切な「オプション2」に名前を変更しました「秘密鍵をコピーしない」というルールが好きです。それは良いルールです。

— 怠acyな

1

オプション3およびPuppetなどを使用してキー管理を処理します。

— diq
ソース

これはreductivelabs.com/trac/puppet/wiki/PuppetIntroduction Puppetへのリンクですか？

— アンディ

はい、それだけです。このサイトの例をいくつか確認してください。他の人がすでにやったことを確認するのに役立ちます-車輪を再発明する必要はありません。

— DIQ

1

オプション3。

これにより、クライアントがアクセスできるサーバーを制御することもできます。たとえば、クライアントXがサーバーAとBにアクセスする必要があるが、CまたはDにアクセスする必要がある場合、それらのホストのみに公開キーをコピーします。

— pgs
ソース