Ich habe die Anweisungen von Redhat befolgt, wie man die Authentifizierung auf einem Linux-Server verstärkt, aber wir verwenden nur SSH mit Authentifizierung über öffentlichen Schlüssel. Gemäß diesen Anweisungen: https://access.redhat.com/documentation/en-us/red_hat_enterprise_linux/7/html/security_guide/chap-hardening_your_system_with_tools_and_services
Hier sind meine Dateien /etc/pam.d/system-auth und /etc/pam.d/password-auth. Eigentlich sind sie beide gleich:
#%PAM-1.0
# This file is auto-generated.
# User changes will be destroyed the next time authconfig is run.
auth required pam_env.so
auth required pam_faildelay.so delay=2000000
auth required pam_faillock.so preauth silent audit deny=3 even_deny_root unlock_time=60
auth sufficient pam_unix.so nullok try_first_pass
auth [default=die] pam_faillock.so authfail audit deny=3 even_deny_root unlock_time=60
auth requisite pam_succeed_if.so uid >= 1000 quiet_success
auth required pam_deny.so
account required pam_faillock.so
account required pam_unix.so
account sufficient pam_localuser.so
account sufficient pam_succeed_if.so uid < 1000 quiet
account required pam_permit.so
password requisite pam_pwquality.so try_first_pass local_users_only retry=3 authtok_type=
password sufficient pam_unix.so sha512 shadow nullok try_first_pass use_authtok
password required pam_deny.so
session optional pam_keyinit.so revoke
session required pam_limits.so
-session optional pam_systemd.so
session [success=1 default=ignore] pam_succeed_if.so service in crond quiet use_uid
session required pam_unix.so
Mit dieser Konfiguration wollte ich eine Art Sperrmeldung erhalten, wenn der Benutzer beispielsweise nach drei Versuchen versucht, sich mit dem falschen Schlüssel zu authentifizieren. Es wird jedoch keine Meldung zur Sperrung angezeigt und ich kann nicht feststellen, ob die Sperrrichtlinie funktioniert oder nicht. Es gibt auch das Modul pam_tally2, aber ich sehe keinen Unterschied im Vergleich zum Modul pam_faillock.
Die Protokolle zeigen nichts außer, dass die Root-Berechtigung verweigert wurde:
[some_user@ip-10-10-2-53 ~]$ cat /var/run/faillock/some_user
[some_user@ip-10-10-2-53 ~]$ cat /var/run/faillock/root
cat: /var/run/faillock/root: Permission denied
Und ich habe versucht, den falschen Schlüssel für die SSH-Verbindung zu verwenden some_user, und es scheint, als würde ich dadurch nicht ausgesperrt, da ich weder in den Faillock-Protokollen noch in einer SSH-Nachricht von der Stelle, von der ich die SSH-Verbindung herzustellen versuche, etwas sehe.
Antwort1
Das Problem besteht darin, dass Sie versuchen, diese Richtlinien innerhalb des Authentifizierungsstapels durchzusetzen.
auth required pam_env.so
auth required pam_faildelay.so delay=2000000
auth required pam_faillock.so preauth silent audit deny=3 even_deny_root unlock_time=60
auth sufficient pam_unix.so nullok try_first_pass
auth [default=die] pam_faillock.so authfail audit deny=3 even_deny_root unlock_time=60
auth requisite pam_succeed_if.so uid >= 1000 quiet_success
auth required pam_deny.so
account required pam_faillock.so
account required pam_unix.so
account sufficient pam_localuser.so
account sufficient pam_succeed_if.so uid < 1000 quiet
account required pam_permit.so
Die im SSH-Daemon selbst implementierte Authentifizierung mit öffentlichem Schlüssel umgeht den Authentifizierungsstapel. (Es wird kein PAM-Authentifizierungsmodul aufgerufen, um den übermittelten Schlüssel zu validieren, also muss es so funktionieren.) Die einzige Ausnahme ist, wenn Sie eine benutzerdefinierte Konfiguration ausführen, die auch innerhalb der interaktiven Tastatur erfolgreich sein muss. Da dies nicht die Standardeinstellung ist, wird Ihr Authentifizierungsstapel bei diesen Authentifizierungen mit ziemlicher Sicherheit ignoriert.
Während der accountStapelnormalerweisewo Sie Beschränkungen für Anmeldungen nur mit öffentlichem Schlüssel festlegen, glaube ich nicht, dass das hier funktionieren wird, da Sie zuerst die Authentifizierung erfolgreich durchführen müssten, damit das PAM-Modul aufgerufen wird. Wenn Ihr PAM-Modul nicht aufgerufen wird, kann es bei jeder fehlgeschlagenen Anmeldung keinen Zähler erhöhen.
Ich kann mir nur vorstellen, dass dies funktioniert, wenn Sie Ihre SSHD-Konfiguration so anpassen, dass eine tastaturinteraktive Authentifizierung erforderlich istzusätzlich zuAuthentifizierung mit öffentlichem Schlüssel. (Sie könnendiese Frage und Antwortals Ausgangspunkt) Allerdings ist es, wie JohnA anmerkt, fraglich, ob dies wirklich einen Mehrwert bieten würde.
Antwort2
Ich bin ziemlich sicher, dass Sie PAM in dieser Funktion nicht verwenden können. Wenn der Benutzer nicht über den privaten SSH-Schlüssel verfügt, der dem öffentlichen SSH-Schlüssel auf dem Server entspricht, kann er sich nicht authentifizieren.
Der Zweck der Kennwortsperre besteht darin, das Erzwingen des Kennworts eines Benutzerkontos durch Brute-Force-Angriffe zu verhindern. Wenn die SSH-Schlüsselauthentifizierung erzwungen wird, muss kein Benutzerkontokennwort berücksichtigt werden.
Bei dem für die SSH-Schlüsselauthentifizierung angeforderten Kennwort handelt es sich um das Kennwort für den privaten Schlüssel. Eine fehlgeschlagene Authentifizierung anhand des privaten Schlüssels führt nicht zu einem Authentifizierungsfehler beim Server.