序章

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

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

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

このガイドでは、サーバーをユーザーに対して検証するためにmonkeysphereをセットアップする方法について説明します。 これにより、ユーザーが接続しているサーバーが実際にアクセスしようとしているサーバーであるかどうかを推測する必要があるという問題が解決されます。 通常、サーバーに初めて接続すると、次のようなものが表示されます。

The authenticity of host '107.170.43.127 (107.170.43.127)' can't be established.
ECDSA key fingerprint is 10:14:75:d6:42:a3:c5:59:d1:83:6d:cf:52:61:4a:52.
Are you sure you want to continue connecting (yes/no)?

この記事では、これらのメッセージがユーザーに表示されないようにします。 今後のガイドでは、ユーザーの簡単な識別と認証の問題を解決する方法について説明します。

このシステムを構成するには、Ubuntu12.04VPSインスタンスを使用します。 ユーザーに対して検証を試みるSSHサーバーがあります。 また、デモンストレーション用に他の2台のマシンが必要です(ローカルコンピューターまたはVPSインスタンス)。 1つは管理者のコンピューターで、もう1つはクライアントであり、信頼のWebによってサーバーのIDを検証できるかどうかを確認するためのテストマシンとして使用します。

基本戦略

モンキースフィアシステム全体は、GPGキーとキーサーバーに依存して機能します。 開始する前に、システムごとにこれらのキーを構成する必要があります。 実際の構成の多くは、これらのキーを介して行われます。

GPGの使用を開始する前に、GPGキーの使用方法に関する記事を参照することをお勧めします。 必要な特定のコマンドを提供しますが、何が起こっているのかをより深く理解することで、問題が発生した場合のトラブルシューティングに役立つ場合があります。

3台のマシンとその用途は次のとおりです。

  • server.example.com :クライアントに対して検証するSSHサーバー。
  • admin.example.com :アクセスの構成に使用する管理者コンピューター。 これは通常、自宅のコンピューターですが、ガイドでは別のドロップレットを使用します。
  • client.example.com :これは、検証をテストするために使用するクライアントです。 不明なホストの警告を受信せずに、このコンピューターがサーバーに接続できるようにする必要があります。

SSHサーバーマシンには、公的にアクセス可能なドメイン名が必要です。 このガイドを使用して、DigitalOceanでドメイン名を設定します。

最初の部分では、管理者コンピューターとクライアントコンピューターの両方でキーを生成します。 次に、これらのキーを一元化されたキーサーバーにアップロードします。 キーサーバーから管理者のキーをプルダウンし、クライアントキーを使用して署名および信頼します。これは、クライアントが管理者を信頼していることを示します。

これが検証スキーム全体の基礎です。 コンピューターやキーを信頼する代わりに、GPGのWebofTrustモデルを活用しています。 接続しようとしているサーバーについて知識が豊富で信頼できる人と見なす場合は、その人に任せて、サーバーが正当であるかどうかを知らせることができます。 この場合、クライアントはサーバー管理者がサーバーのIDを検証できることを信頼します。

次に、GPGフレームワークを使用して情報をプルダウンし、信頼できる管理者が接続しようとしているサーバーの保証を保証するように、monkeysphereを構成できます。

GPGキーと認証を設定する

幸い、GPGはデフォルトでUbuntuにインストールされています。

まず、クライアントシステムと管理者のシステムの両方でいくつかのGPGキーを作成します。 これらのキーは単一のユーザーに関連付けられており、そのユーザーをグローバルに識別するために使用されます。 SSHサーバーへのアクセスが必要な各ユーザーは、それらを識別するGPGキーを持っている必要があります。 これが私たちが信頼の網を構築する方法です。

GPGキーの生成

クライアントマシンと管理マシンの両方でGPGキーを作成する必要があります。 これらのコンピューターの両方で次のアクションを実行します。

gpg --gen-key

これにより、キーペアを作成するためのいくつかの質問が表示されます。 まず、作成するキーのタイプを尋ねます。 「1」を選択して、2つのRSAキーを作成します。 次の質問のデフォルト値を受け入れて、2048ビットのキーを作成します。 「0」を選択してキーが自動的に期限切れにならないようにし、「Y」と入力して情報が正しいことを確認します。

次に、これらの各ユーザーの情報を求められます。 管理者のキーには、名前「admin」とメールアドレス「admin @fakedomain.com」を使用します。 クライアントには、「client」という名前と「client @fakedomain.com」というメールアドレスを使用します。 オプションのコメントを追加する機会があります。次に、「O」と入力して、情報に問題がないことを示します。

キーを保護するためのパスフレーズを入力して確認します。

