SSH キーベースの認証: known_hosts と authorized_keys

SSH キーベースの認証: known_hosts と authorized_keys

Linux で SSH キーを設定する方法について読みましたが、いくつか質問があります。間違っていたら訂正してください…

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

質問1: ありませんユーザーファイル known_hosts のフィールドには、IP アドレスとホスト名だけが記載されています。tr-mdm には多数のユーザーがいて、それぞれに独自の.sshフォルダーがある可能性があります。各ファイルに公開キーを追加する必要がありますかknown_hosts?

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

答え1

サーバー マシンからクライアント マシンへの認証と、サーバー マシンへのユーザーの認証が混同されています。

サーバー認証

SSH接続が確立されるときに最初に起こることの1つは、サーバーがクライアントに公開鍵を送信し、(公開鍵暗号) をクライアントに送り、関連する秘密鍵を知っていることを伝えます。これによりサーバーが認証されます。プロトコルのこの部分が成功すると、クライアントはサーバーが自分が偽っている人物であることを認識します。

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

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

ユーザ認証

サーバーは、リモート ユーザーがそのアカウントにアクセスする権限があることを証明できる場合にのみ、そのユーザーのログインを許可します。サーバーの構成とユーザーの選択に応じて、ユーザーは複数の形式の資格情報のいずれかを提示できます (以下のリストはすべてを網羅しているわけではありません)。

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

答え2

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

関連情報