ステータス:非推奨

この記事では、サポートされなくなったバージョンのUbuntuについて説明します。 現在Ubuntu12.04を実行しているサーバーを運用している場合は、サポートされているバージョンのUbuntuにアップグレードまたは移行することを強くお勧めします。

理由:
Ubuntu 12.04は2017年4月28日に保守終了(EOL)に達しました and no longer receives security patches or updates. This guide is no longer maintained.

代わりに参照してください:このガイドは参照として役立つ場合がありますが、他のUbuntuリリースでは機能しない場合があります。 可能な場合は、使用しているUbuntuのバージョン用に作成されたガイドを使用することを強くお勧めします。 ページ上部の検索機能を使用して、より新しいバージョンを見つけることができます。

序章

多くのユーザーがいる大量のサーバーを構成する場合、インフラストラクチャに合わせてSSHアクセスを維持することは複雑になる可能性があります。 LDAPなど、一元化された認証機関を実装する方法はかなりありますが、これらはやり過ぎになることがあります。

SSHには、実際には認証局を使用してサーバーとクライアントを認証する機能があります。 これは両方の方法で機能します。 このシステムを使用すると、ホストをクライアントに対して認証でき、ホストの信頼性を検証できないという混乱を招くメッセージを回避できます。 また、クライアントをホストに対して検証して、新しいSSHキーを1つの場所に登録し、組織全体にアクセスできるようにすることもできます。

上記の両方の方法でこれらの証明書を活用する方法について説明します。 これを3つのUbuntu12.04VPSインスタンスでデモします。 1つはホストとして機能し、もう1つはクライアントとして機能し、3つ目は認証局として機能します。

ホスト証明書を構成する方法

まず、サーバーをクライアントに対して認証する証明書を構成します。 これにより、クライアントはサーバーの信頼性を疑うことなくサーバーに接続できます。

認証局として使用するマシンから始めます。 この例では、これを「auth.example.com」と呼びます。

署名キーの生成

まず、署名キーとして機能するRSAキーを生成する必要があります。 任意のユーザーを使用しますが、rootユーザーはおそらく良い考えです。 「server_ca」および「server_ca.pub」というキーを作成します。これらはサーバーの認証に使用されるためです。

これらのキーをホームディレクトリに作成しましょう。

cd ~
ssh-keygen -f server_ca

パスフレーズを作成するかどうかを尋ねられます。 これにより、キーが悪意のある人の手に渡った場合に備えて、キーに追加の保護レイヤーが追加されます。 これが完了すると、ホームディレクトリに秘密鍵と公開鍵が作成されます。

ls

server_ca   server_ca.pub

ホストキーへの署名

キーができたので、ホストキーへの署名を開始できます。

まず、認証局自体のホストキーに署名する必要があります。 これは、次の構文を使用して実行できます。

ssh-keygen -s signing_key -I key_identifier -h -n host_name -V + 52w host_rsa_key

これが何を意味するのかを見ていきましょう。

  • -s :これは、他のすべての鍵に署名するために使用する、先ほど作成した秘密鍵です。
  • -I :これは証明書を識別するために使用される名前です。 証明書が認証に使用される場合、ログ記録の目的で使用されます。
  • -h :これにより、結果の証明書がクライアントキーではなく、ホストキーとしてマークされます。
  • -n :これは、この証明書に関連付けられている名前(ユーザーまたはホスト)を識別するために使用されます。
  • -V :証明書の有効期間を指定します。 この場合、証明書は1年(52週間)で期限切れになることを指定します。

その後、署名するキーを指定します。

この場合、独自のホストRSAキーに署名するために、次のような行を使用します。 このサーバーを「host_auth_server」として識別します。 署名鍵の作成時に使用したパスフレーズの入力を求められます。

ssh-keygen -s server_ca -I host_auth_server -h -n auth.example.com -V +52w /etc/ssh/ssh_host_rsa_key.pub

Signed host key /etc/ssh/ssh_host_rsa_key-cert.pub: id "host_auth_server" serial 0 for auth.example.com valid from 2014-03-20T12:25:00 to 2015-03-19T12:26:05

出力からわかるように、私たちの証明書は1年間有効です。 サーバーホストキー(/etc/ssh/)と同じディレクトリに作成されており、「ssh_host_rsa_key-cert.pub」と呼ばれます。

