sudoパスワードアップグレードに失敗しました - /etc/shadowハッシュは正常、グループは正常、/etc/sudoersは正常

sudoパスワードアップグレードに失敗しました - /etc/shadowハッシュは正常、グループは正常、/etc/sudoersは正常

システムのアップデート/アップグレード後、正しいパスワードでsudoを使用してアップグレードすることはできません。

user $ sudo -s
[sudo] password for user: ********************
Sorry, try again.
[sudo] password for user: ********************
Sorry, try again.

(これはVPSです。ログインは次のように行われます。SSHパスワードなし - パスワードのみが必要Sudo)

グループ設定が正しい。

$ groups user
user : user sudo docker

この路線は/etc/sudoers:

# Allow members of group sudo to execute any command
%sudo   ALL=(ALL:ALL) ALL

レスキューモードでパスワードをリセットし、内容を再確認してください。/etc/shadow独立計画の反対:

mkpasswd --method=sha-512 --salt=GiHwtvMC
Password: ********************
$6$GiHwtvMC$pONfZo5...<omitted>...Vg5c0

出力は表示されたハッシュと正確に一致します。/etc/shadow。まだSudoアップグレードに失敗しました。

回避できる他のシステム設定はありますか?Sudo正しいパスワードを使用してアップグレードしますか?

(アップグレードには、私が許すように説得する目標とされた意図的なハッキングを含めることができると思いました。Sudoパスワードなしでアップグレードが可能ですが、その可能性はほとんどありません。)


コンテンツ/etc/sudoers、コメントが削除されました

Defaults        env_reset,timestamp_timeout=-1
Defaults        mail_badpass
Defaults        secure_path="/usr/local/sbin:/usr/local/bin:/usr/sbin:/usr/bin:"
root    ALL=(ALL:ALL) ALL
%admin ALL=(ALL) ALL
%sudo   ALL=(ALL:ALL) ALL

/var/log/auth.logからの抜粋

Jan 31 10:46:48 izu sshd[1126]: Accepted publickey for username from 111.111.111.11 port 52768 ssh2: RSA SHA256:<omitted>
Jan 31 10:46:48 izu sshd[1126]: pam_unix(sshd:session): session opened for user username by (uid=0)
Jan 31 10:46:48 izu systemd-logind[679]: New session 1 of user username.
Jan 31 10:46:48 izu systemd: pam_unix(systemd-user:session): session opened for user username by (uid=0)
Jan 31 10:46:48 izu sshd[1126]: User child is on pid 1150
Jan 31 10:46:48 izu sshd[1150]: Starting session: shell on pts/0 for username from 111.111.111.11 port 52768 id 0
Jan 31 10:47:16 izu sudo: pam_unix(sudo:auth): authentication failure; logname=username uid=1000 euid=0 tty=/dev/pts/0 ruser=username rhost=  user=username

問題は前作の修正にある/etc/pam.d/common-authログファイルの抜粋を電子メールで送信できます。

# here are the per-package modules (the "Primary" block)
auth    [success=1 default=ignore]  pam_unix.so nullok_secure

# ADDED HOOK NOW REMOVED
auth    optional  pam_exec.so seteuid /etc/local/lib/pam_auth_fail_notify.sh    

# 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)
# end of pam-auth-update config

答え1

問題が何であるかについての@steveの提案/etc/pam.dそうだね

問題は、ログファイルの抜粋を電子メールで送信できるようにした /etc/pam.d/common-auth の以前の修正です。

# here are the per-package modules (the "Primary" block)
auth    [success=1 default=ignore]  pam_unix.so nullok_secure

# ADDED HOOK NOW REMOVED
auth    optional  pam_exec.so seteuid /etc/local/lib/pam_auth_fail_notify.sh    

# 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)
# end of pam-auth-update config

AFIR、この文書およびその他の文書/etc/pam.d戻り値をスタックにプッシュする順次命令が含まれています。わかりやすく、壊れやすく、アップデートに敏感なようです。

修正の目的は、両方をキャプチャすることです。Sudoそしてログイン(そしてSSHキーログイン? )ある時点で失敗します。スタックエクスチェンジはどこかが見た内容なのですが… 今では、本格的な方法で各機能を別々に実装してみましょう。悪いSudo簡単です。この2行だけを入力してください。/etc/sudoers

Defaults    mail_badpass
Defaults    mailerpath="/usr/local/sbin/sendmail"

私の場合、メールを送信標準ではありません。 APIを介して無料の電子メールサービスに送信されます。この行は公式メール設定には必要ありません。

答え2

Pam設定の問題は、Ubuntuがpamを構築する新しい方法([success = 1 default = ignore])によって引き起こされる可能性が高いです。

pam_unix が成功すると、1 行をスキップします。 pam_denyをスキップすると予想していましたが、代わりにpam_execをスキップしてpam_denyを実行しました。 pam_denyとpam_succeedの間でpam_execを移動すると、期待どおりに機能する可能性があります。

関連情報