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

サーバー認証

SSH接続が確立されているときに最初に発生することの1つは、サーバーがその公開鍵をクライアントに送信し、証明することです。 （公開鍵暗号化のおかげで）関連付けられた秘密鍵を知っていることをクライアントに通知します。これによりサーバーが認証されます。プロトコルのこの部分が成功すると、クライアントは、サーバーが本人であると主張していることを知っています。

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

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

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

ユーザー認証

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

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

コメント

• これは非常に役立ちます。 know_hostsファイルはクライアントで維持され、authorized_keyファイルはサーバーで維持されると言うのは正しいです
• @Ankitはい。
• サーバーに両方のファイルがあります。しかし、2つのファイルの内容は異なります。したがって、これらのファイルのキーは異なりますか？
• @Timoキーは完全にunrです。大喜び。 1つはマシンのキーで、もう1つはユーザーのキーです。
• @Gillesしたがって、サーバーのエントリ’が追加されるとクライアント’のマシンの known_hosts ファイルに対して、2つの間の後続のsshセッションは’ tサーバーが正しい秘密鍵を持っていることを証明する必要がありますか？

これら2つのファイルは、どちらもによって使用されます。 SSH ですが、目的がまったく異なるため、混乱を簡単に説明できます。

承認済みキー

デフォルトでは、SSHはホストOSによって管理されるユーザーアカウントとパスワードを使用します。 （実際には PAM によって管理されていますが、この区別はおそらくここではあまり役に立ちません。）これは、ユーザー名でSSHに接続しようとしたときに意味します。 「bob」とSSHサーバープログラムがOSに尋ねるパスワード”パスワードが「wonka」であると言っている「bob」という名前の男を見つけました。彼を入れてもいいですか？”答えが「はい」の場合、SSHを使用すると認証が可能になり、楽しい道を進むことができます。

パスワードに加えてSSHまた、公開鍵暗号化と呼ばれるものを使用してユーザーを識別できます。特定の暗号化アルゴリズムはさまざまですが、通常はRSAまたは DSA 、または最近では ECCSA 。いずれの場合も、キーを設定するときは、 ssh-keygen プログラムでは、2つのファイルを作成します。1つは秘密鍵で、もう1つは公開鍵です。名前はかなり自己です-説明。設計上、公開鍵は、妥協することなく、タンポポの種のように風にまき散らすことができます。秘密鍵は、常に極秘に保管する必要があります。

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

既知のホスト

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

1. サーバーでキーが変更されました。これは、 OS を再インストールするか、一部のOSではSSHの更新時にキーが再作成されることが原因である可能性があります。
2. 接続しているホスト名またはIPアドレス以前は別のサーバーに属していました。これは、アドレスの再割り当て、 DHCP 、または同様のものである可能性があります。
3. 悪意のある man-中間者攻撃が発生しています。これは、キーチェックがユーザーを保護しようとしている最大のことです。

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

コメント

• ” SSHサーバーに接続するたびに、そのIDを証明するために秘密鍵が提示されます。”絶対にそうしないことを望んでいます。 その公開鍵を意味していると思います。サーバーが私に提示した場合、クライアントはその秘密鍵を持っています-それは（A）’私がそれを認証するために機能せず、（B）サーバーがそうであることを示していますすぐに取引をやめるべきだという設定が間違っていた。秘密鍵は、指定されたユーザーのみが元のマシンでアクセスできる必要があります。その’はちょっとポイントです。 😉
• この回答は、受け入れられた回答よりも役に立ちました（：
• ローカルサーバー（ローカルIP）にSSHで接続し、後で同じコンピューターからリモートに接続した場合同じサーバー（パブリックIP）に接続すると、キーの不一致がトリガーされますか？これをどのように軽減できますか？

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

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

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

公開鍵の値は「風の種のように安全に散らばることができる」と言われていますが、それは「庭に植えるシードを決定するシードポッドではなくガードナー公開鍵は秘密ではありませんが、鍵と認証されているものとの信頼できる関連付けを維持するには、強力な保護が必要です。場所この関連付けの作成を委託されているのは、「known_hosts」、「authorized_keys」、「CertificateAuthority」のリストです。

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

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