コンピュータは、システムから収集されたランダムなデータを使用してキーを作成します。 これは「エントロピー」と呼ばれ、真にランダムなキーを作成するために使用されます。 しばらく時間がかかる場合があります。 プロセスを高速化するために、別のSSHセッションでログインして作業を行うと役立つ場合があります。

キーが生成されると、GPGキーリング内に保存されます。 次のように入力すると表示されます。

 gpg --list-keys
  /root/.gnupg/pubring.gpg

pub 2048R / 08D014B32014-03-14uidクライアント @fakedomain .com> sub 2048R / 4C73683E 2014-03-14

上記の赤い部分は短縮キーIDです。 このハッシュを使用して、このキーを参照できます。

キーをキーサーバーにアップロードする必要があります。 これらのキーサーバーは世界中で複製されており、誰でも私たちの重要な情報を引き出すことができます。 これは、2人のユーザーとSSHサーバーが相互に対話し、信頼関係を確立できるようにするために必要なものです。

キーをキーサーバーにアップロードするには、クライアントコンピューターと管理コンピューターで次のように入力する必要があります。 上記のキーIDが必要になります。

gpg --send-key key_id

したがって、上記のクライアントキーの場合、次のように入力して、これをキーサーバーにアップロードできます。

gpg --send-key 08D014B3

キーに署名する

管理者とクライアントの両方がGPGキーを持ち、それらをキーサーバーにアップロードしたので、それらは世界中の他のキーサーバーに伝播し始めます。 各キーが世界中のGPGサーバーにコピーされるまでに時間がかかる場合があるため、これらの手順が機能するまで数分待つ必要がある場合があります。

数分待った後、各コンピューターの反対側のキーを引き下げてみることができます。 これは、クライアントコンピューターで、管理者のキーをプルダウンしようとすることを意味します。 また、管理者コンピューターのクライアントキーをプルダウンする必要があります。

これらのキーに署名します。つまり、これらのキーは有効であると見なし、識別しようとしている人物にとって正しいキーであることを確認しました。 正しいキーを確実に取得するために、検索せずに、正確なキーを指紋で識別して指定することにより、これを実行します。

クライアントサーバーで、これを入力してGPGキーのフィンガープリントを取得します。 「クライアント」は、キーを作成するときに選択した名前またはメールアドレスです。

 gpg --with-colons --fingerprint client
  tru :: 1:1394819815:0:3:1:5 pub:u:2048:1:4B3F73E208D014B3:2014-03-14 ::: u:client   @fakedomain  .com> :: scESC:fpr ::::::::: 85ECDB498FB0CAB5F02989E64B3F73E208D014B3 :sub:u:2048:1:254105194C73683E:2014-03-14 :::::: e:

上で強調表示されている出力の部分は、探している指紋です。

管理者のコンピューターでこのフィンガープリントを取得したので、次のように、そのフィンガープリントを持つキーを探してローカルコンピューターにプルダウンするようにGPGに指示できます。

gpg --recv-keys 85ECDB498FB0CAB5F02989E64B3F73E208D014B3

これにより、デフォルトのキーサーバーに接続し、そのフィンガープリントで識別されるキーを要求します。 ローカルシステムに転送されます。

キーにアクセスできるようになったので、署名して、管理者としてクライアントに属するキーを信頼していることを示すことができます。

gpg --sign-key 85ECDB498FB0CAB5F02989E64B3F73E208D014B3

これで、ローカルシステムのキーに署名しました。 ここで、クライアントのキーをキーサーバーに送り返す必要があります。 キーサーバーは、クライアントキーの情報を更新して、管理者アカウントがキーに署名し、それが有効であると見なしていることを示します。

署名されたキーをキーサーバーに送り返すには、次のように入力します。

gpg --send-key 85ECDB498FB0CAB5F02989E64B3F73E208D014B3

キーサーバーには、以前と同じように、管理者のキーとクライアントのキーがあります。 違いは、キーサーバーにも、クライアントキーの管理者キーからの署名があることです。

ここで反対の操作を行う必要があります(管理者のキーにクライアントのキーで署名します)。 これを行うために、管理者のマシンで、管理者キーのフィンガープリントを取得します。

gpg --with-colons --fingerprint admin

これで、クライアントマシンで、以前と同じように、出力から収集したフィンガープリントを使用して、管理者のキーをプルダウン、署名、およびアップロードします。

gpg --recv-keys 7C873BB244245CB13BFEFC31F7C66E2FF945A061
gpg --sign-key 7C873BB244245CB13BFEFC31F7C66E2FF945A061
gpg --send-key 7C873BB244245CB13BFEFC31F7C66E2FF945A061

