Ich verwende den Ubuntu 16.04.3 LTS Server. Ich habe dort einen Benutzer mit Sudo-Berechtigungen. Wenn ich versuche, von meinem aktuellen Benutzer zu Root zu wechseln, werde ich nach meinem Passwort gefragt. Ich gebe das richtige Passwort ein und es wird abgelehnt.
username@server:/ sudo su
[sudo] password for username:
Sorry, try again.
[sudo] password for username:
Sorry, try again.
[sudo] password for username:
sudo: 3 incorrect password attempts
Glücklicherweise habe ich ein weiteres Terminalfenster geöffnet, in dem ich immer noch als Root angemeldet bin. Also habe ich versucht, das Passwort für meinen Benutzer zurückzusetzen. Es heißt, ich habe den Benutzer erfolgreich aktualisiert.
root@server:/# passwd username
Enter new UNIX password:
Retype new UNIX password:
passwd: password updated successfully
Also versuche ich den sudo suBefehl noch einmal. Es schlägt mit den gleichen Meldungen fehl.
Ich öffne ein neues Terminalfenster für denselben Benutzer und versuche es, sudo suund derselbe Befehl schlägt mit denselben Meldungen fehl.
Ich habe auch versucht, den Benutzer zu entsperren sudo usermod --expiredate -1 username. Auch dies hat das Problem nicht gelöst.
Ich habe auch versucht, dem Benutzer „sudo“-Rechte zu erteilen usermod -aG sudo username. Das Problem bestand jedoch weiterhin.
Ich habe aufgegeben und einfach einen neuen Benutzer mit Sudo-Rechten erstellt und angefangen, den neuen Benutzer zu verwenden. Am nächsten Tag hatte ich mit dem neuen Benutzer genau dieselben Probleme.
Der pwckBefehl listet mehrere Systemkonten und Nachrichten zu ihren Home-Verzeichnissen auf, sonst aber nichts. Der grpckBefehl gibt überhaupt keine Nachricht aus.
Wir haben vor etwa einem Monat die „PAM“-Authentifizierung hinzugefügt.
/etc/pam.d/sudo
#%PAM-1.0
session required pam_env.so readenv=1 user_readenv=0
session required pam_env.so readenv=1 envfile=/etc/default/locale user_readenv=0
@include common-auth
@include common-account
@include common-session-noninteractive
/etc/pam.d/common-auth
auth required pam_tally2.so deny=5 unlock_time=600
# here are the per-package modules (the "Primary" block)
auth [success=1 default=ignore] pam_unix.so nullok_secure
# here's the fallback if no module succeeds
auth requisite pam_deny.so
# prime the stack with a positive return value if there isn't one already;
# this avoids us returning an error just because nothing sets a success code
# since the modules above will each just jump around
auth required pam_permit.so
# and here are more per-package modules (the "Additional" block)
auth optional pam_cap.so
# end of pam-auth-update config
/etc/pam.d/gemeinsames Konto
# here are the per-package modules (the "Primary" block)
account [success=1 new_authtok_reqd=done default=ignore] pam_unix.so
# here's the fallback if no module succeeds
account requisite pam_deny.so
# prime the stack with a positive return value if there isn't one already;
# this avoids us returning an error just because nothing sets a success code
# since the modules above will each just jump around
account required pam_permit.so
# and here are more per-package modules (the "Additional" block)
# end of pam-auth-update config
/etc/pam.d/common-session-noninteractive
# here are the per-package modules (the "Primary" block)
session [default=1] pam_permit.so
# here's the fallback if no module succeeds
session requisite pam_deny.so
# prime the stack with a positive return value if there isn't one already;
# this avoids us returning an error just because nothing sets a success code
# since the modules above will each just jump around
session required pam_permit.so
# The pam_umask module will set the umask according to the system default in
# /etc/login.defs and user settings, solving the problem of different
# umask settings with different shells, display managers, remote sessions etc.
# See "man pam_umask".
session optional pam_umask.so
# and here are more per-package modules (the "Additional" block)
session required pam_unix.so
# end of pam-auth-update config
Dank @telcoM und @roaima habe ich herausgefunden, dass das PAM-Authentifizierungsmodul die Ursache des Problems ist.
root@server:/# pam_tally2
Login Failures Latest failure From
username 53 06/05/18 16:53:42 xxx.xxx.xxx.xxx
Obwohl ich die Ursache des Problems gefunden habe, verstehe ich das Verhalten nicht. Vielleicht habe ich etwas im PAM-Modul falsch konfiguriert. Jedes Mal, wenn ich tippe sudo su(ob erfolgreich oder nicht), wird ein Fehler hinzugefügt pam_tally2. Ich habe keine Ahnung, warum die erfolgreiche Eingabe des richtigen Passworts die Anzahl der Fehlversuche erhöht, aber es ist so. Beispiel unten.
pam_tally2
Login Failures Latest failure From
username 0 06/05/18 16:53:42 xxx.xxx.xxx.xxx
username@server:/ sudo su
[sudo] password for username:
root@server:/#
pam_tally2
Login Failures Latest failure From
username 1 06/05/18 16:54:03 xxx.xxx.xxx.xxx
Die Verwendung von sudo -soder sudo -iführt auch zu einer Erhöhung der Fehler in pam_tally2.
Antwort1
Sie haben erwähnt, dass es ständig Anmeldeversuche von nicht autorisierten externen Benutzern gibt. Wenn diese unerwünschten Remote-Anmeldeversuche rootauf Ihr usernameBenutzerkonto verweisen, kann dies bedeuten, dass das pam_tally2PAM-Modul einen oder beide davon sperrt.
Führen Sie den pam_tally2Befehl aus, um zu ermitteln, wodurch die Fehler verursacht werden. (Möglicherweise müssen Sie den Befehl ausführen, pam_tally2 --user=username --resetum die Sperre zurückzusetzen username.
Alternativ kann dieser ProblemberichtDie pam_tally2 zählt ein gutes Passwort als fehlgeschlagenen Anmeldeversuch, wenn in der Datei /etc/ssh/sshd_config "ChallengeResponseAuthentication yes" eingestellt istbeschreibt Ihr Szenario möglicherweise genauer. (Ich arbeite immer noch daran, eine alternative Quelle für eine Lösung zu finden.)
Übrigens sollten Sie trotz aller (aber falschen) Bemühungen von Canonical niemals sudo sufür irgendetwas verwenden müssen. (Das ist, als würde man sagen: „Gib mir root? OK, danke. Jetzt bin ich root, ich muss root werden".) Versuchen Sie es sudo -smit einer Root-Shell oder sudo -ieiner Root-Login-Shell.