一、先明确目标：你到底想管理什么#

一个多人协作的 Ubuntu 系统，权限管理至少要解决这几件事：

1. 每个人都能用自己的身份登录
2. 不同角色拿到不同层级的权限
3. 日常开发和部署不依赖 root
4. 服务运行身份和人员身份分开
5. 出问题时能追踪到是谁做了什么

如果做不到这几点，那么账号再多，也只是“多人共用一堆危险权限”的另一种形式。

二、5 人团队的推荐角色划分#

先假设这个团队里有 5 个人：

• alice：负责人，兼系统管理员
• bob：运维，兼系统管理员
• carol：后端开发
• dave：后端开发
• erin：测试或产品，只需要查看日志和部分结果

对应的权限建议如下：

• alice、bob：可以拥有管理员权限
• carol、dave：不能拿完整系统管理权限，但可以访问项目目录、部署代码、查看应用日志
• erin：只读访问，不参与部署，不修改服务

这就是第一条原则：权限按角色分层，而不是所有人默认同权。

三、为什么示例用户名常写成 Alice、Bob、Carol、Dave、Erin#

这几个名字并不是随手起的。在密码学、网络协议、权限设计和技术文档里，它们经常被当作“占位符角色名”来使用，用来简化多人协作、消息传递或权限关系的描述。

我这里沿用了这种写法，主要是为了让例子更容易读。大致可以这样理解：

• Alice：最常见的发送方或发起者名字，常被认为来自 Adalheidis，有“高贵”之意。
• Bob：最常见的接收方名字，通常被看作 Robert 的昵称，词源可追溯到“光辉的名声”。
• Carol：常用来表示第三个参与者，名字本身在英语世界里也很常见，所以技术文章很喜欢拿来做第三方示例。
• Dave：常用来表示第四个参与者，延续了这种按人名顺着往下补角色的传统。
• Erin：我在这篇文章里把它当成第五个普通成员示例名来用。很多技术语境里也会看到 Eve，通常代表窃听者；这里为了团队示例更自然，我改成了 Erin。

你可以把这些名字理解成技术文章里的“示例角色标签”。它们的意义不在于名字本身，而在于看见这些名字时，读者会很快明白“这是不同身份的参与者”。

四、最佳实践的核心原则#

如果你只记住几条，那我建议记住下面这几条：

• 每个人都使用独立账号，不共用登录身份
• root 保留应急用途，不作为日常工作账号
• 能不给 sudo 的，就不要给
• 能用组管理目录权限的，就不要用 777
• 应用服务尽量用专门的服务账号运行
• 人员入职、离职、转岗都要有权限变更流程

Ubuntu 的权限模型本身不复杂，真正复杂的是团队协作。如果一开始就没有边界，后面一定会在生产环境里补学费。

五、推荐的账号与组设计#

在 Ubuntu 里，比较推荐的做法不是给每个人单独手工开“特殊权限”，而是先设计好组，再通过组来收敛权限。

一个常见且实用的设计如下：

• sudo：系统管理员
• deploy：允许执行部署相关动作
• app_rw：允许读写项目目录
• logs_read：允许查看应用日志

先创建这些组：

1
sudo groupadd deploy
2
sudo groupadd app_rw
3
sudo groupadd logs_read

然后创建团队成员账号：

1
sudo adduser alice
2
sudo adduser bob
3
sudo adduser carol
4
sudo adduser dave
5
sudo adduser erin

再把他们分配到对应组：

1
sudo usermod -aG sudo alice
2
sudo usermod -aG sudo bob
3

4
sudo usermod -aG deploy,app_rw,logs_read carol
5
sudo usermod -aG deploy,app_rw,logs_read dave
6

7
sudo usermod -aG logs_read erin

这一步做完以后，系统的权限结构就已经开始清晰了：谁是管理员，谁能部署，谁能改项目，谁只能看日志，一眼就能分清。

六、SSH 登录的推荐做法#

多人协作服务器上，SSH 登录建议尽量按下面的方式配置：

• 每个人使用自己的账号登录
• 每个人使用自己的 SSH 公钥
• 不要共享密码
• 能关密码登录就关
• root 最好只保留兜底用途

给某个用户添加 SSH 公钥的基本方式如下：

1
sudo mkdir -p /home/carol/.ssh
2
sudo nano /home/carol/.ssh/authorized_keys
3
sudo chown -R carol:carol /home/carol/.ssh
4
sudo chmod 700 /home/carol/.ssh
5
sudo chmod 600 /home/carol/.ssh/authorized_keys

