known_hosts ファイルは、クライアントがサーバーを認証して、偽装者に接続していないことを確認できるようにします。 authorized_keys ファイルは、サーバーがユーザーを認証できるようにします。
サーバー認証
SSH 接続が確立されたときに最初に行われることの 1 つは、サーバーがその公開鍵をクライアントに送信し、(公開鍵暗号化のおかげで) 関連付けられた秘密鍵を知っていることをクライアントに証明することです。これにより、サーバーが認証されます。プロトコルのこの部分が成功した場合、クライアントは、サーバーが主張している人物であることを認識します。
クライアントは、サーバーが既知のサーバーであり、正しいサーバーとして偽装しようとしている不正なサーバーではないことを確認する場合があります。 SSH は、サーバーの正当性を検証するための単純なメカニズムのみを提供します:~/.ssh/known_hosts で、既に接続したサーバーを記憶します。 クライアント マシン上のファイル (システム全体のファイル /etc/ssh/known_hosts もあります) ）。サーバーに初めて接続するときは、サーバーから提示された公開鍵が実際に接続したいサーバーの公開鍵であることを別の方法で確認する必要があります。接続しようとしているサーバーの公開鍵を持っている場合は、それを ~/.ssh/known_hosts に追加できます
ところで、known_hosts DSA (RSA および ECDSA も含む) だけでなく、SSH 実装でサポートされている任意のタイプの公開鍵を含めることができます。
サーバーに機密データを送信する前に、サーバーの認証を行う必要があります。特に、ユーザー認証にパスワードが含まれる場合、認証されていないサーバーにパスワードを送信してはなりません。
ユーザー認証
サーバーは、そのユーザーがそのアカウントにアクセスする権利を持っていることを証明できる場合にのみ、リモート ユーザーのログインを許可します。サーバーの構成とユーザーの選択に応じて、ユーザーはいくつかの形式の資格情報のいずれかを提示できます (以下のリストはすべてを網羅しているわけではありません)。
- ユーザーは、ログインしようとしているアカウントのパスワードを提示できます。次に、サーバーはパスワードが正しいことを確認します。
- ユーザーは公開鍵を提示し、その公開鍵に関連付けられた秘密鍵を所有していることを証明できます。これは、サーバーの認証に使用される方法とまったく同じですが、ユーザーは身元を証明しようとしており、サーバーはそれを検証しています。ユーザーが秘密鍵を知っていて、公開鍵がアカウントの認証リスト (
~/.ssh/authorized_keys) にあることを証明した場合、ログイン試行は受け入れられます - 別のタイプの方法では、ユーザーの認証作業の一部をクライアント マシンに委任します。これは、多くのマシンが同じアカウントを共有する企業などの制御された環境で発生します。サーバーは、逆に使用されるのと同じメカニズムによってクライアント マシンを認証し、クライアントに依存してユーザーを認証します。
これらの 2 つのファイルはどちらも SSH で使用されますが、目的がまったく異なるため、混乱するのは簡単です。
認証キー
デフォルトでは、SSH はホスト OS によって管理されるユーザー アカウントとパスワードを使用します。 (実際には PAM によって管理されていますが、その区別はおそらくここではあまり役に立ちません。) これが意味することは、ユーザー名 'bob' とパスワードを使用して SSH に接続しようとすると、SSH サーバー プログラムが OS に「私はパスワードが「wonka」だと言っている「ボブ」という男を捕まえました。彼を入れてもいいですか？答えが「はい」の場合、SSH で認証が可能になり、思い通りに進むことができます。
パスワードに加えて、SSH では公開鍵暗号と呼ばれるものを使用してユーザーを識別することもできます。特定の暗号化アルゴリズムはさまざまですが、通常は RSA または DSA、最近では ECDSA です。いずれにせよ、キーを設定するときは ssh-keygen を使用します プログラムでは、2 つのファイルを作成します。 1 つは秘密鍵で、もう 1 つは公開鍵です。名前はかなり自明です。設計上、公開鍵は風になびくタンポポの種のようにまき散らされても、ユーザーを危険にさらすことはありません。秘密鍵は常に厳重に保管する必要があります。
したがって、公開鍵を authorized_keys に配置するだけです ファイル。次に、ユーザー名 'bob' と秘密鍵を使用して SSH に接続しようとすると、OS に「私はこの男の名前 'bob' を取得しました。ここにいることができますか?」と尋ねます。答えが「はい」の場合、SSH は秘密鍵を検査し、公開鍵が authorized_keys に含まれているかどうかを確認します。 file はそのペアです。両方の答えが「はい」の場合、入室が許可されます。
既知のホスト
authorized_keys のように ファイルは known_hosts のユーザーを認証するために使用されます ファイルは、サーバーの認証に使用されます。 SSH が新しいサーバーで構成されている場合は常に、ユーザーに対して行ったのと同じように、サーバーの公開キーと秘密キーが常に生成されます。 SSH サーバーに接続するたびに、対応する秘密鍵を所有しているという証明と共に、公開鍵が表示されます。公開鍵を持っていない場合、コンピューターはそれを要求し、それを known_hosts に追加します。 ファイル。キーがあり、それが一致する場合は、すぐに接続します。キーが一致しない場合は、厄介な警告が表示されます。ここからが興味深いところです。キーの不一致が通常発生する 3 つの状況は次のとおりです。
どちらの場合も、known_hosts と authorized_keys 、SSH プログラムは、クライアントまたはサーバーを識別するために公開鍵暗号を使用しています。
公開鍵を含む安全なファイルについて
「known_hosts」と「authorized_keys」がどのように異なるかを理解するのに役立つように、これらのファイルが「ssh」にどのように適合するかを説明するコンテキストを次に示します。これは単純化しすぎています。 「ssh」には、ここで述べたよりも多くの機能と複雑さがあります。
協会は信頼できる情報源にあります
公開鍵の値は「風にそよぐ種のように安全にまき散らすことができる」と言われていますが、どの種が庭に定着するかを決定するのは種の鞘ではなく庭師であることに注意してください。公開鍵は秘密ではありませんが、鍵が認証しているものと鍵との信頼できる関連付けを維持するには、強力な保護が必要です。この関連付けを行うために委託された場所には、「known_hosts」、「authorized_keys」、および「Certificate Authority」のリストが含まれます。
「ssh」が使用する信頼できるソース
公開鍵を「ssh」に関連させるには、鍵を事前に登録し、適切な安全なファイルに保存する必要があります。 (この一般的な真実には重要な例外が 1 つあります。これについては後で説明します。) サーバーとクライアントはそれぞれ、安全に格納された独自の公開鍵のリストを持っています。ログインは、それぞれの側が他方に登録されている場合にのみ成功します。
- 「known_hosts」はクライアントにあります
- 「authorized_keys」はサーバー上にあります
クライアントのセキュア ファイルは「known_hosts」と呼ばれ、サーバーのセキュア ファイルは「authorized_keys」と呼ばれます。これらのファイルは、それぞれが行ごとに 1 つの公開鍵を含むテキストを含むという点で似ていますが、形式と使用法に微妙な違いがあります。
認証には鍵ペアが使用されます
公開鍵と秘密鍵のペアは、「非対称暗号化」を実行するために使用されます。 「ssh」プログラムは、認証に非対称暗号を使用できます。この場合、エンティティは身元を証明するためにチャレンジに答える必要があります。チャレンジは、1 つのキーでエンコードすることによって作成され、もう 1 つのキーでデコードすることによって回答されます。 (非対称暗号化はログイン段階でのみ使用されることに注意してください。その後、「ssh」(TSL/SSL) は別の形式の暗号化に切り替えてデータ ストリームを処理します。)
サーバー用のキーペアとクライアント用のキーペア
「ssh」では、両側（クライアントとサーバー）が他方を疑っています。これは、「ssh」の前身である「telnet」からの改良です。 「telnet」では、クライアントはパスワードを提供する必要がありましたが、サーバーは精査されていませんでした。審査の欠如により、「中間者」攻撃が発生し、セキュリティに壊滅的な結果をもたらしました。対照的に、「ssh」プロセスでは、サーバーが最初にチャレンジに応答するまで、クライアントは情報を引き渡しません。
「ssh」認証の手順
ログイン情報を共有する前に、「ssh」クライアントはまずサーバーに「あなたは本当に私が思っている人ですか?」と証明するよう要求することで、中間者攻撃の機会を排除します。このチャレンジを行うには、クライアントはターゲット サーバーに関連付けられている公開鍵を知っている必要があります。クライアントは、「known_hosts」ファイルでサーバーの名前を見つける必要があります。関連する公開鍵は、サーバー名の後の同じ行にあります。 server-name と public-key の間の関連付けは、違反しないようにしておく必要があります。したがって、「known_hosts」ファイルのパーミッションは 600 でなければなりません。他の誰も書き込みも読み取りもできません。
サーバーが認証されると、クライアントにチャレンジする機会が与えられます。認証には、「authorized_keys」にある公開鍵の 1 つが含まれます。 (これらのキーがどれも機能しない場合、「sshd」プロセスはパスワード形式の認証にフォールバックします。)
ファイル形式
したがって、「ssh」の場合、他のログイン プロセスと同様に、「フレンド」のリストがあり、リストに載っている人だけがチャレンジに合格することができます。クライアントの場合、「known_hosts」ファイルは、サーバー (ホスト) として機能できる友人のリストです。これらは名前でリストされています。サーバーの場合、同等の友人リストは「authorized_keys」ファイルです。ただし、公開鍵自体が識別子のように機能するため、そのファイルには名前がありません。 (サーバーはログインがどこから来ているかは気にしませんが、どこに行くかだけを気にします。クライアントは特定のアカウントにアクセスしようとしています。アカウント名は、「ssh」が呼び出されたときにパラメーターとして指定されました。「authorized_keys " ファイルはそのアカウントのホーム ディレクトリの下にあるため、そのアカウントに固有のものです。)
構成エントリで表現できる機能は多数ありますが、基本的で最も一般的な使用法には、次のパラメーターがあります。パラメータはスペース文字で区切られていることに注意してください。
「known_hosts」の場合:
{server-id} ssh-rsa {public-key-string} {comment}
"authorized_keys" の場合:
ssh-rsa {public-key-string} {comment}
トークン ssh-rsa に注意してください エンコードに使用されるアルゴリズムが「rsa」であることを示します。他の有効なアルゴリズムには、「dsa」と「ecdsa」があります。したがって、別のトークンが ssh-rsa の代わりになる場合があります
「ssh」で「known_hosts」エントリを自動構成する
どちらの場合も、公開鍵が安全なファイル内に見つからない場合、非対称暗号化は行われません。前述のとおり、この規則には例外が 1 つあります。ユーザーは、ユーザーの「known_hosts」ファイルにリストされていないサーバーにログインすることにより、中間者攻撃の可能性を意図的に選択することができます。 「ssh」プログラムはユーザーに警告しますが、ユーザーが先に進むことを選択した場合、「ssh」クライアントは「これだけ」それを許可します。確実に一度だけ発生するようにするために、「ssh」プロセスはサーバーに公開鍵を要求し、それを「known_hosts」ファイルに書き込むことによって、必要な情報で「known_hosts」ファイルを自動的に構成します。この例外は、敵対者がサーバー名と公開鍵の関連付けを提供できるようにすることで、セキュリティを完全に覆します。このセキュリティ リスクは許容されます。もちろん、正しく安全な方法は、ユーザーがサーバーにログインする前に、サーバー名と公開鍵を含む行を「known_hosts」ファイルに手動で挿入することでした。 (しかし、リスクの低い状況では、余分な作業は無意味かもしれません。)
一対多の関係
クライアントの「known_hosts」ファイルのエントリには、サーバーの名前と、サーバー マシンに適用可能な公開鍵が含まれています。サーバーには、すべてのチャレンジに回答するために使用される単一の秘密鍵があり、クライアントの「known_hosts」エントリには、一致する公開鍵が必要です。したがって、特定のサーバーにアクセスするすべてのクライアントは、「known_hosts」ファイルに同一の公開鍵エントリを持ちます。 1:N の関係は、サーバーの公開鍵が多くのクライアントの「known_hosts」ファイルに現れる可能性があるということです。
「authorized_keys」ファイルのエントリは、フレンドリ クライアントがアカウントへのアクセスを許可されていることを示します。友人は、同じ公開鍵と秘密鍵のペアを使用して、複数の異なるサーバーにアクセスする可能性があります。これにより、これまでに接続したすべてのサーバーに対して単一のキー ペアを認証できます。標的となった各サーバー アカウントは、それぞれの「authorized_keys」ファイルに同一の公開鍵エントリを持っています。 1:N の関係は、1 つのクライアントの公開鍵が、複数のサーバー上の複数のアカウントの「authorized_keys」ファイルに表示されるということです。
複数のクライアント マシンで作業しているユーザーが、同じキー ペアを複製することがあります。通常、これは、ユーザーがデスクトップとラップトップで作業するときに行われます。クライアント マシンは同一のキーで認証されるため、サーバーの「authorized_keys」の同じエントリと一致します。
秘密鍵の場所
サーバー側では、システム プロセスまたはデーモンがすべての着信 "ssh" ログイン要求を処理します。デーモンの名前は「sshd」です。秘密鍵の場所は、SSL のインストールによって異なります。たとえば、Apple は /System/Library/OpenSSL に配置します。 ですが、独自のバージョンの OpenSSL をインストールすると、場所は /opt/local/etc/openssl になります。 .
クライアント側では、必要なときに「ssh」(または「scp」) を呼び出します。コマンドラインにはさまざまなパラメーターが含まれており、そのうちの 1 つで、使用する秘密鍵をオプションで指定できます。デフォルトでは、クライアント側の鍵ペアはしばしば $HOME/.ssh/id_rsa と呼ばれます および $HOME/.ssh/id_rsa.pub .
まとめ
要するに、"known_hosts" と "authorized_keys" の両方に公開鍵が含まれていますが、...
- known_hosts -- クライアントはホストが本物かどうかをチェックします
- authorized_keys -- クライアントのログインが許可されているかどうかをホストがチェックします