認証局自体でホストキーに署名したので、クライアントに対して認証しようとしている別のSSHサーバーのホストキーに署名できます。

SSHサーバーからホストキーをコピーします。 このマシンを「sshserver.example.com」と呼びます。 scpを使用してこれを行うことができます。

cd ~
scp [email protected]:/etc/ssh/ssh_host_rsa_key.pub .

これで、上記で使用したのと同じ方法を使用して、このファイルから証明書を作成できます。 署名する新しいホストを参照するために、いくつかの値を変更する必要があります。

ssh-keygen -s server_ca -I host_sshserver -h -n sshserver.example.com -V +52w ssh_host_rsa_key.pub

Signed host key ssh_host_rsa_key-cert.pub: id "host_sshserver" serial 0 for sshserver.example.com valid from 2014-03-20T12:40:00 to 2015-03-19T12:41:48

次に、生成された証明書ファイルをホストにコピーして戻す必要があります。 繰り返しますが、これにはscpを使用できます。

scp ssh_host_rsa_key-cert.pub [email protected]:/etc/ssh/

その後、SSHサーバーの公開鍵と証明書の両方を認証サーバーから削除できます。

rm ssh_host_rsa_key.pub ssh_host_rsa_key-cert.pub

これで署名付き証明書が配置されました。これらを使用するようにコンポーネントを構成する必要があります。

ホスト証明書を使用するためのコンポーネントの構成

まず、両方のサーバー(auth.example.comsshserver.example.com)を続行して、作成した証明書ファイルを認識させる必要があります。

これらのマシンの両方で、メインのSSHデーモン構成ファイルを編集する必要があります。 ssh_configファイルではなく、sshd_configファイルを編集していることを確認してください。

sudo nano /etc/ssh/sshd_config

HostCertificate行が見つかった場合は、それを変更します。 それ以外の場合は、これをファイルの最後に追加します。 ホスト証明書ファイルへのパスを確立する必要があります。

HostCertificate /etc/ssh/ssh_host_rsa_key-cert.pub

終了したら、ファイルを保存して閉じます。

次に、SSHデーモンを再起動して、次の変更を行います。

sudo service ssh restart

これは、ホスト証明書を構成するすべてのサーバーで実行します。

これで、サーバーは証明書を使用するように構成されましたが、クライアントはサーバーが提示する証明書を確認する方法を知りません。

client.example.com」と呼ぶクライアントマシンで、「~/.ssh/known_hosts」ファイルを開くか作成します。

nano ~/.ssh/known_hosts

証明書エントリ用に構成しているサーバーに関係するエントリをすべて削除する必要があります。 すべてを削除するのが最善かもしれません。

その後、ログイン時にホストから提供される証明書を確認するために使用する公開鍵を指定する特別なエントリを追加する必要があります。 @cert-authorityから始めます。 その後、キーが適用されるドメイン制限と、それに続いてすべてに署名している公開認証局キーを含めることができます。

認証局のマシンで、次のように入力して公開証明書署名キーを取得できます。

cat ~/server_ca.pub

ssh-rsa AAAAB3NzaC1yc2EAAAADAQABAAABAQCxC+gikReZlWEnZhKkGzhcNeRD3dKh0L1opw4/LQJcUPfRj07E3ambJfKhX/+G4gfrKZ/ju0nanbq+XViNA4cpTIJq6xVk1uVvnQVOi09p4SIyqffahO9S+GxGj8apv7GkailNyYvoMYordMbIx8UVxtcTR5AeWZMAXJM6GdIyRkKxH0/Zm1r9tsVPraaMOsKc++8isjJilwiQAhxdWVqvojPmXWE6V1R4E0wNgiHOZ+Wc72nfHh0oivZC4/i3JuZVH7kIDb+ugbsL8zFfauDevuxWeJVWn8r8SduMUVTMCzlqZKlhWb4SNCfv4j7DolKZ+KcQLbAfwybVr3Jy5dSl root@auth

この情報を使用すると、~/.ssh/known_hostsファイルの行は次のようになります。