其他用户同理。

这样做的好处是：

• 账号行为可追踪
• 公钥可以单独回收
• 不会因为共享密码导致整体失控

七、目录权限不要图省事用 777#

很多团队一开始最喜欢用的办法，就是项目目录权限不够时直接：

1
chmod -R 777 /srv/myapp

这几乎可以算是多人服务器权限管理里的反面教材。

更稳的方式是：目录归组，用户入组。

假设项目放在 /srv/myapp，推荐这样做：

1
sudo mkdir -p /srv/myapp
2
sudo chown -R root:app_rw /srv/myapp
3
sudo chmod -R 2770 /srv/myapp

这里的 2770 很关键：

• 所有者和组成员可读写执行
• 其他人无权限
• 新建文件会继承组

这样 carol 和 dave 都能协作维护项目目录，但没有被授权的人无法进入。

如果有只读目录，比如报告、文档、导出结果，可以单独做：

1
sudo mkdir -p /srv/reports
2
sudo chown -R root:logs_read /srv/reports
3
sudo chmod -R 2750 /srv/reports

这样像 erin 这种只读角色就能访问，但不能乱改内容。

八、命令解释：chmod 777 和 chmod 2750 到底是什么意思#

多人协作服务器里，这两个命令特别值得单独讲清楚，因为它们分别代表了两种完全不同的权限思路。

1
chmod 777 /some/path

1
chmod 2750 /srv/reports

1
chmod 2770 /srv/myapp

1
chmod 2750 /srv/reports

九、服务运行身份要和人员身份分开#

这一步是很多小团队最容易忽略，但实际上非常重要的一点。

不要让 Web 服务、Worker、定时任务直接跑在某个开发账号下面，更不要长期挂在 root 下面。更推荐的方式是给应用创建一个单独的系统账号：

1
sudo adduser --system --group myapp

然后在 systemd 服务里指定：

1
User=myapp
2
Group=myapp

这样做有几个好处：

• 人员账号和服务身份解耦
• 某个开发离职不会影响服务运行
• 服务被攻击后的影响面更小
• 权限边界更清晰

一句话总结：人是人，服务是服务，不要混在一个账号里。

十、sudo 不要全发，应该精确授权#

一个常见误区是把权限简单分成两种：

• 没有权限
• 全量 sudo

实际上在很多团队里，更合理的做法是：只给一小部分人完整 sudo，给开发人员有限 sudo 权限。

比如 carol 和 dave 只需要重启某个服务、查看某个服务状态、看日志，就没有必要进 sudo 组。你可以用 /etc/sudoers.d/ 做精确授权：

1
alice ALL=(ALL:ALL) ALL
2
bob   ALL=(ALL:ALL) ALL
3

4
carol ALL=(root) NOPASSWD: /usr/bin/systemctl restart myapp, /usr/bin/systemctl status myapp, /usr/bin/journalctl -u myapp
5
dave  ALL=(root) NOPASSWD: /usr/bin/systemctl restart myapp, /usr/bin/systemctl status myapp, /usr/bin/journalctl -u myapp

这意味着：

• alice、bob 是完整管理员
• carol、dave 只能管理 myapp 相关服务
• erin 没有 sudo

这比把开发全部拉进 sudo 组要稳得多，也更符合最小权限原则。

十一、日志权限也应该单独设计#

很多时候测试、产品或者非管理员同事并不需要改系统，但需要查看日志。

这类需求不要靠“顺手给个 sudo”来解决，而应该通过组来控制日志访问。

如果你的应用日志落在 /var/log/myapp，可以这样配置：

1
sudo mkdir -p /var/log/myapp
2
sudo chown -R root:logs_read /var/log/myapp
3
sudo chmod -R 2750 /var/log/myapp

这样加入 logs_read 组的成员就能查看日志，但不能随意修改。

如果你主要依赖 journalctl，也可以通过 sudo 精确授权给某些人只读查看某个服务日志，而不是让他们直接拿完整管理权限。

十二、哪些权限不要轻易给#

在 Ubuntu 系统里，有些权限一旦给出去，实际效果几乎已经接近管理员。下面这些尤其要谨慎：

• sudo
• docker 组
• 可写 /etc
• 可写 systemd 服务文件
• 可写线上代码并且服务直接执行这些代码
• 数据库超级管理员权限

尤其是 docker 组，很多场景下几乎等价于 root。不要因为“只是让他运行一下容器”就随手把用户加进去。

