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
共通認証
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/共通アカウント
# 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-非対話型
# 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 -i、 の失敗も増加しますpam_tally2。
答え1
権限のない外部ユーザーからのログイン試行が継続的に発生しているとのことです。これらの望ましくないリモート ログイン試行がユーザー アカウントを参照している場合、rootPAMモジュールがそれらの 1 つまたは両方をロックアウトしているusername可能性があります。pam_tally2
コマンドを実行してpam_tally2、失敗の原因を確認します。(pam_tally2 --user=username --resetのブロックをリセットするには、を実行する必要がある場合がありますusername。
あるいは、この問題レポートpam_tally2 は、/etc/ssh/sshd_config ファイルに「ChallengeResponseAuthentication yes」が設定されている場合、有効なパスワードを失敗したログイン試行としてカウントします。あなたのシナリオをより正確に説明できるかもしれません。(解決策の代替ソースをまだ探しているところです。)
ちなみに、Canonical のあらゆる最善の（しかし間違った）努力にもかかわらず、sudo su何に対しても を使用する必要はありません。（「ルート権限をください。わかりました、ありがとうございます。今私はルート権限を持っています。ルート権限が必要です"。)sudo -sルート シェルまたはsudo -iルート ログイン シェルを試してください。