PasswordAuthentication 設定は、すべてのパスワードベースの認証を制御するわけではないことに注意してください。 ChallengeResponseAuthentication は通常、パスワードも要求します。
PasswordAuthentication は、RFC-4252 (セクション 8) で定義されている「パスワード」認証スキームのサポートを制御します。 ChallengeResponseAuthentication は、RFC-4256 で定義されている「キーボード インタラクティブ」認証スキームのサポートを制御します。 「キーボードインタラクティブ」認証スキームは、理論的には、ユーザーに多面的な質問をいくつでもすることができます。実際には、ユーザーのパスワードのみを要求することがよくあります。
パスワードベースの認証を完全に無効にする場合は、PasswordAuthentication と ChallengeResponseAuthentication の両方を「no」に設定します。ベルトとサスペンダーの考え方をお持ちの場合は、UsePAM を「いいえ」に設定することも検討してください。
公開/秘密鍵ベースの認証 (PubkeyAuthentication 設定で有効化) は、もちろんサーバーへのユーザー パスワードの送信を伴わない別個のタイプの認証です。
自動化が難しいため、ChallengeResponseAuthentication を使用する方が PasswordAuthentication よりも安全であると主張する人もいます。したがって、ChallengeResponseAuthentication を有効のままにして、PasswordAuthentication を無効のままにすることをお勧めします。この構成は、自動化されたシステム ログインに公開鍵認証を使用することも推奨します (ただし、必ずしも防止するわけではありません)。しかし、SSH はネットワークベースのプロトコルであるため、サーバーは ChallengeResponseAuthentication (別名「キーボード インタラクティブ」) への応答が実際にキーボードの前に座っているユーザーによって提供されていることを保証する方法がありません。ユーザーにパスワードを尋ねるだけです。
あなたのリンクは、10 年前のドキュメントを指しています。
SSH はユーザーを認証する複数の方法をサポートしています。最も一般的な方法は、ログインとパスワードを要求することですが、ユーザーをログインと公開鍵で認証することもできます。 PasswordAuthentication を no に設定すると、認証にログインとパスワードを使用できなくなり、代わりにログインと公開鍵を使用する必要があります (PubkeyAuthentication が yes に設定されている場合)
PasswordAuthentication は、何もする必要がないため、最も簡単な実装です。反対の部分は、暗号化された接続を介してサーバーにパスワードを送信することです。サーバーが侵害された場合、パスワードが取得される可能性があるため、これはセキュリティ上の問題になる可能性があります。
公開鍵を使用すると、パスワードはサーバーに送信されません。より安全ですが、より多くの設定が必要です。