十三、root 账号应该怎么处理#

从最佳实践上讲，root 更适合作为应急账号，而不是日常工作账号。

推荐的使用方式是：

• 保留 root
• 日常不用 root
• 管理员先登录自己的账号，再通过 sudo 提权

这样一来，日常操作都有明确的人类身份，而不是全都混在 root 下面。

如果你暂时还不想禁用 root 远程登录，也至少要做到：

• root 密码足够强
• 尽量使用 SSH key
• 限制来源 IP
• 开启防暴力破解措施

十四、日常审计和安全建议#

一个多人协作系统，不只要“能用”，还要“可审计”。

至少建议做下面这些基础配置：

• 开启 ufw
• 安装 fail2ban
• 启用自动安全更新
• 定期检查 auth.log
• 定期审核组成员和 sudoers

一些常用命令如下：

1
sudo ufw allow OpenSSH
2
sudo ufw enable
3
sudo apt install fail2ban unattended-upgrades

查看登录记录：

1
last
2
lastlog

查看认证日志：

1
sudo less /var/log/auth.log

权限管理真正成熟的标志，不是“从来不出问题”，而是出了问题以后你能快速知道是谁、在什么时候、做了什么。

十五、入职和离职流程一定要固定#

很多团队权限混乱，不是因为技术不会配，而是因为流程没固定。

推荐把权限管理分成两个固定动作。

新成员加入时：

1. 创建独立账号
2. 配置 SSH 公钥
3. 加入对应权限组
4. 记录其职责和拥有的权限

成员离开或转岗时：

1. 先锁定账号
2. 备份家目录
3. 删除 SSH 公钥
4. 移出权限组
5. 删除相关 sudoers 配置
6. 确认不再持有服务或数据库管理权限

锁定账号可以这样做：

1
sudo passwd -l dave
2
sudo usermod -s /usr/sbin/nologin dave

确认不再需要后再删除：

1
sudo deluser --remove-home dave

这一套流程看起来像“管理问题”，但实际上是服务器安全里最容易被低估的一环。

十六、我实际做法#

1
sudo groupadd deploy
2
sudo groupadd app_rw
3
sudo groupadd logs_read

1
sudo adduser alice
2
sudo adduser bob
3
sudo adduser carol
4
sudo adduser dave
5
sudo adduser erin

1
sudo usermod -aG sudo alice
2
sudo usermod -aG sudo bob
3

4
sudo usermod -aG deploy,app_rw,logs_read carol
5
sudo usermod -aG deploy,app_rw,logs_read dave
6

7
sudo usermod -aG logs_read erin

1
sudo mkdir -p /home/alice/.ssh /home/bob/.ssh /home/carol/.ssh /home/dave/.ssh /home/erin/.ssh
2
sudo chmod 700 /home/alice/.ssh /home/bob/.ssh /home/carol/.ssh /home/dave/.ssh /home/erin/.ssh
3
sudo touch /home/alice/.ssh/authorized_keys /home/bob/.ssh/authorized_keys /home/carol/.ssh/authorized_keys /home/dave/.ssh/authorized_keys /home/erin/.ssh/authorized_keys
4
sudo chmod 600 /home/alice/.ssh/authorized_keys /home/bob/.ssh/authorized_keys /home/carol/.ssh/authorized_keys /home/dave/.ssh/authorized_keys /home/erin/.ssh/authorized_keys
5
sudo chown -R alice:alice /home/alice/.ssh
6
sudo chown -R bob:bob /home/bob/.ssh
7
sudo chown -R carol:carol /home/carol/.ssh
8
sudo chown -R dave:dave /home/dave/.ssh
9
sudo chown -R erin:erin /home/erin/.ssh

1
sudo nano /home/alice/.ssh/authorized_keys
2
sudo nano /home/bob/.ssh/authorized_keys
3
sudo nano /home/carol/.ssh/authorized_keys
4
sudo nano /home/dave/.ssh/authorized_keys
5
sudo nano /home/erin/.ssh/authorized_keys

1
sudo mkdir -p /srv/myapp
2
sudo chown -R root:app_rw /srv/myapp
3
sudo chmod -R 2770 /srv/myapp

1
sudo mkdir -p /srv/reports
2
sudo chown -R root:logs_read /srv/reports
3
sudo chmod -R 2750 /srv/reports

1
sudo mkdir -p /var/log/myapp
2
sudo chown -R root:logs_read /var/log/myapp
3
sudo chmod -R 2750 /var/log/myapp

