SSHキーベースの認証：known_hosts vs authorized_keys

Linuxでのsshキーのセットアップについて読んで、いくつか質問があります。間違っている場合は修正してください…

ホストtr-lgtoがsshを使用してホストtr-mdmに接続したいとします。それが実際のtr-mdmであることを確認したい場合は、tr-mdmでキーのペアを生成しknown_hosts、tr-lgtoで公開キーを追加します。tr-mdmがそれが実際のtr-lgtoであることを確認したい場合、tr-lgtoはキーペアを生成し、authorized_keystr-mdmに公開鍵を追加する必要があります。

質問1：ファイルknown_hostsにはユーザーフィールドはなく、IPアドレスとホスト名のみがあります。tr-mdmには多くのユーザーがいて、それぞれに独自の.sshフォルダーがあります。各known_hostsファイルに公開鍵を追加する必要がありますか？

質問2：ssh-keyscan -t rsa tr-mdmtr-mdmの公開キーが返されることがわかりました。このキーがどのユーザーに属しているかを知るにはどうすればよいですか？さらに、公開キーは、/root/.ssh/そのコマンドが返すものとは異なります。どうすればいいの？

サーバーマシンの認証とクライアントマシン、およびユーザーの認証とサーバーマシンを混同しています。

サーバー認証

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

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

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

ユーザ認証

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

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

友達が答えてくれました。デフォルトでは、キーはユーザーではなくマシンを識別します。そのため、キーは/ etc / ssh /に保存されます。それが、/ root / .sshに保存されているキーとは異なるキーを取得した理由です