关键不是“封禁什么”，而是“只放行什么”——需组合sudo白名单授权、/sbin/nologin登录限制、setfacl文件级控制及rbash环境锁定三层机制实现最小权限。
限制特定运维账号的 Shell 命令执行权限，关键不是“封禁什么”，而是“只放行什么”——用白名单机制构建最小权限边界。直接删命令、改权限或靠 alias 拦截，容易被绕过或影响系统稳定性，真正落地需组合三层控制：sudo 白名单授权、登录 Shell 限制、目录级访问控制。
用 /etc/sudoers 做精准命令授权
运维账号通常需要执行少数高危操作（如重启服务、查看日志），但绝不能拥有全量 root 权限。必须通过 visudo 编辑 sudoers，按绝对路径精确授权：
- 写成
deploy ALL=(root) /usr/bin/systemctl restart nginx，不能简写为systemctl或漏掉/usr/bin/ - 多个命令用逗号分隔：
/usr/bin/journalctl, /usr/bin/tail；禁止某条加!前缀：!/bin/rm -
NOPASSWD:必须紧贴命令前，格式为deploy ALL=(root) NOPASSWD: /usr/bin/systemctl，而非NOPASSWD: ALL - 规则顺序生效：若上面已有
%wheel ALL=(ALL:ALL) ALL，你下面的限制规则将永不匹配
用 /sbin/nologin 阻断交互式登录
运维账号常用于自动化任务（如 cron、rsync、API 调用），无需 SSH 登录 shell。改 shell 是最干净、无副作用的方式：
- 执行
sudo usermod -s /sbin/nologin deploy，用户 SSH 连接后立即退出，提示 “This account is currently not available.” - 不影响其 cron job、systemd --user 服务、或 rsync over SSH 等非交互场景
- 恢复登录只需
sudo usermod -s /bin/bash deploy，无需重置密码
用 setfacl 控制命令文件级执行权
当需更细粒度区分用户（如允许 deploy 执行 rm，但禁止 backup 用户），chmod 的三段式权限不够用，必须用 ACL：
- 先收回通用执行权：
sudo setfacl -m other::r-x /bin/rm→ 改为other::r-- - 单独授权目标用户：
sudo setfacl -m u:deploy:r-x /bin/rm - 验证结果：
getfacl /bin/rm应显示user:deploy:r-x，且 mask 未屏蔽该权限 - 注意：ACL 优先级高于传统权限，但需确保文件系统挂载时启用 acl 选项（ext4 默认支持）
用 rbash + 自定义 PATH 锁定可用命令集
对强隔离需求（如第三方合作方仅能执行监控脚本），可启用受限 shell：
- 创建软链接：
sudo ln -sf /bin/bash /bin/rbash，再设用户 shell：sudo usermod -s /bin/rbash monitor - 在用户家目录建专用 bin 目录：
mkdir ~/bin，只放入允许的命令软链接，如ln -s /usr/bin/uptime ~/bin/uptime - 在
~/.bashrc中强制重设 PATH：export PATH="$HOME/bin"，并禁止修改（rbash 会拦截PATH=赋值） - 该方式下，用户无法 cd 切目录、无法用绝对路径调用命令、无法重定向输出，天然防逃逸
