web-dev-qa-db-ja.com

sshキーを管理するための最良のシステム？

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

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

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

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

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

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

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

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

完全に船外？

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

sshauthentication
42
slacy

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

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

オプション4はいいですが、やりすぎです。 オプションでは、98％が手間をかけずに得られます。

33
dwc

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

Linuxワークステーションでほぼ排他的に作業しているため、LUKS暗号化を使用してセットアップされたUSBキーがあり、XALウィンドウマネージャーと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式を使用して、リモートサーバーのユーザー名に固有のキーを探すことも、リモートサーバーの％hを探すこともできます。 ％uおよび％lのようなホスト名が使用されました。

更新：今、私は実際にssh-agent互換のGnuPG gpg-agentを使用して、OpenPGP v2スマートカードから認証キーを読み取って使用します。

26
Jeremy Bouse

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

6
David Z

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

1
diq

オプション3。

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

1
pgs