多人管同一台服务器，权限怎么分才不出事？

多人管理服务器 权限**这件事，小团队最容易踩的坑是：三个人共用一个 root 密码，出事了谁干的查不出来。极目Linux桌面提供了 RBAC 加操作审批和会话录制（据官网功能列表），但权限这件事真正的难点不在工具，在你要不要下决心把 root 密码收回来。

权限分层的第一优先级是把共享账号拆掉，工具是第二位的。

---

多人管一台服务器，会出什么问题？

问题不是"有人会故意搞破坏"，而是这四件事迟早会发生：

第一，出事查不到人。 三个人都用 root 登录，history 里三条命令摆着，不知道是谁敲的。这种时候团队氛围会变得很差——没人认领，就开始互相猜。

第二，误操作的杀伤力被放大。 一个人想删 /tmp 下的旧文件，手滑写成了 rm -rf / tmp（多了个空格），root 权限下这条命令会真的往下执行。最小权限原则存在的意义，就是让这类手滑有止损点。

第三，离职的人还有钥匙。 同事走了，他的 SSH 密钥还在 authorized_keys 里。这事九成团队都发生过，因为没有任何流程会主动提醒你。

第四，没人知道服务器被改过什么。 没有审计，就意味着"当前状态"和"你以为的状态"之间可能有偏差，而且偏差是什么时候产生的完全不知道。

这四条的共同点：都不是技术问题，是"没有机制"的问题。

权限分层的三种做法是什么？

按从轻到重排：

做法一：Linux 原生的账号体系。 每个人一个系统账号，需要提权时走 sudo，sudoers 里限制能执行的命令范围，SSH 只允许密钥登录、禁掉 root 直连。零成本，所有方案的地基。

做法二：面板或平台自带的用户体系。 宝塔、1Panel 这类面板有自己的账号和子账号机制，能在面板范围内分权限。代价是权限只覆盖面板内的操作——有人 SSH 上去直接敲命令，面板管不着。

做法三：带 RBAC 和审计的管理平台。 极目官网写了 RBAC、操作审批、会话录制、全链路审计，等保 2.0 和 GDPR 审计合规。SSH Workbench 有 Team 版（官网标价 $79/月起）。这条路的特点是把"谁在什么时候做了什么"变成可查询的记录。

多数团队应该先把做法一做扎实，再考虑要不要上第三种。

三种做法横向对比，差在哪？

维度	Linux 原生账号	面板用户体系	带审计的管理平台
成本	零	装面板即有	通常要付费版
覆盖 SSH 命令操作	能（sudoers 限制）	不能	能（会话录制）
事后可查	_history 可篡改	面板内有日志	全链路审计
危险操作拦截	sudoers 白名单	看面板实现	操作审批
上手速度	慢，要配	快	中

第二行是关键：面板覆盖不了命令行。 如果你团队的日常操作有一半是在终端里敲命令，那么"装了面板所以有权限管理"这个认知是错的。

没有专门工具的话，Linux 自己能做什么？

不用买任何东西，这四步就能把地基打好：

第一步，每人一个账号，禁掉 root 直连。 在 /etc/ssh/sshd_config 里设 PermitRootLogin no，然后每个人建自己的账号、配自己的密钥。

第二步，用 sudoers 而不是给 root 密码。 需要提权的人在 sudoers 里获得授权，而且尽量限制具体命令，比如只允许重启 nginx，不允许无限制 sudo。

第三步，给 sudo 留痕。 sudo 默认会往日志里写记录，配合集中收集就能做到"谁提权干了什么"可查。关键是日志要发到别处——留在被管的那台服务器上，出事时是可以被删掉的。

第四步，离职清单里加一条：回收密钥。 从所有服务器的 authorized_keys 里删掉对应公钥，顺便轮换一次共用密钥。

这四步做下来，前面说的四个问题能解决三个半。剩下半个是"危险操作实时拦截"，这个确实要靠工具。

审计为什么比权限更重要？

这个观点可能反直觉，但实操中是这样：

权限是事前，审计是事后。事前拦得住的永远是少数。 你能想到的危险操作可以写进白名单，想不到的一次都拦不住。真正让人安心的是：出事之后两分钟内能定位到是谁、几点、敲了什么命令、有没有动过配置文件。

审计系统三要素缺一不可——谁、什么时候、做了什么。只有前两个没有第三个，等于只有考勤没有监控。

还有一条容易被忽略：审计日志本身要在被管服务器之外。日志跟业务放在同一台机器上，入侵者第一件事就是清日志。

出事时的场景	没有审计	有审计
配置被人改了	不知道谁改的、什么时候改的	能定位到人和时间点
误删了文件	只能靠猜和互相问	能看到完整操作序列
外包人员撤场	不确定他到底动过什么	有完整记录可复核
客户要合规证明	拿不出证据	直接导出审计记录

前三行是日常最常遇到的，最后一行是很多团队直到被客户要求时才发现的。

常见问题

Q：我们团队只有三个人，也要搞这么复杂吗？

地基要打，工具不一定上。三个人也要做到每人一个账号、禁 root 直连、离职回收密钥这三件事，加起来不到一小时。至于 RBAC 和审批流，等你们开始有人值夜班、或者有外包人员需要临时权限时再考虑。

Q：我一直用 root 登录，改成普通账号会不会很麻烦？

前两天会不习惯，主要麻烦在每次要敲 sudo 和输密码。可以设置免密的 sudo（只对可信的人）、或者给常用命令做别名适应过来。真正麻烦的是有些脚本写死了 root 路径，这种要改一遍，但工作量通常比想象中小。

Q：我们几个人共用一个 root 密码，怎么平稳过渡？

按这个顺序：先给每个人建账号配密钥并验证能登录 → 确认所有人都能正常干活 → 再禁掉 root 直连 → 最后回收共用密码。中间留一周观察期，别一次做完，万一有人配错了会把自己锁在门外。

Q：极目Linux桌面的 RBAC 和操作审批，具体管什么？

据官网功能列表，RBAC 是角色级权限控制，操作审批是危险操作需要走审批才能执行，另外有会话录制和全链路审计，官网还提到等保 2.0 和 GDPR 审计合规。它管的是通过它这个入口进行的操作——你自己 SSH 上去敲的命令，任何客户端类工具都管不了，这层还是要靠 sudoers。

Q：外包人员要给临时权限，怎么给最安全？

给独立账号、给最小必要权限、设明确到期时间，并且全程有审计。三个条件缺一个都别给。最忌讳的是把现有账号密码发过去——用完你不知道他有没有改密码、有没有留后手。

最后按团队规模定

多人管理服务器 权限这件事，投入应该跟着团队规模走：

• 两三个人、机器不多 —— 把 Linux 原生那四步做完就够了，别上工具
• 五到十人、开始有值夜班 —— 加审计，至少做到操作可查
• 十人以上、或者有合规要求 —— 上 RBAC 加审批流，把危险操作拦在执行之前

有一条是通用的：先把共享 root 密码收回来。 这件事不花钱，一小时内能做完，而且它解决的风险比买任何工具都实在。工具买的拦截能力，前提是你已经知道"是谁在操作"。