その後、両方のマシンで、キーを更新する必要があります。 これは、各ユーザーが自分のキーに署名しているが、自分のコンピューターではなく、反対側のコンピューターとキーサーバーにその署名がないためです。 ここで数分待って変更を反映させてから、次のように入力します。

gpg --refresh-keys

更新が処理されたことを確認する必要があります。 出力には、「新しい署名:1」という行が含まれている必要があります。 これが存在しない場合は、表示されるまで再試行してください。

これで、各コンピューターに両方の署名付きキーが必要になります。

管理者の判断を信頼する

私たちの信頼の網が実際に機能するためには、クライアントに管理者の鍵に署名させるだけでなく、クライアントが管理者の判断を「信頼」することを確立する必要があります。

これは、管理者がSSHサーバーがマシンであると言った場合、クライアントとして、管理者である別の人が作成した署名を信頼できることを意味します。

まず、次のように入力して、クライアントの現在の設定を確認できます。

gpg --check-trustdb

gpg: 3 marginal(s) needed, 1 complete(s) needed, PGP trust model
gpg: depth: 0  valid:   1  signed:   1  trust: 0-, 0q, 0n, 0m, 0f, 1u
gpg: depth: 1  valid:   1  signed:   0  trust: 1-, 0q, 0n, 0m, 0f, 0u

これは非常に紛らわしい情報のセットです。 最初の行は、私たちが運用している信頼モデルを示しています。 基本的に、完全に信頼できる1人のユーザーによって署名されたキーがある場合、そのキーも有効であると見なされます。 わずかに信頼している3人以上の人が署名していれば、キーを信頼することもできます。

2行目は、「深さ0」の信頼レベルについて示しています。 これは基本的に私たち自身の鍵に関する情報です。 有効で署名されていると見なします。 また、「信頼」の部分は、キーが「u」カテゴリにあり、最終的に信頼できることを意味します。

3行目は、「深さ1」のキーについて説明しています。 これらは私たちが個人的に署名した鍵です。 1つのキーが有効であると見なし(管理者キーに署名して有効にした)、管理者キーが気になる追加のキーに署名していないことがわかります。

その行の信頼セクションには、「1-」のフィールドがあります。 これは、このレベルで持っている1つのキー(管理者キー)に信頼設定が与えられていないことを意味します。 このキーにどのレベルの信頼を置くべきかわかりません。

管理者キーを完全に信頼したいと思います。 このように、管理者が署名するすべてのキー(IDを確認しようとしているSSHサーバーなど)は、正当であると見なされます。 これを行うには、次のように入力して、クライアントマシンの信頼データベースを更新できます。

gpg --update-trustdb

署名したキーのうち、現在信頼値がないキーに信頼度を割り当てるように求められます。 次のようになります。

gpg: 3 marginal(s) needed, 1 complete(s) needed, PGP trust model
gpg: depth: 0  valid:   1  signed:   1  trust: 0-, 0q, 0n, 0m, 0f, 1u
No trust value assigned to:
2048R/49E95F19 2014-03-14
      "admin <[email protected]>"
 Primary key fingerprint: A612 56B8 5307 B7ED 9AD8  D93E 9E06 881E 49E9 5F19

Please decide how far you trust this user to correctly verify other users' keys
(by looking at passports, checking fingerprints from different sources, etc.)

  1 = I don't know or won't say
  2 = I do NOT trust
  3 = I trust marginally
  4 = I trust fully
  s = skip this key
  q = quit

Your decision?

このキーを完全に信頼したいので、「4」と入力します。

これで、管理者の判断を信頼できるため、管理者が署名したキーが問題のユーザーまたはサービスに合法的に関連付けられていることを合理的に確信できます(通常、クライアントや管理者の代わりに本名を使用します)。

Monkeysphereをインストールし、SSHサーバーを構成します

クライアントと管理者のコンピューターにGPGキーが設定されたので、実際のmonkeysphereのインストールと構成を開始できます。

Ubuntuのデフォルトリポジトリにはmonkeysphereパッケージがあります。 SSHが検証にGPGを使用するために必要なサーバーユーティリティとクライアントユーティリティの両方が含まれています。 そのため、各コンピューターにパッケージをインストールする必要があります。

このモデルのすべてのコンピューター(管理者、クライアント、SSHサーバー)に、次のように入力してmonkeysphereをインストールします。

sudo apt-get update
sudo apt-get install monkeysphere

これで、これらの部品を組み合わせるために必要なコンポーネントができました。 SSHサーバーでは、monkeysphereに含まれているラッパーユーティリティを使用して特別なGPGキーを生成します。 生成されたキーは、 ssh_host_rsa_key これは、クライアントに対してサーバーを識別するために使用されます。

