免密提权的本质是授权范围问题
免密提权让自动化流程不必交互输入口令即可获得特权，代价是把「知道口令」这层门槛去掉了。因此配置的重点不是「要不要免密」，而是「允许哪个身份、在哪些主机、以哪个目标用户、执行哪些命令」四要素是否收得很紧。四要素中任何一个放宽到通配，免密就等于把该范围内的特权直接交给了持有该账号的所有人。
基本信息
| 适用对象 | Linux 与类 Unix 系统的提权工具 |
|---|---|
| 配置位置 | 集中配置文件与包含目录，语法以官方文档为准 |
| 四要素 | 授权身份、主机范围、目标用户、可执行命令 |
| 校验方式 | 编辑工具自带语法检查，改前务必备份 |
| 审计能力 | 可记录命令输入输出与会话内容，用于事后追溯 |
配置要点
- 命令写绝对路径：按路径精确授权，避免同名命令被替换后获得特权执行
- 避免通配授权：命令参数可被解释器或编辑器二次执行时，通配等于放开任意命令
- 限定目标用户：默认切到最高权限用户是最危险的做法，应按需要指定目标身份
- 按组授权而非按个人：人员变动时只需调整组成员，规则不会随人员流动残留
- 保留非交互语义：自动化场景要求不带终端执行，需确认规则与相关默认项允许该方式
- 开日志留痕：记录执行的命令与会话内容，是事后复盘的唯一依据
规则写法示例
规则写法示例
# 按组授权，仅允许以指定身份执行少数命令
%deployops ALL=(root) NOPASSWD: /usr/bin/systemctl restart myapp, /usr/bin/systemctl status myapp
# 单独定义命令别名，便于统一维护
Cmnd_Alias WEBREL = /usr/bin/systemctl reload nginx
%webops ALL=(root) NOPASSWD: WEBREL
# 记录输入输出，供事后审计
Defaults log_input, log_output
Defaults iolog_dir="/var/log/sudo-io"验证与使用
验证与使用
visudo -c # 语法检查，改完必须执行
sudo -l -U deployuser # 查看该账号实际可用规则
sudo -n /usr/bin/systemctl status myapp # 非交互执行，验证免密是否生效
sudo -K # 清除缓存的时间戳，重新验证行为授权粒度与风险
| 写法 | 效果 | 风险 |
|---|---|---|
| 指定命令加绝对路径 | 只能执行该命令 | 风险可控，推荐 |
| 命令后带通配 | 参数不受限 | 可通过参数调用其他程序 |
| 放开全部命令 | 等于完整特权 | 账号失窃即全盘失守 |
| 授权给通配目标用户 | 可切换任意身份 | 横向移动范围被放大 |
免密规则只解决「不用输口令」，不解决「谁能用这个账号」。真正的边界在账号本身：自动化账号应只允许从指定来源、用指定密钥登录，并禁止交互式登录，这样免密规则的影响面才被收窄。
提权配置写错会把所有人挡在门外，包括你自己。修改前保留一个已提权的会话，改完先做语法检查再验证；确认可正常提权后才退出原会话。