• “known_hosts”はclieに存在しますnt
• 「authorized_keys」はサーバー上にあります

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

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

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

サーバー用の1つのキーペア、別のキーペアクライアントの場合

「ssh」では、両側（クライアントとサーバー）が他方を疑っています。これは、「telnet」であった「ssh」の前身を改良したものです。 「telnet」では、クライアントはパスワードを提供する必要がありましたが、サーバーは精査されませんでした。審査が行われなかったため、「man-in-the-middle」攻撃が発生し、セキュリティに壊滅的な結果をもたらしました。対照的に、「ssh」プロセスでは、サーバーが最初にチャレンジに応答するまで、クライアントは情報を提供しません。

「ssh」認証の手順

ログイン情報を共有する前に、 「ssh」クライアントは、最初にサーバーに「あなたは本当にあなたが誰だと思うのか」を証明するように要求することにより、中間者攻撃の機会を排除します。この課題を作成するには、クライアントはターゲットサーバーに関連付けられている公開鍵を知っている必要があります。クライアントは「known_hosts」ファイルでサーバーの名前を見つける必要があります。関連付けられた公開鍵はサーバー名の後の同じ行にあります。サーバー名と公開鍵の間の関連付けは侵害されないようにする必要があります。したがって、 「known_hosts」ファイルは600である必要があります。他の誰も書き込み（読み取りも読み取りもできません）。

サーバーが認証されると、クライアントにチャレンジする機会が与えられます。認証には公開鍵の1つが含まれます- 「authorized_keys」にあるキー（これらのキーのいずれも機能しない場合、「sshd」プロセスはパスワードスタイルの認証にフォールバックします。）

ファイル形式

「 ssh」は、他のログインプロセスと同様に、「友達」のリストがあり、リストにある人だけがチャレンジの通過を試みることができます。クライアントの場合、「known_hosts」ファイルは、として機能できる友達のリストです。サーバー（ホスト）;これらは名前でリストされます。サーバーの場合、同等の友達リストは「authorized_keys」ファイルですが、公開鍵なので、そのファイルには名前がありません。 cキー自体は識別子のように機能します。 （サーバーはログインの送信元を気にせず、どこに移動するかだけを気にします。クライアントが特定のアカウントにアクセスしようとしているため、「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」ファイルにリストされていないサーバーにログインすることにより、man-in-the-middle攻撃の可能性を危険にさらすことを故意に選択できます。「ssh」プログラムはユーザーに警告しますが、ユーザーが先に進むことを選択した場合、「ssh」クライアントは「これを1回だけ」許可します。これが1回だけ発生することを保証するために、「ssh」プロセスはサーバーに要求することにより、必要な情報を含む「known_hosts」ファイルを自動的に構成します。この例外は、攻撃者がサーバー名と公開鍵の関連付けを提供できるようにすることで、セキュリティを完全に破壊します。このセキュリティリスクは、事態を大幅に悪化させるため、許容されます。もちろん、ユーザーがサーバーにログインしようとする前に、server-nameとpublic-keyの行を「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-ホストはクライアントのログインが許可されているかどうかを確認します

コメント

• SSHクライアントは通常’キーがありません。 authorized_keysにリストされている公開鍵は、マシンではなくユーザーを識別します。
• ありがとうございます。これは、ファイルとキーの関係についての非常に明確でわかりやすい説明です。

まったく当てはまりません。

known_hostsファイルにはホストのフィンガープリントが含まれています。リモートホストの公開鍵または秘密鍵ではありません。

キーから生成されますが、キー自体ではありません。

次のアドレスにSFTPを使用する場合複数の（さまざまな）ホスト（負荷分散など）に解決される可能性があります。可能なすべてのエンドポイントからフィンガープリントを追加する必要があります。そうしないと、最初は機能し、2番目（または後続）のホストにルーティングされると失敗します。

コメント

• ermはknown_hostsファイルを確認し、接続時にホストのフィンガープリントと比較します。これで少しクリアになるはずです。さらに、known_hostsファイルの指紋または公開鍵であるかどうかに関係なく、例はまったく同じになります。