SSHサーバーで、次のように入力します。

Monkeysphere-ホストインポートキー/etc/ ssh / ssh_host_rsa_key ssh:// server.example.com

上記の2番目のコンポーネントは、SSHサーバーのドメインを示している必要があります。 これは、クライアントがサーバー接続を確認しようとするときに正しいサーバーキーを見つけるのに役立ちます。

これで、作成したキーをパブリックキーサーバーに再度アップロードできます。 今回も、monkeysphereスイートに含まれているラッパープログラムを使用します。

monkeysphere-host publish-key

これにより、サーバーキーがアップロードされ、接続を希望するクライアントが利用できるようになります。

サーバー管理者としてのサーバーキーの検証

これで、SSHサーバーのキーが世界中のキーサーバーに伝播されました。 しかし、これはどのように役立ちますか?

ええと、GPGが機能する方法は、GPGが「信頼の網」と呼ぶものを確立することです。 簡単に言えば、それはあなたが知っていて、その身元を高い確実性で確認できる人々の個人的なネットワークを確立することによって機能します。 次に、それらの信頼関係を使用して、情報を知る責任を信頼できる人に任せることができます。

私たちの場合、(この例のクライアントとして)私たちは、サーバーが正当であるかどうかを知る責任を、信頼できる管理者に任せています。 サーバーの管理者は、サーバーの資格情報がチェックアウトされているかどうかを把握している必要があります。

したがって、ここで行う必要があるのは、サーバー管理者としてSSHサーバーのGPGキーに署名することです。これにより、クライアントユーザーは、管理者を信頼してサーバーのIDを確認できます。

SSHサーバーで、次のように入力してGPGフィンガープリントを取得します。

monkeysphere-host show-key

pub   2048R/0D281337 2014-03-14
uid                  ssh://fakedomain.com
OpenPGP fingerprint: E06A426459E584F272DB708AD2D462790D281337
ssh fingerprint: 2048 61:1e:a7:66:1d:04:64:80:3f:27:81:34:31:78:8d:df (RSA)

「OpenPGPフィンガープリント」は、GPGフィンガープリントと同じです。 これは、管理者のコンピューターのキーをプルダウンして署名するために使用するものです。

管理者のコンピューターで、これを入力してSSHサーバーのキーを取得します。 繰り返しますが、数分待つ必要があるかもしれません。

gpg --recv-key E06A426459E584F272DB708AD2D462790D281337

上記のクライアントキーで行ったのと同じように、キーに署名します。

gpg --sign-key E06A426459E584F272DB708AD2D462790D281337

最後に、署名されたキーをキーサーバーにアップロードすることを忘れないでください。

gpg --send-key E06A426459E584F272DB708AD2D462790D281337

クライアントからのSSHサーバーのIDの確認

これで、クライアントコンピューターからSSHサーバーのIDを検証するためのすべての準備が整いました。

これを行うには、SSHコマンドをmonkeysphereユーティリティでラップする必要があります。 これにより、sshを実行しようとしているサーバーのGPGキーをチェックするためにmonkeysphereを使用するようにクライアントに指示されます。 次に、サーバーが有効であることを確認した人を信頼するかどうかを確認します。

何が起こっているかを示すために、これを初めて手動で行います。 その後、これをファイルに追加して、これを自動的に行うことができます。

クライアントで、次のように手動コマンドを入力します。

 ssh -oProxyCommand ='monkeysphere ssh-proxycommand%h%p' server.example .com
  --------------------Monkeysphereの警告-------------------Monkeysphereは、このホスト名のOpenPGPキーを検出しましたが、完全な有効性を持ったものはありませんでした。 ホストによって提供されたsshキーと一致するOpenPGPキーが見つかりました:

pub 2048R / 0D281337 2014-03-14 uid[不明]ssh://server.example.com sig!3 0D281337 2014-03-14 ssh://fakedomain.com RSAキーの指紋は61:1e:a7:66: 1d:04:64:80:3f:27:81:34:31:78:8d:df。

--------------------sshは以下に続きます--------------------ホストの信頼性' server.example.com (( )'を確立できません。 ECDSAキーのフィンガープリントは78:50:80:60:2a:a3:51:51:37:9d:25:8b:d4:0c:d1:15です。 接続を続行してもよろしいですか(はい/いいえ)?

ここに「no」と入力します。

ご覧のとおり、接続しようとしているホストの信頼性を確立できないという通常のメッセージがあります。 この問題はまだ修正されておらず、サーバーのIDも確認されていないため、間違ったホストに接続しないように「no」と入力する必要があります。

