クライアント（コンピュータ3）は公開鍵にアクセスできます。

秘密鍵が混乱している可能性があります。文書秘密鍵を使用してください。

公開鍵と秘密鍵のペアを生成すると、ほとんどの実装は秘密鍵と公開鍵を含む秘密鍵ファイルを生成します。便宜上、多くの実装では公開鍵を別々のファイルに記録することもあります。

~によるとRFC 4252セクション7公開鍵は認証中にクライアントによって提供されます。したがって、顧客はこれを持っている必要があります。

opensshを使用すると、秘密鍵ssh-keygenファイルから公開鍵を抽出できます。

ssh-keygen -y -f ~/.ssh/id_rsa

認証メカニズム

https://www.rfc-editor.org/rfc/rfc4252#section-7

クライアントがログインしようとする前に可能許可されているものを確認することから始めてください。この確認には、使用可能な秘密鍵と一致する公開鍵を送信することが含まれ、サーバーは使用する公開/秘密鍵を表すことができます。

...署名操作には高価な計算が必要です。不要な処理やユーザーの対話を避けるために、「公開鍵」方式を使用した認証が許可されているかどうかを照会するために、次のメッセージが表示されます。

  byte      SSH_MSG_USERAUTH_REQUEST
  string    user name in ISO-10646 UTF-8 encoding [RFC3629]
  string    service name in US-ASCII
  string    "publickey"
  boolean   FALSE
  string    public key algorithm name
  string    public key blob

次にログインを試みます。

実際の認証を実行するために、クライアントは秘密
鍵を使用して生成された署名を送信できます。クライアントは、
まず鍵が
許可されていることを確認せずに署名を直接送信できます。署名は、次のパケットを使用して送信されます。

  byte      SSH_MSG_USERAUTH_REQUEST
  string    user name
  string    service name
  string    "publickey"
  boolean   TRUE
  string    public key algorithm name
  string    public key to be used for authentication
  string    signature

これには、公開鍵と秘密鍵を使用して生成された署名が含まれます。公開鍵は「認証鍵」が多いため、サーバーSSHに便利です。サーバーはすべての署名をテストする必要はありません。

いくつかの同様のアルゴリズムとは異なり、SSHは試行応答を使用しません。今正しいいいえステップ4（クライアントの起動1回、サーバーチャレンジ2回、クライアント署名3回、サーバー確認4回）を使用して2つのステップを実行します。

1. 顧客署名セッション識別子（つまり、以前に生成されたハッシュ値DHキー交換)
2. その後、サーバーは次のことを確認します。
   • 指定された公開鍵が許可されます（ユーザーの認証済み鍵のうち）。
   • セッション識別子を生成するために指定された公開鍵を使用して署名を復号化します。

なぜ一部の人々はこれについて混乱していますか？

公開 - 秘密鍵認証技術は、クライアントが公開鍵を保持する必要はありません。クライアントは秘密鍵を使用して署名を作成するだけです。サーバーは、一致する公開鍵を使用して署名を確認するだけです。

ただし、SSHを使用すると、クライアントは複数の秘密鍵を持つことができ、サーバーはユーザーが複数の認証された鍵を持つことができます。クライアントに10個のキーがあり、サーバーが10個のキーを受け入れるが、1対のみが一致する場合、クライアントは10個の署名を送信し、サーバーは10個のキーに対して各署名を確認する必要があります（合計100個の確認）。これは計算コストが高い。これとは対照的に、SSHは単一の署名検証だけで同じ状況を処理します。