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无密码 - 仅需要密码须藤

组设置正确。

$ groups user
user : user sudo docker

这条线是在/etc/sudoers:

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

在救援模式下,重置密码,仔细检查内容/etc/影子反对独立计划:

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

输出与中显示的哈希完全匹配/etc/影子。仍然须藤升级失败。

是否有其他系统设置可以阻止须藤使用正确的密码升级?

(我突然想到,升级可能包含有针对性的故意黑客攻击,以说服我允许须藤无需密码即可升级,但这似乎不太可能)。


内容/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包含将返回值推入堆栈的顺序指令 - 它不容易理解并且很脆弱,并且显然对更新敏感。

进行修改的目的是捕获两者须藤登录(和SSH密钥登录?)在某一时刻失败。这是我在 Stack Exchange 上的某个地方看到的……现在我将以正统的方式分别实现每个功能。坏的须藤很简单 - 我只需要输入这两行/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,它可能会按预期工作。

相关内容