ただし、「Monkeyspherewarning」セクションヘッダーの下に追加の情報セクションも表示されています。 キーを取得できたが、必要な信頼関係がなかったため、サーバーを検証できなかったことがわかります。

クライアントコンピューターのキーチェーン内のキーを見ると、SSHサーバーのキーがあることがわかります。

gpg --list-keys

/root/.gnupg/pubring.gpg
------------------------
pub   2048R/87791BD0 2014-03-14
uid                  client &lt;[email protected]&gt;
sub   2048R/3294D31D 2014-03-14

pub   2048R/54AD641F 2014-03-14
uid                  admin &lt;[email protected]&gt;
sub   2048R/A87CADCB 2014-03-14

pub   2048R/0D281337 2014-03-14
uid                  ssh://fakedomain.com

これで、システムに鍵ができました。 ここで、キーを更新する必要があります。 これにより、システム内のキーの署名が取得されます。

gpg --refresh-keys

new signatures: 1」。 これは、SSHサーバーのキーで使用可能な署名を確認することで確認できます。

 gpg --list-sigs ssh:// server.example.com
  pub 2048R / 0D281337 2014-03-14 uid ssh://server.example.com sig 3 0D281337 2014-03-14 ssh://server.example.com sig 54AD641F 2014-03-14 admin   @fakedomain  .com>

ご覧のとおり、管理者のキーを一覧表示する「sig」行が表示されます。 クライアントは管理者を信頼しているため、プロキシによってSSHサーバーを信頼できるようになりました。

コマンドをもう一度試してみましょう。

ssh -oProxyCommand='monkeysphere ssh-proxycommand %h %p' server.example.com

[email protected]'s password:

ご覧のとおり、SSHサーバーの有効性を確認するように求められることなく、パスワードプロンプトが表示されます。 これは、GPGを介してそのIDを確認したためです。

サーバーにSSHで接続するたびにこの長いコマンドを入力する必要がないように、クライアントコンピューターの構成ファイルに次のコマンドを追加します。

nano ~/.ssh/config

Host *
ProxyCommand monkeysphere ssh-proxycommand %h %p

これにより、通常どおりSSHを介して接続できるようになり、すべてのモンキースフィアの検証がバックグラウンドで実行されます。

ssh server.example.com

これが機能していることを再確認するには、現在のファイルを削除してください known_hosts ファイル:

rm ~/.ssh/known_hosts

ここで、sshコマンドを再試行します。

ssh server.example.com

ログインするか、パスワードの入力を求められます。ホストを受け入れるかどうかを尋ねられることはありません。 また、 known_hosts ファイルが自動的に再作成され、そのホストが追加されました。

cat ~/.ssh/known_hosts

server.example.com ssh-rsa AAAB3NzaC1yc2EAAAADAQABAAABAQC9aTHZmHZSgwNtwichF0AqDI74bCMtI29kqPDZaNn2r86NGIElRUlQiRImmZXs5oEjF0o8VaW6s1cIj0hC5ziDPShJ3VzZTWz9RmJ9xfPPcAPw2JbV1c1Q1bplstQqCZmFcRZyofztnP55HqOiJ4htLMxH+a9lM4AydDZtGHhzU+usxUjHniVbxCUVntpunlwtMk+Mtk9eysVdnJCJyV02/W89HExiO9QRpv+EugKN1eCQYrGvNbKWQKq4gSJ0RDwOSKNgkY/Ii0MsGJ2HuioO9np6IEdeZdgSGHPA23+zZe8asrN62iLUBADDkyIR6FAonCvfh99hbFxpNz2N8Mdb MonkeySphere2014-03-21T21:30:44

結論

SSHにmonkeysphereを使用するように組織を構成する場合、SSHユーザーは組織内のホストの正当性を疑う必要はありません。 ユーザーがサーバー管理者を信頼し、monkeysphereに依存するようにSSHを構成し、管理者が新しいホストへの署名に注意を払っていると仮定すると、ユーザーにホストIDの確認を求められることはありません。

ホストを有効なものとして盲目的に受け入れることは大きなリスクであり、ほとんどのユーザーは、管理者の助けなしにサーバーのIDを合法的にチェックする機能を持っていません。 したがって、Monkeysphereを使用すると、組織全体の安全のために、このプロセス全体を切り取ることができます。

これは大変な作業のように思えるかもしれませんが、信頼ネットワークを設定する作業は少なくなり、危険な中間者攻撃を回避できるようになります。

次の記事では、monkeysphereを使用してSSHサーバーに対してユーザーを検証する方法について説明します。

ジャスティン・エリングウッド