序章

組織が成長するにつれて、多数のSSHキーとサーバーを管理することは非常に困難になる可能性があります。 組織全体で有効なキーを正しく識別し、無効なキーを削除すると、エラーが発生し、サーバーのセキュリティに大きな影響を与える可能性があります。

さらに、サーバーが変更された場合、サーバーの信頼性を確立できないという警告がユーザーに表示されることがあります。 ほとんどのユーザーは、接続する前にサーバーのキーフィンガープリントを再確認しないため、誰かがサーバーを偽装して中間者攻撃を実行する可能性があります。

これらの問題に対処するために、monkeysphereというプロジェクトが作成されました。 これは、GPGキーとWeb of Trustモデルを活用して、サーバーの資格情報を検証し、ユーザー管理を容易にすることで実現します。

以前のガイドでは、ユーザーに対してサーバーを検証するためにmonkeysphereをセットアップする方法について説明しました。 このガイドで中断したところから続行します。ここでは、GPGキーとサーバー管理者のこれらのユーザーへの信頼のみに基づいて、サーバーに対してユーザーを自動的に認証する方法を学習します。 これにより、ほとんど暗号化された情報ではなく、平易な英語を使用する認証ファイルを作成できるようになります。

このガイドは、前のガイド( server.example.com admin.example.com client.example)で中断したセットアップがあることを前提としています。 com と必要な信頼関係が確立されています)。 始めましょう。

SSHサーバー上にID証明書を作成する

SSHサーバーがサーバーに対してユーザーを自動的に認証できるようにするための最初のステップは、識別認証機能を確立することです。 ID証明書は、ユーザーのIDを確立する際に信頼できると指定している人物です。

ほとんどの場合、単純で論理的な選択は、サーバー管理者にログインできるユーザーを識別させることです。 このルートに行きます。 状況によってその責任の分散が必要な場合は、複数のID認証者を作成することもできます。

管理ユーザーの指紋をもう一度取得することから始めましょう。 管理者のコンピューターでは、前回のガイドで使用したのと同じGPGコマンドを使用して、完全なフィンガープリントを取得できます。

gpg --with-colons --fingerprint [email protected]

ここでも、次のような出力行を探しています。

fpr ::::::::: A61256B85307B7ED9AD8D93E9E06881E49E95F19

赤で強調表示されているセクションは、ここで必要なものです。

SSHサーバー( server.example.com )で、このキーをID証明書として追加します。 これを行うには、次のように入力します。

 Monkeysphere-authentication add-identity-certifier A61256B85307B7ED9AD8D93E9E06881E49E95F19 

次に、Monkeysphereは一致するGPG情報をキーサーバーから取得し、それを独自のキーリングに保存します。 このキーは、他のユーザーのIDを確認できるキーとしてマークされます。

SSHユーザーの認証サブキーを生成する

サーバー管理者が正当なユーザーを識別できることを確認したので、クライアント側で少し作業を行う必要があります。

各クライアントは、実際の認証に使用されるGPGサブキーを生成する必要があります。 公開GPGキーはユーザーを識別するために使用されますが、サブキーは実際のログイン手順に使用されます。

monkeysphereコマンドには、認証サブキーを簡単に生成できるサブコマンドが含まれています。 クライアントで、次のように入力します。

monkeysphere gen-subkey

サブキーが生成され、メインキーの下のローカルGPGキーリングに追加されます。

SSHサーバーがこのサブキーを使用して問題のユーザーの内部認証ファイルを生成できるように、キーの変更をキーサーバーに再度アップロードする必要があります。 公開する必要のあるキーは、サブキーの変更を含むメインキーです。 重要な情報を取得するには、次のように入力します。

 gpg--list-keysクライアント @fakedomain  .com
  pub 2048R / 87791BD02014-03-14uidクライアント  @fakedomain