Bitte beachten Sie, dass die PasswordAuthentication-Einstellung nicht ALLE passwortbasierten Authentifizierungen steuert. ChallengeResponseAuthentication fragt normalerweise auch nach Passwörtern.
PasswordAuthentication steuert die Unterstützung für das in RFC-4252 (Abschnitt 8) definierte „Kennwort“-Authentifizierungsschema. ChallengeResponseAuthentication steuert die Unterstützung für das in RFC-4256 definierte „keyboard-interactive“-Authentifizierungsschema. Theoretisch könnte das „Tastatur-interaktive“ Authentifizierungsschema einem Benutzer eine beliebige Anzahl von Fragen mit vielen Facetten stellen. In der Praxis wird oft nur nach dem Passwort des Benutzers gefragt.
Wenn Sie die kennwortbasierte Authentifizierung vollständig deaktivieren möchten, setzen Sie BEIDE PasswordAuthentication und ChallengeResponseAuthentication auf „no“. Wenn Sie Gürtel und Hosenträger denken, sollten Sie auch UsePAM auf 'no' setzen.
Die auf öffentlichen/privaten Schlüsseln basierende Authentifizierung (aktiviert durch die PubkeyAuthentication-Einstellung) ist eine separate Art der Authentifizierung, bei der natürlich keine Benutzerpasswörter an den Server gesendet werden.
Einige würden argumentieren, dass die Verwendung von ChallengeResponseAuthentication sicherer ist als PasswordAuthentication, da sie schwieriger zu automatisieren ist. Sie empfehlen daher, PasswordAuthentication deaktiviert zu lassen, während ChallengeResponseAuthentication aktiviert bleibt. Diese Konfiguration fördert auch (aber verhindert nicht notwendigerweise) die Verwendung der Publickey-Authentifizierung für alle automatisierten Systemanmeldungen. Da SSH jedoch ein netzwerkbasiertes Protokoll ist, hat der Server keine Möglichkeit zu garantieren, dass Antworten auf ChallengeResponseAuthentication (alias „keyboard-interactive“) tatsächlich von einem Benutzer bereitgestellt werden, der an einer Tastatur sitzt, solange die Challenge(s) immer bestehen und besteht nur darin, einen Benutzer nach seinem Passwort zu fragen.
Ihr Link verweist auf eine Dokumentation, die 10 Jahre veraltet ist.
SSH unterstützt mehrere Möglichkeiten, Benutzer zu authentifizieren, die häufigste ist die Abfrage eines Logins und eines Passworts, aber Sie können Benutzer auch mit einem Login und einem öffentlichen Schlüssel authentifizieren. Wenn Sie PasswordAuthentication auf no setzen, können Sie sich nicht mehr mit einem Login und Passwort authentifizieren und müssen stattdessen ein Login und einen öffentlichen Schlüssel verwenden (wenn PubkeyAuthentication auf yes gesetzt ist)
PasswordAuthentication ist die einfachste Implementierung, da nichts zu tun ist. Das Gegenstück ist, dass Sie Ihr Passwort über eine verschlüsselte Verbindung an den Server senden. Dies kann ein Sicherheitsproblem darstellen, wenn der Server kompromittiert wurde, da das Passwort dann erbeutet werden könnte.
Mit dem öffentlichen Schlüssel wird Ihr Passwort nicht an den Server übertragen, es ist sicherer, erfordert aber mehr Einrichtung.