@cert-authority *.example.com ssh-rsa AAAAB3NzaC1yc2EAAAADAQABAAABAQCxC+gikReZlWEnZhKkGzhcNeRD3dKh0L1opw4/LQJcUPfRj07E3ambJfKhX/+G4gfrKZ/ju0nanbq+XViNA4cpTIJq6xVk1uVvnQVOi09p4SIyqffahO9S+GxGj8apv7GkailNyYvoMYordMbIx8UVxtcTR5AeWZMAXJM6GdIyRkKxH0/Zm1r9tsVPraaMOsKc++8isjJilwiQAhxdWVqvojPmXWE6V1R4E0wNgiHOZ+Wc72nfHh0oivZC4/i3JuZVH7kIDb+ugbsL8zFfauDevuxWeJVWn8r8SduMUVTMCzlqZKlhWb4SNCfv4j7DolKZ+KcQLbAfwybVr3Jy5dSl root@auth

完了したら、ファイルを保存して閉じます。

これで、クライアントから(完全なホスト名を使用して)SSHサーバーに初めてアクセスするときに、リモートホストを信頼するかどうかを尋ねられることはありません。 これは、ホストが認証局によって署名されたホスト証明書を提示したためです。 known_hostsファイルをチェックし、証明書が正当であることを確認しました。

ユーザーキーを構成する方法

ユーザーに対してサーバーを認証する方法を学習したので、サーバーに対してユーザーを認証するように認証局を構成することもできます。

以前と同様に、このプロセスは認証局サーバーで開始されます。 今回は、ユーザー証明書に署名するために、新しいキーのセットを生成する必要があります。

ssh-keygen -f users_ca

繰り返しますが、パスフレーズを選択して、誰かがアクセスした場合にキーが保護されるようにします。

ユーザー認証を使用してログインを受け入れるようにサーバーを構成する

完了したら、ユーザーの信頼性を検証する必要がある各SSHサーバーに公開鍵をコピーする必要があります。 これは、通常どおりscpを使用して行います。

scp users_ca.pub [email protected]:/etc/ssh/

このキーを探すには、SSHサーバーのSSHデーモン構成を変更する必要があります。

sshserver.example.com」ホストで、構成ファイルを開きます。

sudo nano /etc/ssh/sshd_config

下部のHostCertificate行の下に、コピーしたファイルを参照する別の行を追加する必要があります。

TrustedUserCAKeys /etc/ssh/users_ca.pub

繰り返しますが、これらの変更を行うには、SSHデーモンを再起動する必要があります。

sudo service ssh restart

ユーザーログインキーへの署名

users_caキーによって署名されたキーを信頼するようにサーバーが構成されたので、このスキームが機能するように、実際にユーザーの認証キーに署名する必要があります。

まず、scpを使用してクライアントキーを認証局サーバーに取得する必要があります。 証明書サーバーから、次のように入力します。

 cd〜scpユーザー名 @クライアント .example.com:/ home /username/.ssh/id_rsa.pub

証明書マシンにキーがあるので、users_caキーを使用して署名できます。 これは、前回server_caキーを使用してキーに署名したときと非常によく似ていますが、-hパラメーターはユーザーキーであるため、ここでは含まれていません。

必要なコマンドは次のようなものです。 管理を容易にするために、署名するユーザーの名前を反映するように「username」の値を変更します。

 ssh-keygen -s users_ca -I user_ username -n username -V + 52w id_rsa.pub
 署名されたユーザーキーid_rsa-cert.pub:2014-03-20T14:45:00から2015-03-19T14:46:52まで有効なユーザー名のID「user_username」シリアル0

キーの作成中に設定されたusers_caパスフレーズの入力を求められます。 これで、ディレクトリにid_rsa-cert.pubファイルがあり、クライアントマシンに転送する必要があります。

 scpid_rsa-cert.pubユーザー名 @クライアント .example.com:/ home / username /.ssh/

これで、クライアントコンピューターからsshserver.example.comにログインするときに、このユーザーとしてこのサーバーにログインしたことがない場合でも、認証の詳細を尋ねられることはありません。

結論

ホストキーとユーザーキーに署名することで、ユーザーとサーバーの検証のためのより柔軟なシステムを作成できます。 これにより、サーバーをユーザーに対して検証し、ユーザーをサーバーに対して検証するために、インフラストラクチャ全体に対して1つの集中管理機関を設定できます。

一元化された認証を作成する最も強力な方法ではないかもしれませんが、多くの時間と構成を必要とせずに、セットアップと既存のツールの活用が簡単です。 また、証明書を確認するためにCAサーバーがオンラインである必要がないという利点もあります。

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