Ubuntu 16.04.3 LTSサーバーを使用しています。 sudo権限を持つユーザーがいます。現在のユーザーがrootに切り替えようとすると、パスワードの入力を求められます。正しいパスワードを入力しましたが、パスワードが拒否されました。
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
幸いなことに、別のターミナルウィンドウを開きましたが、まだrootとしてログインしています。そのため、ユーザーのパスワードをリセットしようとしています。ユーザーを正常に更新したとします。
root@server:/# passwd username
Enter new UNIX password:
Retype new UNIX password:
passwd: password updated successfully
だから私はそのコマンドを再試行しましたsudo su。同じメッセージで失敗します。
同じユーザーに対して新しい端末ウィンドウを開こうとしましたが、sudo su同じメッセージで同じコマンドが失敗しました。
私もユーザーのロックを解除しようとしましたsudo usermod --expiredate -1 username。これも問題は解決されませんでした。
また、ユーザーに「sudo」権限を与えてみましたusermod -aG sudo username。ユーザーにはまだこの問題が発生しています。
私は放棄し、ちょうどsudo権限を持つ新しいユーザーを作成し、新しいユーザーを使い始めました。翌日、私は新しいユーザーと同じ問題を抱え始めました。
このpwckコマンドは、複数のシステムアカウントとそのホームディレクトリのメッセージを一覧表示しますが、それ以外は何も表示しません。このgrpckコマンドはまったくメッセージを提供しません。
最近約1か月前に「pam」認証を追加しました。
/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/common-account
# 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
@telcoM、@roaimaのおかげで、pam認証モジュールが問題の原因であることがわかりました。
root@server:/# pam_tally2
Login Failures Latest failure From
username 53 06/05/18 16:53:42 xxx.xxx.xxx.xxx
問題の原因が見つかりましたが、この動作を理解できませんでした。おそらく、pamモジュールで誤って設定した可能性があります。入力するたびにsudo su（成功かどうかにかかわらず）失敗しますpam_tally2。以下の例
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
使用すると誤動作が増加する可能性sudo -sがあります。sudo -ipam_tally2
ベストアンサー1
承認されていない外部ユーザーが引き続きログインしようとしました。不要なリモートログイン試行がrootユーザーアカウントを参照している場合は、PAMモジュールが両方または両方をロックしているusernameことを意味できます。pam_tally2
コマンドを実行してpam_tally2障害の原因を確認してください。 （pam_tally2 --user=username --resetリセットするには実行する必要がありますusername。
またはこの問題レポート/etc/ssh/sshd_config ファイルに「ChallengeResponseAuthentication yes」が設定されている場合、pam_tally2 は正しいパスワードを失敗したログイン試行としてカウントします。状況をより正確に説明できます。 （私はまだ解決策のための代替ソースを見つけようとしています。）
ちなみに、Canonicalのすべての最善の（そして間違った）努力にもかかわらず、それを使用する必要はありませんsudo su。 （これは「と言うのと同じです。ルートを教えてください？よろしくお願いします。今私はルートです。ルートになる必要があります。".) sudo -sroot シェルまたはsudo -iroot ログインシェルを試してください。