最可靠方式是用sudo grep -r "NOPASSWD" /etc/sudoers* 2>/dev/null | grep -v "^#"扫描所有配置文件，再以sudo -n -U username true验证实际免密能力，因静态扫描可能漏掉Defaults隐式配置，而运行时验证才反映真实生效策略。
直接查 sudoers 里带 NOPASSWD 的行
最可靠的方式是 grep 扫描所有 sudo 配置源，包括 /etc/sudoers 和 /etc/sudoers.d/ 下所有文件。NOPASSWD 是显式配置项，不会被继承或隐式触发，必须落在某条规则里。
执行以下命令（需 root 或有读取权限）：
sudo grep -r "NOPASSWD" /etc/sudoers* 2>/dev/null | grep -v "^#"
注意点：
-
/etc/sudoers.d/下的文件若权限不是440，sudo会跳过加载，但grep仍能扫到——这意味着配置存在但未生效，属于“伪违规”，需额外验证 - 匹配到
NOPASSWD:后面如果跟的是ALL或宽泛路径（如/bin/sh,/usr/bin/python3），才真正构成提权风险；若只限/usr/sbin/reboot这类窄命令，风险较低 - 别漏掉注释行里的残留配置：有些管理员会用
# NOPASSWD: ALL做标记，实际不生效，但可能误导后续维护
用 sudo -l 检查当前用户是否真有免密能力
sudo -l 是运行时验证，比静态扫描更真实——它反映的是最终生效的策略，已合并 Host_Alias、Runas_Alias、Defaults 等影响。
对目标用户（比如审计中发现的高权限账号）执行：
sudo -l -U username 2>/dev/null
关键判断依据：
- 输出含
(ALL) NOPASSWD: ALL或类似字段 → 确认具备免密 root 权限 - 输出
User username is not allowed to run sudo on hostname→ 该用户未被任何规则显式授权，哪怕他在sudo组里，也无效 - 输出为空但无报错 → 可能被
Defaults requiretty或Defaults !visiblepw拦截，需补测：sudo -n true -U username，返回码为 0 才算真通
警惕组权限被注释或覆盖的“假 sudo 组”
很多运维误以为 groups username | grep -q 'sudo' 就等于有权限，其实完全不是。
Linux Security Scanner
下载
Linux 安全审计工具，检查 SSH 配置、开放/监听端口、防火墙规则（ufw/iptables/nftables）、失败登录尝试、sudoers 权限...
真正起作用的是 /etc/sudoers 里那行 %sudo ALL=(ALL:ALL) ALL 是否未被注释，且没被 /etc/sudoers.d/ 里更高优先级的规则覆盖。
检查步骤：
- 确认默认组规则是否启用：
sudo grep -E '^\s*%sudo\s+ALL' /etc/sudoers - 检查是否有同名但限制更强的覆盖配置：
sudo grep -r "%sudo" /etc/sudoers.d/ 2>/dev/null - RHEL/CentOS 8+ 默认不启用
%wheel，即使用户在 wheel 组，也要看/etc/sudoers里有没有对应未注释行
自动化脚本里静默识别免密账号要绕开陷阱
在批量巡检脚本中，不能用 sudo -v（会卡住等密码）或 sudo -l（输出含敏感命令路径，可能被日志系统拦截）。唯一安全可靠的判断方式是：
if sudo -n -U username true 2>/dev/null; then echo "username has nopasswd sudo"; fi
原理：
-
-n禁止交互，失败立即退出 -
true不产生副作用，不写日志，不触发命令白名单检查 - 返回码 0 表示：用户被授权 + 免密（或缓存有效）+ 主机名匹配 + 无 requiretty 拦截
这个判断链里任意一环断掉，都会返回非 0。所以它既是“有权限”的充分条件，也是“可免密执行任意命令”的最小可信信号。
真正难排查的不是明写的 NOPASSWD，而是那些被 Defaults 隐式放宽的场景，比如 Defaults:user1 timestamp_timeout=0 配合 Defaults:user1 !authenticate，效果等同于免密，但 grep 根本扫不到。
