web-dev-qa-db-ja.com

SSHのauthorized_keysファイルとknown_hostsファイルの違いは何ですか？

SSHプロトコルの基礎を学んでいます。次の2つのファイルの内容が混同されています。

  1. ~/.ssh/authorized_keys：サーバーの承認済み公開鍵のリストを保持します。クライアントがサーバーに接続すると、サーバーはこのファイル内に保存されている署名済みの公開鍵をチェックしてクライアントを認証します

  2. ~/.ssh/known_hosts：ユーザーがアクセスするSSHサーバーのDSAホストキーが含まれます。このファイルは、SSHクライアントが正しいSSHサーバーに接続していることを確認するために非常に重要です。

どういう意味かわかりません。助けてください。

authenticationlinuxssh
190
Ankit

known_hostsファイルを使用すると、クライアントはサーバーを認証して、なりすましに接続していないことを確認できます。 authorized_keysファイルを使用すると、サーバーでユーザーを認証できます。

サーバー認証

SSH接続が確立されているときに最初に起こることの1つは、サーバーがその公開鍵をクライアントに送信し、（ public-key cryptography のおかげで）クライアントが関連する秘密鍵。これによりサーバーが認証されます。プロトコルのこの部分が成功した場合、クライアントはサーバーが本人であることを認識します。

クライアントは、サーバーが既知のサーバーであって、正しいサーバーとして偽装しようとしている不正なサーバーではないことを確認する場合があります。 SSHは、サーバーの正当性を確認するための単純なメカニズムのみを提供します。クライアントマシンの~/.ssh/known_hostsファイルに、すでに接続しているサーバーを記憶します（システム全体のファイル/etc/ssh/known_hostsもあります）。サーバーに初めて接続するときは、他の方法で、サーバーから提示された公開鍵が実際に接続したいサーバーの公開鍵であることを確認する必要があります。接続しようとしているサーバーの公開鍵がある場合は、クライアントの~/.ssh/known_hostsに手動で追加できます。

ちなみに、known_hostsには、DSAだけでなく（RSAやECDSAも）、SSH実装でサポートされている任意のタイプの公開鍵を含めることができます。

機密データをサーバーに送信する前に、サーバーの認証を行う必要があります。特に、ユーザー認証にパスワードが含まれる場合、そのパスワードを認証されていないサーバーに送信しないでください。

ユーザ認証

サーバーは、リモートユーザーがそのアカウントにアクセスする権限を持っていることを証明できる場合にのみ、リモートユーザーのログインを許可します。サーバーの構成とユーザーの選択に応じて、ユーザーはいくつかの形式の資格情報の1つを提示する場合があります（以下のリストは完全ではありません）。

  • ユーザーは、ログインしようとしているアカウントのパスワードを提示できます。次に、サーバーはパスワードが正しいことを確認します。
  • ユーザーは公開鍵を提示し、その公開鍵に関連付けられた秘密鍵を所有していることを証明できます。これは、サーバーの認証に使用される方法とまったく同じですが、ユーザーは自分の身元を証明しようとし、サーバーはそれを確認しています。ログインの試みは、ユーザーが秘密鍵を知っていて、公開鍵がアカウントの認証リスト（サーバー上の~/.ssh/authorized_keys）にあることを証明した場合に受け入れられます。
  • 別のタイプの方法には、ユーザーを認証する作業の一部をクライアントマシンに委任することが含まれます。これは、多くのマシンが同じアカウントを共有する企業などの制御された環境で発生します。サーバーは、逆の方法で使用されるのと同じメカニズムでクライアントマシンを認証し、クライアントに依存してユーザーを認証します。
199
Gilles 'SO- stop being evil'

これら2つのファイルは両方とも [〜＃〜] ssh [〜＃〜] によって使用されますが、完全に異なる目的で使用されているため、混乱を簡単に説明できます。

承認済みキー

デフォルトでは、SSHはホストOSによって管理されるユーザーアカウントとパスワードを使用します。 （まあ、実際には [〜＃〜] pam [〜＃〜] によって管理されますが、この区別はおそらくここではあまり役に立ちません。）これが意味することユーザー名「bob」とパスワードを使用してSSHに接続しようとすると、SSHサーバープログラムはOSに「bob」という名前の人にパスワードが「wonka」であると教えてくれます。 ？」答えが「はい」の場合、SSHを使用すると認証が可能になり、楽に進みます。

パスワードに加えて、SSHは、いわゆる 公開鍵暗号 を使用してユーザーを識別できるようにします。特定の暗号化アルゴリズムはさまざまですが、通常はRSAまたは [〜＃〜] dsa [〜＃〜] 、またはより最近のもの [〜＃〜] ecdsa [〜＃〜] 。いずれの場合も、 ssh-keygen プログラムを使用してキーを設定すると、2つのファイルが作成されます。 1つは秘密鍵で、もう1つは公開鍵です。名前はかなり自明です。設計により、公開鍵はあなたを危険にさらすことなく、風の中でタンポポの種のように散らばることができます。秘密鍵は常に最も厳格な秘密にしておく必要があります。

