普通用户不能直接用 root 登录，因会暴露系统最高权限，导致密码泄露、误操作（如 rm -rf /）等高危风险；应禁用 root 远程登录，日常操作通过最小权限 sudo 完成。
为什么普通用户不能直接用 root 登录
因为 root 是系统最高权限账户，直接登录等于把整台机器的控制权暴露在交互入口上。一旦密码泄露、SSH 密钥被窃或终端被劫持，攻击者就能立刻执行 rm -rf /、修改 /etc/shadow 或植入后门。
实际运维中更常见的风险是误操作：比如在 root 下执行 cd /tmp && rm -rf *，本意删自己目录，却因路径拼错或当前目录不在预期位置，清空了整个根文件系统。
合理做法是：
- 禁用 root 的 SSH 密码登录：
PermitRootLogin no（写入/etc/ssh/sshd_config） - 保留 root 的本地 console 登录能力（用于故障恢复），但不开放远程 shell
- 所有日常操作通过普通用户 +
sudo完成，且仅授予最小必要命令权限
如何用 sudoers 精确控制命令权限
sudoers 不是“给用户加 sudo 就完事”，关键在限制能跑什么、以谁的身份跑、是否需要密码。默认的 %sudo ALL=(ALL:ALL) ALL 过于宽泛，生产环境应细化。
例如，让运维人员只能重启 Nginx，不能改配置或杀任意进程：
deploy ALL=(root) NOPASSWD: /bin/systemctl restart nginx, /bin/systemctl status nginx
注意几个易错点：
- 命令必须写绝对路径，
systemctl无效，/bin/systemctl才生效 - 如果命令带参数（如
nginx -t），需明确写出完整命令行，否则匹配失败 - 别用通配符绕过限制，
/usr/bin/*sh会放行/usr/bin/bash -i反弹 shell - 用
sudo -l验证权限是否按预期加载，避免语法错误导致规则未生效
用户组设计要匹配服务边界而非组织架构
不要建 dev、qa、ops 这类和部门对齐的组——权限不是按“谁在哪个组”分，而是“谁需要访问哪些资源”。比如数据库备份脚本需要读取 /var/lib/mysql 和写入 /backup，那就该创建 mysql-backup 组，把对应用户加进去，并设置目录属组 + setgid 位。
典型实践：
- 每个服务独立组：如
webapp、redis、logrotate - 敏感目录用
chgrp+chmod g+rX开放组读执行，禁止 world 权限 - 用
getent group <groupname>检查成员是否准确，避免手工编辑/etc/group出错 - 临时提权用
sg命令切换组上下文，比反复sudo su -更可控
账号生命周期管理常被忽略的三个细节
账号不是创建完就一劳永逸。没清理的僵尸账号是横向渗透的跳板，尤其那些长期没登录、shell 设为 /bin/false 却仍保有 SSH 密钥的用户。
必须定期检查：
- 用
lastlog -b 90找出 90 天未登录的账号，结合业务确认是否可禁用 - 检查
/etc/shadow中密码字段：若为*或!表示锁定，但密钥仍可能有效；应同步清理~/.ssh/authorized_keys - 删除用户时用
userdel -r，否则家目录残留可能被新用户复用 UID，造成权限混淆
自动化这事不能只靠人盯，建议在 cron 里跑脚本扫描 chage -l 输出，对 password_max_days 超期的账号自动发告警。
