sudo默认验证当前用户密码而非目标用户密码，因其基于调用者身份授权，通过PAM校验自身密码并依据/etc/sudoers规则提权，确保可追溯性与最小权限；需目标密码时应使用su。
Linux 系统中，sudo 默认不支持也不设计为验证目标用户密码——它验证的是执行命令的当前用户（caller）的密码，这是其安全模型的基础。所谓“sudo 切换用户时输入目标密码”，本质上是误解或混淆了 sudo 与 su 的职责边界。
为什么 sudo 不能也不该验证目标用户密码
sudo 的核心机制是基于调用者身份授权：它读取 /etc/sudoers 规则，确认当前用户是否有权以某身份（如 root 或 alice）运行某命令，然后通过 PAM 调用 pam_unix.so 验证当前用户自己的密码。整个流程不获取、不比对、不传输目标用户的密码。目标用户的密码甚至可能根本不存在（如 Ubuntu 默认禁用 root 密码），或由独立认证系统（如 LDAP、SSO）管理，sudo 无权也不应介入。
真正需要目标密码的场景，该用 su
如果你明确要求用户在切换身份时输入目标账户的密码，正确工具是 su，而非配置 sudo：
-
su - alice：切换到用户 alice，提示输入 alice 的密码 -
su -c "ls /root" root：以 root 身份执行单条命令，仍需输入 root 的密码
这符合 POSIX 行为和传统 Unix 权限模型，且无需修改任何全局策略文件。
强行让 sudo “模拟”目标密码验证？不推荐，且不可靠
理论上可通过自定义 PAM 模块或重写 sudo 的认证栈实现，但存在严重问题：
- 违反最小权限与职责分离原则，大幅增加攻击面
- 多数发行版默认禁用
root或目标用户密码，该配置将直接失效 - 绕过 sudo 日志审计（
/var/log/auth.log记录的是 caller，不是 target） - visudo 语法不支持
auth_user=xxx类指令，硬改会导致语法错误或静默降级
更安全、更可控的替代方案
若目标是限制用户仅能以特定身份执行特定操作，应使用 sudo 的原生能力：
- 在
/etc/sudoers中精确授权：alice ALL=(bob) /bin/ls, /usr/bin/cat，表示 alice 可以用 bob 身份执行这两个命令 - 配合
Defaults runaspw：要求用户在 以其他用户身份运行命令前 输入那个目标用户的密码（注意：此选项极少见、文档弱、兼容性差，且仅适用于本地 shadow 密码；现代系统普遍不启用，也不建议开启） - 对敏感操作启用双重确认：例如用
sudo -i进入 root shell 后再执行，或结合sudoedit安全编辑文件
