服务器账号权限分级安全管理从零上手教程
为什么服务器账号要分级管
很多新手买来服务器后，一直用 root 操作所有事，这就像把家里大门钥匙挂脖子上到处跑。
一旦脚本被注入或密码泄露，攻击者就能拿到整个服务器的控制权。权限分级的意思就是：给不同的人分配不同的“开门权限”——比如开发人员只能操作自己的项目目录，运维人员可以重启服务，只有你（管理员）能改系统配置。
这样即使某个账号被攻破，损失也被限制在小范围内。
开始权限分级前需要做哪些准备
- 一台 Linux 服务器（本文以 CentOS 7/8 为例，Ubuntu 命令略有差别会注明）。
- 已通过 SSH 登录到服务器（使用 root 或一个有 sudo 权限的初始账号）。
- 知道当前服务器上已有的用户列表（用命令
cat /etc/passwd可以查看）。 - 确认是否安装了
sudo（一般系统自带，没有则通过yum install sudo/apt install sudo安装）。
三步搭建账号权限分级体系
第一步：创建不同角色用户
假设你的团队里有一个开发人员（名叫 dev1）、一个运维人员（名叫 ops1）、以及你自己（管理员 admin1）。
先创建普通用户，再初始化密码。
useradd dev1
passwd dev1 # 输入两次密码
useradd ops1
passwd ops1
useradd admin1
passwd admin1用 id dev1 可以查看新用户的 UID、GID 和所属组。
默认每个用户都会创建同名的组（比如 dev1 组）。
第二步：用 sudo 文件精细控制权限
/etc/sudoers 文件控制哪些用户能执行哪些特权命令。千万不要直接编辑源文件，用 visudo 命令安全编辑：
visudo在文件末尾添加以下规则（每条一行）：
# 管理员可以执行所有命令，相当于 root
admin1 ALL=(ALL) ALL
# 运维人员可以执行服务管理相关命令（systemctl、service）和服务日志查看
ops1 ALL=(ALL) /usr/bin/systemctl, /usr/sbin/service, /usr/bin/journalctl
# 开发人员只能执行自己的项目目录操作，其余命令需要申请
# 这里只允许 dev1 重启自己的项目服务（假如项目名叫 myproject）
dev1 ALL=(ALL) /usr/bin/systemctl restart myproject, /usr/bin/systemctl status myproject保存退出（visudo 会自动检查语法）。注意：Ubuntu 上 systemctl 路径可能为 /bin/systemctl，请用 which systemctl 确认。
如果想让 dev1 完全不能执行任何 sudo 命令（只能用自己的普通权限），就不添加任何规则，但通常要给最低限度的操作能力，否则他连查看系统状态都做不了。
第三步：用用户组和目录权限锁死访问范围
创建一个名为 project_dev 的组，把开发人员放进去，再设置项目目录的所属组和权限。
groupadd project_dev
usermod -aG project_dev dev1
# 如果需要其他开发者也加进来
# usermod -aG project_dev dev2
# 假设项目目录在 /opt/myproject
chown -R root:project_dev /opt/myproject
chmod -R 750 /opt/myproject # 所有者（root）读写执行，同组（project_dev）读和执行，其他人无权限此时 dev1 只能通过 cd /opt/myproject 读取和执行文件，但不能修改（除非特别需求则把 750 改成 770 允许同组写）。
你也可以用 ACL 做更细的控制，新手阶段用组权限基本足够。
踩坑最多的四个问题
Q1：visudo 编辑保存时提示语法错误
原因：命令路径写错或漏了逗号 / 空格。
用 visudo -c 检查语法，修复后再退出。
Q2：用户执行 sudo 时提示「不在 sudoers 文件中」
原因：该用户没有配置 sudo 规则。
回看第二步，用 visudo 添加对应条目。
Q3：普通用户无法读取项目文件
原因：目录或文件的所有者/权限不对。
检查 ls -l /opt/myproject，确保用户所在组和目录组一致，且目录权限至少 750（用户是组内成员）。
Q4：忘了禁用 root 远程登录
权限分级的一个辅助措施是禁止 root 通过 SSH 直接登录。
修改 /etc/ssh/sshd_config，找到 PermitRootLogin 设置为 no，然后重启 SSH 服务，这样攻击者无法直接爆破 root 密码。
如何验证权限是否生效
- 用各账号分别 SSH 登录（先测试普通用户能否登录）。
- 测试 sudo 命令：
# 用 admin1 登录
sudo systemctl restart nginx # 应该成功
# 用 ops1 登录
sudo systemctl restart nginx # 成功（已授权）
sudo useradd test2 # 应该提示没有权限
# 用 dev1 登录
sudo systemctl restart nginx # 失败（仅允许操作 myproject）
sudo systemctl status myproject # 成功- 测试目录访问：
su - dev1
cd /opt/myproject && ls # 应该可以列出文件
touch test.txt # 如果权限是750则失败（没有写权限）- 检查 sudo 日志：所有 sudo 执行记录都会写入
/var/log/secure（CentOS）或/var/log/auth.log（Ubuntu）。用tail -f /var/log/secure实时查看，确保没有意外的 sudo 调用。
完成以上步骤后，一个基本的 服务器账号权限分级 环境就搭好了。
实际生产环境还需要结合密钥认证、双因素、审计日志等，但今天的内容已经能帮你把风险降低 80% 以上。
如果你正在处理这项配置，建议先按本文步骤完整执行，再根据自己的环境微调规则；
遇到异常时优先回看“踩坑最多的四个问题”，基本都能解决。