1
sudo adduser --system --group myapp

1
sudo visudo -f /etc/sudoers.d/myapp-team

1
alice ALL=(ALL:ALL) ALL
2
bob   ALL=(ALL:ALL) ALL
3

4
carol ALL=(root) NOPASSWD: /usr/bin/systemctl restart myapp, /usr/bin/systemctl status myapp, /usr/bin/journalctl -u myapp
5
dave  ALL=(root) NOPASSWD: /usr/bin/systemctl restart myapp, /usr/bin/systemctl status myapp, /usr/bin/journalctl -u myapp

1
id alice
2
id bob
3
id carol
4
id dave
5
id erin

1
sudo -l -U alice
2
sudo -l -U bob
3
sudo -l -U carol
4
sudo -l -U dave
5
sudo -l -U erin

1
ls -ld /srv/myapp
2
ls -ld /srv/reports
3
ls -ld /var/log/myapp

1
sudo passwd -l dave
2
sudo usermod -s /usr/sbin/nologin dave

1
sudo deluser --remove-home dave

十七、适合 5 人团队的推荐落地方案#

如果你想直接把这篇文章压缩成一句最实用的建议，那我会推荐这样一套方案：

• alice、bob：管理员，拥有 sudo
• carol、dave：开发，能访问项目目录、部署代码、重启指定服务、查看日志
• erin：只读成员，只能查看日志和部分输出内容
• 所有人都用独立账号和独立 SSH key
• 线上服务使用专门的系统账号运行
• 项目目录通过组授权，不使用 777
• sudo 尽量精确授权，不做泛滥发放
• root 只作为应急身份保留

这套结构对 5 人左右的小团队已经足够实用，而且也方便以后继续扩展到更多成员。

最后的建议#

Ubuntu 的权限管理并不难，难的是你是否愿意在一开始就把边界划清楚。

很多时候，权限问题并不会在第一天暴露出来。它往往会在下面这些时刻一起出现：

• 线上出故障时
• 成员误操作时
• 服务被异常访问时
• 团队成员变动时
• 需要追责或回溯时

所以真正好的权限管理，目标从来不是“尽量方便”，而是：

• 平时足够顺手
• 出事时足够清楚
• 后续扩展时足够稳定

如果你的 Ubuntu 服务器接下来会给多人长期协作使用，那越早把账号、组、目录、服务和 sudo 权限拆开，后面就越省心。

十八、如果你用宝塔面板管理，可以这样落地#

很多团队实际用的不是纯命令行，而是 Ubuntu + 宝塔面板。这种情况下，前面讲的原则并不会失效，只是“账号、目录、服务、面板入口”这几件事需要分开看。

最重要的一句话是：宝塔面板只是管理工具，不能替代 Linux 账号权限设计。

推荐按下面的步骤落地。

如果你的服务器还没有安装宝塔面板，建议先在 纯净的 Ubuntu 服务器 上执行官方安装命令：

1
if [ -f /usr/bin/curl ];then curl -sSO https://download.bt.cn/install/install_panel.sh;else wget -O install_panel.sh https://download.bt.cn/install/install_panel.sh;fi;bash install_panel.sh docscenter

执行后按提示输入 y 确认安装。安装完成后，终端会输出宝塔面板的访问地址、用户名和初始密码。正式登录前，记得先在云厂商安全组或系统防火墙里放行面板端口。

1
sudo groupadd deploy
2
sudo groupadd app_rw
3
sudo groupadd logs_read
4

5
sudo adduser alice
6
sudo adduser bob
7
sudo adduser carol
8
sudo adduser dave
9
sudo adduser erin
10

11
sudo usermod -aG sudo alice
12
sudo usermod -aG sudo bob
13
sudo usermod -aG deploy,app_rw,logs_read carol
14
sudo usermod -aG deploy,app_rw,logs_read dave
15
sudo usermod -aG logs_read erin

1
/www/wwwroot/myapp

1
sudo chown -R root:app_rw /www/wwwroot/myapp
2
sudo chmod -R 2770 /www/wwwroot/myapp

1
sudo mkdir -p /www/wwwroot/myapp/runtime /www/wwwroot/myapp/uploads
2
sudo chown -R www:app_rw /www/wwwroot/myapp/runtime /www/wwwroot/myapp/uploads
3
sudo chmod -R 2775 /www/wwwroot/myapp/runtime /www/wwwroot/myapp/uploads

1
sudo passwd -l dave
2
sudo usermod -s /usr/sbin/nologin dave