Auf dieser Seite finden Sie die folgenden Erklärungen:
Die Option PasswordAuthentication gibt an, ob die kennwortbasierte Authentifizierung verwendet werden soll. Aus Sicherheitsgründen muss diese Option immer auf yes gesetzt sein.
Es werden jedoch keine Anwendungsszenarien bereitgestellt, die verdeutlichen, wann ein Ja oder Nein angemessen wäre. Kann jemand bitte weiter ausführen?
Antworten:
Ihr Link verweist auf Dokumentation, die 10 Jahre alt ist.
SSH unterstützt mehrere Möglichkeiten zur Authentifizierung von Benutzern. Am häufigsten werden Sie nach einem Login und einem Passwort gefragt. Sie können den Benutzer jedoch auch nach einem Login und einem öffentlichen Schlüssel authentifizieren. Wenn Sie PasswordAuthentication auf no setzen, können Sie sich nicht mehr mit Login und Passwort authentifizieren und müssen stattdessen einen Login und einen öffentlichen Schlüssel verwenden (wenn PubkeyAuthentication auf yes gesetzt ist).
Beachten Sie, dass die Einstellung PasswordAuthentication nicht ALLE kennwortbasierten Authentifizierungen steuert. ChallengeResponseAuthentication fragt normalerweise auch nach Passwörtern.
PasswordAuthentication steuert die Unterstützung des in RFC-4252 (Abschnitt 8) definierten Authentifizierungsschemas 'Kennwort'. ChallengeResponseAuthentication steuert die Unterstützung für das in RFC-4256 definierte Authentifizierungsschema "keyboard-interactive". Das "tastaturinteraktive" Authentifizierungsschema könnte theoretisch einem Benutzer eine beliebige Anzahl von facettenreichen Fragen 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 BOTH PasswordAuthentication und ChallengeResponseAuthentication auf "no". Wenn Sie sich für Gürtel und Hosenträger interessieren, sollten Sie UsePAM ebenfalls auf "Nein" setzen.
Die Authentifizierung mit öffentlichem / privatem Schlüssel (aktiviert durch die Einstellung PubkeyAuthentication) ist ein separater Authentifizierungstyp, bei dem natürlich keine Benutzerkennwörter an den Server gesendet werden.
Einige würden argumentieren, dass die Verwendung von ChallengeResponseAuthentication sicherer ist als die Verwendung von PasswordAuthentication, da die Automatisierung schwieriger ist. Sie empfehlen daher, PasswordAuthentication deaktiviert zu lassen, während ChallengeResponseAuthentication aktiviert bleibt. Durch diese Konfiguration wird auch die Verwendung der öffentlichen Authentifizierung für alle automatisierten Systemanmeldungen gefördert (aber nicht unbedingt verhindert). Da es sich bei SSH jedoch um ein netzwerkbasiertes Protokoll handelt, kann der Server nicht garantieren, dass Antworten auf ChallengeResponseAuthentication (auch als "tastaturinteraktiv" bezeichnet) tatsächlich von einem Benutzer bereitgestellt werden, der an einer Tastatur sitzt, solange die Herausforderung besteht und besteht nur darin, einen Benutzer nach seinem Passwort zu fragen.
UsePAM
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 sein, wenn der Server kompromittiert wurde, da das Kennwort dann erfasst werden kann.
Mit public-key wird Ihr Passwort nicht an den Server übertragen, es ist sicherer, aber es muss mehr eingerichtet werden.
Sie können den Wert bei Verwendung von Schlüsseln auf no setzen oder deren Verwendung erzwingen.