つまり、公開鍵をauthorized_keysファイルに配置します。次に、ユーザー名「bob」と秘密鍵を使用してSSHに接続しようとすると、OSに「この人の名前「bob」を取得しました、ここにいることができますか？」答えが「はい」の場合、SSHは秘密鍵を検査し、authorized_keysファイルの公開鍵がそのペアであるかどうかを確認します。両方の回答が「はい」の場合、許可されます。

既知のホスト

authorized_keysファイルを使用してユーザーを認証する方法と同様に、known_hostsファイルを使用してサーバーを認証します。新しいサーバーでSSHが構成されると、ユーザーに対して行ったのと同じように、常にサーバーの公開鍵と秘密鍵が生成されます。 SSHサーバーに接続するたびに、対応する秘密鍵を持っていることの証明とともに、公開鍵が表示されます。公開鍵がない場合は、コンピューターから要求され、known_hostsファイルに追加されます。キーがあり、一致する場合は、すぐに接続します。キーが一致しない場合、大きな厄介な警告が表示されます。ここが面白いところです。キーの不一致が通常発生する3つの状況は次のとおりです。

  1. サーバーでキーが変更されました。これは、 [〜＃〜] os [〜＃〜] を再インストールした場合や、一部のOSでは、SSHの更新時にキーが再作成される場合があります。
  2. 接続先のホスト名またはIPアドレスが別のサーバーに属していた。これは、アドレスの再割り当て、 [〜＃〜] dhcp [〜＃〜] 、または類似したものである可能性があります。
  3. 悪意のある man-in-the-middle攻撃 が発生しています。これは、キーチェックがあなたを守ろうとしている最大のことです。

known_hostsとauthorized_keysのどちらの場合でも、SSHプログラムは公開鍵暗号を使用して、クライアントまたはサーバーのいずれかを識別します。

37
Scott Pack

公開鍵を含む安全なファイルについて

「known_hosts」と「authorized_keys」の違いを理解するために、これらのファイルが「ssh」にどのように適合するかを説明するいくつかのコンテキストを次に示します。これは過度に単純化されています。 「ssh」には、ここで説明されているよりも多くの機能と複雑な機能があります。

関連付けは信頼できるソースにあります

公開鍵の値は「風の中で種のように安全にまき散らされる可能性がある」と言われていますが、どの種を庭に設置するかを決定するのは種鞘ではなくガードナーであることを覚えておいてください。公開キーは秘密ではありませんが、キーが認証しているものとの信頼されたキーの関連付けを維持するには、強力な保護が必要です。この関連付けを委託する場所には、「known_hosts」、「authorized_keys」、「Certificate Authority」のリストが含まれます。

「ssh」が使用する信頼できるソース

公開鍵を「ssh」に関連付けるには、事前に鍵を登録し、適切な安全なファイルに保存する必要があります。 （この一般的な真実には1つの重要な例外があります。これについては後で説明します。）サーバーとクライアントはそれぞれ、安全に保存された独自の公開キーのリストを持っています。ログインは、それぞれの側がもう一方に登録されている場合のみ成功します。

  • 「known_hosts」はクライアント上にあります
  • 「authorized_keys」はサーバーに常駐します

クライアントのセキュアファイルは「known_hosts」と呼ばれ、サーバーのセキュアファイルは「authorized_keys」と呼ばれます。これらのファイルは、1行に1つの公開鍵を含むテキストを持っているという点で似ていますが、形式と使用法に微妙な違いがあります。

キーペアは認証に使用されます

公開鍵と秘密鍵のペアは、「非対称暗号化」を実行するために使用されます。 「ssh」プログラムは、認証に非対称暗号を使用できます。エンティティは、そのアイデンティティを証明するためにチャレンジに回答する必要があります。チャレンジは、1つのキーでエンコードすることで作成され、もう1つのキーでデコードすることで回答されます。 （非対称暗号法はログイン段階でのみ使用されることに注意してください。「ssh」（TSL/SSL）は、データストリームを処理するために別の形式の暗号化に切り替えます。）

サーバー用のキーペアとクライアント用のキーペア

「ssh」では、両側（クライアントとサーバー）が他方を疑っています。これは、「telnet」であった「ssh」の前身を改善したものです。 「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」クライアントは「これだけ」を許可します。これが1回だけ行われることを保証するために、「ssh」プロセスは、サーバーに公開鍵を要求し、それを「known_hosts」ファイルに書き込むことによって、「known_hosts」ファイルに必要な情報を自動的に構成します。この例外は、攻撃者がサーバー名と公開鍵の関連付けを提供できるようにすることで、セキュリティを完全に覆します。このセキュリティリスクは、非常に多くの人々にとって物事を非常に簡単にするため、許可されています。もちろん、正しく安全な方法は、ユーザーがサーバーにログインする前に、サーバー名と公開鍵を含む行を「known_hosts」ファイルに手動で挿入することでした。 （ただし、リスクの低い状況では、追加の作業は無意味な場合があります。）

1対多の関係

クライアントの「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-ホストは、クライアントログインが許可されているかどうかを確認します
1
IAM_AL_X