root 不该直接登录 SSH，因会破坏权限最小化原则，导致攻击者获得完全控制权；应禁用 PermitRootLogin，创建普通用户并限制 sudo 权限范围，服务进程和定时任务也需降权运行。
为什么 root 不该直接登录 SSH
直接用 root 账户登录 SSH 是权限最小化的第一道防线失守。攻击者一旦拿到密码或密钥，就等于拿到整台服务器的完全控制权，所有日志、审计、隔离机制都形同虚设。
实操建议：
- 在
/etc/ssh/sshd_config中设置PermitRootLogin no，然后sudo systemctl restart sshd - 新建普通用户（如
admin），用useradd -m -s /bin/bash admin创建 - 通过
usermod -aG sudo admin（Debian/Ubuntu）或usermod -aG wheel admin（RHEL/CentOS）赋予有限提权能力 - 确保该用户仅能通过 SSH 密钥登录（禁用密码），密钥权限设为
600
sudo 权限要精确到命令和参数
sudo ALL=(ALL) ALL 这类宽泛配置等于变相开放 root 权限——只要能写临时文件或控制环境变量，就可能绕过限制。真正最小化是只放行必要命令，并锁定参数范围。
实操建议：
- 用
visudo编辑，添加类似%webadmin ALL=(www-data) NOPASSWD: /usr/bin/systemctl restart nginx的行 - 若需传参（如重启指定站点），改用封装脚本 +
sudo白名单：比如写/usr/local/bin/restart-site.sh，再授权sudo /usr/local/bin/restart-site.sh - 避免授权
sudo /bin/bash或sudo /usr/bin/vi——它们可逃逸为 shell - 启用
sudoers日志：确认/etc/sudoers中有Defaults logfile="/var/log/sudo.log"
服务进程不该以 root 身份运行
Web 服务、数据库、队列等长期运行的守护进程，如果默认以 root 启动，一旦存在漏洞（如路径遍历、RCE），攻击者就能直接操作整个系统。
实操建议：
- Nginx 默认已用
www-data（Debian）或nginx（RHEL）用户运行，检查ps aux | grep nginx确认主进程 UID 不是 0 - MySQL 8.0+ 安装后默认使用
mysql用户；若手动编译部署，务必在my.cnf中设置user = mysql - 自研 Python/Node.js 服务，用
systemd启动时显式指定User=appuser和Group=appuser，并确保该用户对数据目录仅有必要读写权限 - 禁止用
sudo python app.py启动——这是常见误操作，会导致整个进程树继承 root 权限
定时任务和脚本的权限链容易被忽略
crontab -e 里写的命令，哪怕只是 curl 或 rsync，也以当前用户身份执行。如果该用户有 sudo 权限、或脚本里硬编码了 sudo，就可能形成隐式提权路径。
实操建议：
- 避免在用户级 crontab 中调用需要提权的命令；必须时，改用系统级
/etc/cron.d/并显式指定run-as-user - 所有自动化脚本开头加
set -u和set -e，防止变量未定义或错误被忽略导致权限误用 - 脚本中涉及文件操作，优先用相对路径或明确限定根路径（如
/var/www/myapp），避免cd / && rm -rf $1类危险模式 - 定期检查
find /var/spool/cron -type f -ls和ls -l /etc/cron.d/，确认无异常可写权限或未知任务
最小化不是“越少越好”，而是“刚好够用”。最难的部分往往不在配置本身，而在于厘清每个服务、每个脚本、每个定时任务背后真实的权限需求——它需要你反复问：这个动作，到底需要哪一级别的能力？有没有更窄的替代方式？
