企业官网建设流程全解析

1. 账号体系：先搞懂 Linux 是怎么认人的

Linux 是个多用户操作系统，这点和 Windows 有本质区别。Windows 你装完电脑通常就一个管理员账号，日常使用也基本是这一两个账户来回切；但 Linux 从设计之初就是给多人多任务用的，一台服务器上可能同时跑着几十个用户的任务，而系统必须精确区分“你是谁”“你能碰什么”“你能执行到什么程度”。这一整套机制，就是 Linux 的账号和权限管理。

很多刚接触 Linux 的人容易把账号管理当成“建个用户、设个密码”这种浅层操作，实际上账号管理的本质是给系统中的每个进程、每个文件、每个操作打上身份标签。Linux 识别用户不靠用户名，靠的是 UID（用户 ID）和 GID（组 ID）。用户名只是给人看的，系统内核里跑的所有权限校验，都是数字 ID 在起作用。你输入ls -l看到的那些“root”“daemon”之类的名字，其实只是 UID 到名称的映射结果。

理解了 UID/GID 这个底层逻辑，后面所有账号和权限的操作就都串起来了。比如你从一台机器把文件打包拷到另一台机器，发现文件属主变成了数字，原因就是目标机器上没有对应的 UID 映射；你新建一个用户，系统自动分配一个 UID，如果 UID 分配到了 1000 以下，可能就会和系统内置账号冲突。这些都是实际运维里天天会遇到的事。

1.1 用户分类：不是所有账号都是给人用的

Linux 里用户粗分三大类：

• 超级用户：UID 固定为 0，也就是 root。它拥有系统绝对控制权，可以无视绝大多数权限限制。
• 系统用户：UID 范围通常是 1~999（CentOS/RHEL 系）或 1~499（Debian 旧版）。这些账号不是给人登录用的，而是给后台服务用的。比如 nginx 服务用nginx用户跑，sshd 服务用sshd用户跑。
• 普通用户：UID 一般从 1000 开始。这类账号才是给人用的，能正常登录、操作自己的家目录和权限范围内的资源。

为什么要区分这么清楚？核心原则叫最小权限。服务用独立系统用户跑，即使服务被攻破，攻击者拿到的也只是那个系统用户的权限，不是 root，也不是某个业务普通用户的权限。这样能把横向扩散的伤害降到最低。

查看 UID 信息的命令很简单：

id username # 查看用户 UID、GID 和所属组 cat /etc/passwd # 所有用户信息都记录在这个文件里

/etc/passwd每行用冒号分成 7 个字段，含义依次是：用户名、密码占位符（真正的密码在/etc/shadow）、UID、GID、描述信息、家目录、登录 Shell。我见过很多新手直接 vim 编辑这个文件，这不是不行，但非常容易手滑把 UID 写重或者把家目录写错，导致用户登录异常。正规做法是用useradd、usermod这类命令去操作，让系统帮你校验和落盘。

1.2 组的概念：权限批量下发的通道

组是一堆用户的集合。给组设置权限，组内所有用户自动继承，省得挨个用户去配。比如公司某个项目组有 5 个人，他们需要共同读写/data/project目录，最合理的方案就是建一个project组，把这 5 人加进去，然后把目录属组改成project，目录权限设为770或2770。这样项目内成员自由操作目录，系统里其他人一概无法访问。

组也分主组和附加组：

• 主组（primary group）：用户创建文件时，文件的属组默认取用户的主组。
• 附加组（supplementary group）：用户额外加入的组，可以让同一个用户同时拥有多个组权限。

每个用户必须有一个主组，但可以加入多个附加组。用usermod -G指定附加组，-g改主组。注意别把-g和-G搞混了，我见过有人想加附加组结果把主组改了，导致用户创建文件时属组全变了，后续权限排查一脸懵。

2. 用户和组的增删改查：每一步都得知道影响面

实操是账号管理最见功夫的地方。大多数初学者只会useradd加passwd，但生产环境里往往还要考虑家目录、Shell、用户注释、过期时间、UID 范围、密码策略这些细节。下面逐个拆解我常用的操作和背后的考虑。

2.1 创建用户：useradd 的默认行为比你想象的多

先说最基础的用法：

useradd zhangsan passwd zhangsan

看起来就两步，但系统背后做了这些事：在/etc/passwd加一行、在/etc/shadow加一列、创建家目录/home/zhangsan、把/etc/skel下的所有隐藏文件（如.bashrc、.profile）复制到家目录、创建同名主组zhangsan。如果你不需要主组，可以：

useradd -N zhangsan # 不创建同名主组

如果你不想让它自动创建家目录，比如给某个服务建系统账号：

useradd -r -s /sbin/nologin -d /nonexistent 服务名

-r表示建系统用户，UID 落在系统范围；-s /sbin/nologin表示不允许这个账号登录 Shell，极客安全服务账号的标配；-d /nonexistent是不给它家目录，因为服务根本不需要家目录，省得多个服务账号都在/home下占地方。

创建普通用户时我还习惯显式指定附加组和注释：

useradd -G wheel -c "张三" zhangsan

-G wheel把用户加入 wheel 组（在 RHEL 系里，wheel 组默认可以 sudo），-c写描述信息，方便以后辨认这个账号是干什么的。有些人建了一堆账号后不看描述，过几个月连自己都分不清哪个是哪个，全靠注释信息救命。

2.2 修改用户：usermod 的几个高危参数

usermod能改一个用户几乎所有的属性，但有三个参数在线上操作时要小心：

usermod -L zhangsan # 锁定用户 usermod -U zhangsan # 解锁用户 usermod -e 2025-12-31 zhangsan # 设置账号过期时间

-L锁定相当于在/etc/shadow密码字段前加一个!，用户即使知道密码也登录不了。这常用于员工离职、账号被借用等场景。锁定时建议同时把该用户占用的会话踢掉，否则已经登录的会话不受影响，锁了等于没锁。

-e设置过期时间适合临时账号、外包账号、测试账号，到期后自动失效，不用人工去删。我可以直接把这条命令写进运营规范里，避免有人创建测试账号后忘了回收。

还有一个高频场景是改家目录：

usermod -d /data/home/zhangsan -m zhangsan

-d改家目录路径，-m把旧家目录的内容迁移过来。不写-m的话，用户登录后会发现自己在空目录里，之前的文件全“丢”了，其实只是路径没搬。

2.3 删除用户：删前必须确认的 3 件事

删除用户是最不可逆的操作，手滑删错就麻烦了。我执行删除前一定会先做三件事：

1. 确认这个用户是否还有进程在跑：ps -u zhangsan
2. 确认这个用户拥有哪些文件：find / -user zhangsan（如果不加-user，删掉的只是账号，文件仍然留存在系统里，用户 ID 会变成数字显示）
3. 确认是否真的要连家目录一起删：

userdel zhangsan # 只删账号，保留家目录 userdel -r zhangsan # 删账号同时删家目录和邮件池

生产环境里我很少直接用userdel -r，因为你不知道这个用户是否还有别的目录下的文件。删账号前先find列出来，把有用的迁移走，再把无主文件改成其他用户或删除。尤其要注意用 UID 找文件后，在用户删除后再找就不好定位了，所以顺序一定是：先备份和迁移->再删除用户。

2.4 组的管理：四条命令覆盖 90% 需求

组的增删改查比用户简单得多：

groupadd project # 新建组 groupadd -g 2000 project # 指定 GID 新建组 groupmod -n projectnew project # 组改名 groupdel project # 删除组 gpasswd -a zhangsan project # 加人进组 gpasswd -d zhangsan project # 把人从组里踢出

usermod -G也可以把人加进组，但它会把用户之前的附加组整个替换掉。如果你想让用户保留原有附加组，同时新增一个组，必须把新旧组一起写进-G参数：

usermod -G wheel,project zhangsan

实际我更喜欢用gpasswd -a，这种增量式添加安全得多，不用每次先查询旧组列表再拼参数。

2.5 配置文件直接编辑：什么时候可以用

虽然前面说了用命令更安全，但某些情况下直接编辑/etc/group和/etc/passwd反而高效：批量添加几十个用户时，写脚本调useradd循环是最稳的；但如果你需要一次性把一群人同时加入某个组，用vigr或vipw编辑对应的文件也不失为一种办法。

注意，visudo、vipw、vigr这几个命令是带锁定的编辑工具，编辑时会锁文件，并做基本语法校验，防止两个管理员同时改文件导致冲突。但直接vim /etc/passwd这种没有锁，我不推荐在任何多管理员环境里这么干，改坏了 Shadow 文件用户就全登不上去了。

3. 文件权限体系：rwx 不是三个字母那么简单

账号建好后，真正天天打交道最多的是文件权限。Linux 里一切皆文件，权限自然也就是文件的权限。你读一个目录、执行一个脚本、删除一个临时文件，每一步背后都有权限校验。

3.1 rwx 对文件和目录含义完全不同

rwx三组九个字母，拆开来看：

• r：读权限。
  • 对文件来说就是能查看内容（cat）。
  • 对目录来说，表示能列出目录里的文件名（ls），但注意：仅有 r 权限的目录，你能看到文件名列表，却不一定能查看文件的详细信息，因为查看 inode 元数据需要 x 权限。
• w：写权限。
  • 对文件来说就是能修改文件内容（vi改写）。
  • 对目录来说，表示能在目录里创建、删除、改名文件。这点经常有人搞混：一个文件本身是只读的，只要它所在目录有 w 权限，你依然能删除这个文件。因为删除操作改的是目录的目录项，不是文件本身。
• x：执行权限。
  • 对文件来说就是能执行它（如果它是可执行程序或脚本）。
  • 对目录来说，表示能进入目录（cd），并且能访问目录内文件的 inode 信息。

大多数权限问题的根源就是没搞懂“目录的 w 权限决定删除权”这个事。比如你把一个文件设成 644（属主可读写，组和其他人只读），但它所在的目录是 777，那任何能进目录的用户都能删掉它。所以临时目录不能随便开放写权限，除非你接受里面的文件随时被清空。

3.2 chmod 的数值法和符号法：现场怎么选

chmod有两种设置方式。数值法最常用：

chmod 754 file

754 拆开是：属主 7（rwx）、属组 5（r-x）、其他 4（r--）。数值的计算其实就是二进制组合：r=4、w=2、x=1，相加得到最终数值。7=4+2+1，5=4+1，4=4。这个方法简单、直观、可复制，我写脚本基本都是用它。

符号法则适合调试时就地修改：

chmod u+x file # 给属主加执行权限 chmod g-w file # 去掉属组的写权限 chmod o=rx file # 把其他人的权限设为 r-x

有人会问到底用哪种好。我的建议是：写入脚本、配置、文档里的权限统一用数值法，方便审计和对比；临时排查问题时用符号法，不用心算，直接按意图加减。另外注意chmod -R递归改权限时，要当心把一堆不该变的文件权限也改了。如果只想改目录的权限，不想动目录里的普通文件，最好分开操作，别图省事一把梭。

3.3 chown 和 chgrp：属主和属组必须配套考虑

chown更改属主，chgrp更改属组。实际上chown可以一步完成两个操作：

chown zhangsan:project /data/project

这个写法把属主改成 zhangsan，属组改成 project。写成zhangsan:project，中间冒号千万别漏。如果只想改属主，chown zhangsan file；只想改属组，chown :project file。

改权限的一个核心原则是：先确认目标目录现有权限，再决定改法。比如/data/project当前属主是 root，你想让 zhangsan 能管理这个目录：

chown -R zhangsan:project /data/project chmod -R 2770 /data/project

这里 2770 里的2是后面的特殊权限，先留个印象，下一节细说。-R递归要特别小心，别把目录里本不该归属调整的文件也顺手改了。我一般分两步：先chown把目录本身改了，再chown -R递归，但前提是目录内部没有其他用户私有文件。

3.4 umask：为什么新建文件默认是 644

Linux 里新建文件默认权限是 666 减去 umask 值，新建目录默认是 777 减去 umask 值。常规用户 umask 是 022，所以文件是 644（rw-r--r--），目录是 755（rwxr-xr-x）。

为什么文件默认没有执行权限？因为系统对新建文件强制去掉所有 x 权限，防止一创建就变成可执行状态，除非你用chmod主动加上。这也是安全设计，能有效避免你随手重定向输出到文件后不小心执行了它。

如果想更安全，可以把 umask 设为 027：

umask 027

这样新建的文件是 640，新建的目录是 750，组内其他人只能读文件不能写，系统其他人完全没权限。这在团队共享目录里很常用。注意 umask 是一次性设置，只影响当前 Shell 会话；想永久生效得写到/etc/profile或/etc/bashrc里，建议全局统一的写在/etc/profile.d/下的脚本里，方便维护。

4. 特殊权限和 ACL：突破普通权限模型的最后三板斧

普通 rwx 满足不了所有业务需求。比如可执行程序需要临时获得文件属主的权限、多用户共享目录里需要禁止互删文件、某个用户要精准分发某目录访问权而其他人不受影响。这三类问题分别对应 SUID、SGID、Sticky 位，以及 ACL。

4.1 SUID：执行时临时变身

SUID 一般设置在可执行文件上，效果是：当其他用户执行这个程序时，进程的有效 UID 临时变成文件属主的 UID。

最经典的例子是passwd：

ls -l /usr/bin/passwd -rwsr-xr-x 1 root root 63840 ...

注意属主的 x 位变成了s，这就是 SUID 标志。普通用户执行passwd时，进程以 root 身份去修改/etc/shadow，所以普通用户才能改自己的密码。没有 SUID，普通用户根本无法写入只有 root 能写的 shadow 文件。

设置 SUID：

chmod u+s /path/to/file

不建议在生产环境随便设置 SUID，尤其是给一些自定义脚本或二进制，相当于给任何人一个“绕过属主权限”的后门。我见过有人给一个 Python 脚本设了 SUID，脚本内部还能执行任意系统命令，这等于把 root 权限明晃晃地放在普通用户面前，非常危险。如果要设，必须评估脚本本身有没有漏洞、可写目录是否可控、是否会被替换。

4.2 SGID：目录上最好用的继承机制

SGID 有两种影响：

• 设置在可执行文件上：执行时临时获得文件属组的 GID。
• 设置在目录上：在这个目录下新建的文件（或子目录），其属组自动继承目录的属组，而不是创建者自己的主组。

第二种用法在团队协作里是神器。比如目录/data/project，属主是 root，属组是 project，权限是2770（即rwxrws---）。里面的s就是 SGID 位。zhangsan 在这个目录下新建的文件，属组自动是 project，团队里其他人只要在 project 组里就能编辑。这解决了“新文件属主组不对导致组员写不了”的痛点。

设置方法：

chmod g+s /data/project

注意：SGID 只保证属组继承，不保证权限继承。新建文件的权限依然受 umask 控制。如果你希望所有新文件默认权限统一为 640（组可读写），umask 必须设成 027。所以 SGID + 合理 umask 才是完整方案。

4.3 Sticky 位：共享目录防删的定海神针

Sticky 位通常设置在公共目录上，如/tmp。效果是：目录里创建的文件，只有文件属主（或目录属主、root）能删除或改名，其他用户即使对目录有写权限也毫无办法。

/tmp的权限是drwxrwxrwt，最后的t就是 Sticky 位。因为/tmp是全世界都能写的，如果没有 Sticky 位，任何人都能删别人的临时文件，系统根本没法用。

设置方法：

chmod +t /tmp

如果是数值法，Sticky 位对应数值 1，写在最前面，如 1777。SGID 对应 2，SUID 对应 4，所以：

chmod 2770 /data/project # SGID + rwxrws--- chmod 4755 /usr/local/bin/tool # SUID + rwsr-xr-x chmod 1777 /tmp/shared # Sticky + rwxrwxrwt

这三个特殊权限在ls -l中有时候显示为小写s/t，有时候是大写S/T，区别在于对应的 x 位有没有设置。小写表示 x 和特殊权限同时存在；大写表示只有特殊权限但没有 x。比如rwsr-xr-x的s小写，说明属主有 x；如果显示rwSr-xr-x，说明属主没有 x，SUID 对文件没有任何实际意义（不能执行）。

4.4 ACL：把权限精确到单个用户

普通权限最多管到“属主、属组、其他人”这三类，但现实中往往需要“给某个特定用户单独授权”。ACL（Access Control List）就是干这个的。

比如目录/data/share当前权限是770，属主 root，属组 dev。现在张三需要单独对这个目录有读写权限，但你不能把张三加进 dev 组（因为 dev 组里还有李四、王五，你不想让李四他们看到张三的东西），这时用 ACL：

setfacl -m u:zhangsan:rwx /data/share

查看当前 ACL：

getfacl /data/share

输出里会有类似user:zhangsan:rwx的条目，这说明对该用户单独授权成功。ACL 设置后，目录或常见的ls -l权限后会出现一个+号：

drwxrwx---+ 2 root dev 4096 ...

注意事项：

• 使用 ACL 需要文件系统支持，主流文件系统（ext4、xfs）默认支持，挂载时确认没加noacl就行。
• ACL 对目录有继承能力，通过setfacl -m d:u:zhangsan:rwx /data/share可以设置默认 ACL，之后所有新建文件都会自动带这条 ACL。
• cp命令默认不保留 ACL 和特殊权限（除非加-p），备份时如果用了tar，也要注意加--acls选项，否则备份再恢复后 ACL 就丢了。

ACL 是普通 rwx 模型的有效补充，但它也带来排查复杂度。文件出问题后你可能要同时检查基本权限、特殊权限、ACL 三层叠加情况。所以能用组解决的优先用组，别一上来就用 ACL 到处授权，否则后期管理会越铺越乱。

5. sudo 权限委托：把 root 权力安全地切成小块

日常运维中我们不应该直接登录 root 使用系统，因为 root 权限太大，一个误操作可能毁了整个系统。但普通用户又需要执行一些只有 root 才能做的管理操作，比如重启服务、改系统配置。sudo 就是解决这个矛盾的。

5.1 sudo 的核心设计：让用户“临时”变成管理者

sudo 允许授权用户以 root（或指定用户）身份执行命令。执行时会要求验证用户自己的密码（不是 root 密码），验证通过后在时间窗口内执行，默认 5 分钟不用重复验证（可配置）。

sudo 和 su 的差别：

• su 是切换用户，需要目标用户的密码，切过去之后就是一个完整的 Shell，期间所有命令都以目标用户身份执行，难以审计。
• sudo 只在执行单条命令时提权，命令结束后恢复普通用户，且所有执行记录都会写进/var/log/secure（RHEL 系）或/var/log/auth.log（Debian 系）。

生产环境我几乎只推荐 sudo，不推荐 su。因为 sudo 做到了最小指令授权，每条命令独立审计，出事之后能查谁在什么时候执行了哪条命令。su 以 root 身份一开就是一个长会话，中间干的事全靠操作者自觉，后期追溯极难。

5.2 sudoers 配置：从简单到正规

sudo 的配置在/etc/sudoers，官方强烈建议用visudo修改，因为它会自动检查语法，写错了还提示你选择不改。直接vim改，万一语法出错会导致所有用户都失去 sudo 能力。

最简单的配置：在 sudoers 里加一行：

zhangsan ALL=(ALL) ALL

意思是：用户 zhangsan 可以在任何主机上，以任何用户身份，执行任何命令。这相当于给了完整 root 权限，虽然方便，但没体现 sudo 的价值。

推荐按组给权限：

%wheel ALL=(ALL) ALL

%wheel表示 wheel 组的所有成员都可以全权 sudo。很多发行版默认注释了这行，你取消注释即可。

更精细的限制是只允许执行特定命令。比如让运维用户只能重启 nginx 服务，不能执行其他 root 命令：

zhangsan ALL=(ALL) /usr/bin/systemctl restart nginx, /usr/bin/systemctl status nginx

这样即使账号被盗，攻击者也最多就是重启服务，干不了更危险的事。缺点是命令路径必须写全，否则匹配不上。某些命令（如vim）提权后会以 root 身份打开文件，这等于变相给了写任意文件的能力，要特别小心。

sudoers 还支持别名，比如定义一组用户、一组命令，方便大规模管理：

User_Alias OPS = zhangsan, lisi, wangwu Cmnd_Alias SERVICE = /usr/bin/systemctl restart nginx, /usr/bin/systemctl status nginx OPS ALL=(ALL) SERVICE

这个配置把三个运维成员统一授权为只能管理 nginx 服务。如果以后加新人，只要把用户名加进OPS里就行，不用逐个维护多行。

还有几个常用选项：

• NOPASSWD：让用户执行 sudo 时不输入密码，适合批处理脚本用。
• !：禁止某条命令。注意顺序很重要，sudoers 是自上而下匹配的，改成zhangsan ALL=(ALL) ALL, !/usr/bin/passwd root的写法，前面一条ALL已经把完整权限给了，后面的!并不能覆盖，因为 sudoers 默认取最后一个匹配，但实际使用中这种写法很危险，我建议不要用ALL然后去排除，而是用白名单方式列出允许的命令。

5.3 sudo 常见问题：权限被拒、找不到命令、安全上下文

排查 sudo 问题时第一反应当然是看/etc/sudoers里该用户或该组有没有对应条目。常见坑有几个：

• 用户名写错，导致 sudo 完全不认账。
• 命令路径不对。systemctl在/usr/bin/systemctl，但有些系统可能在/bin/systemctl，写错路径就匹配不上。
• 环境变量问题。执行sudo systemctl时如果secure_path没有包含/usr/bin，可能提示 command not found。此时可以看/etc/sudoers里Defaults secure_path=...配置。
• 提示 “xxx is not in the sudoers file”。说明该用户没授权，要么加到%wheel组，要么加进 sudoers 文件。

我养成的一个好习惯是给关键管理员账号配置独立审计标识，比如让每个运维人员都有自己的账号，而不是共用 root 或共用某个 sudo 账号。这样/var/log/secure里的记录能精确到人。

6. 常见问题排查与安全加固实战

权限问题让人头疼的地方在于，出错时日志往往只告诉你“Permission denied”，却不告诉你具体是哪个环节被卡住。下面整理我平时排查权限问题时的一套动作和几个高频场景。

6.1 万能排查五步法：先定位再解决

碰到权限问题时，按顺序检查这五层：

1. 当前用户身份：id，确认 UID、GID、附加组。
2. 目标文件基本权限：ls -l或stat，确认属主、属组、rwx、特殊权限位。
3. 目标文件 ACL：getfacl，确认有没有单独授权给某个用户或组。
4. 目录权限链：不只是看目标文件本身，还要看它所在的每一层目录是否具备进入权限。比如/data是 700，/data/project是 777，普通用户照样进不去，因为第一层/data就把人拦住了。
5. SELinux（如果开启）：ls -Z看文件的安全上下文，ausearch -m avc看拒绝日志。

我踩过无数坑，最后的终极 bug 往往是 SELinux。比如 nginx 监听 8080 端口，SELinux 默认只放行 80、443 等端口，你手动改了 nginx 配置监听 8080，启动时没报错，但实际访问被拒绝，看日志才发现是 SELinux 拦截。这种问题如果没经验，排查半天都怀疑不到 SELinux 头上，所以开启 SELinux 的系统，第一反应就应该用getenforce看一下状态。

6.2 忘记密码的恢复：紧急又容易翻车

忘记 root 密码基本是每个运维都经历过的。传统做法是重启进单用户模式，现代发行版则是在 grub 启动项里加rd.break或init=/bin/bash。这里不谈具体按键流程，只讲几个核心禁忌：

• 千万不要让任何人物理接触服务器就轻易拿到 root 权限，除非你有保密要求。单用户模式不需要密码就能进入，所以服务器物理安全非常重要。机房的机器一定要在 BIOS 设置引导密码或开启磁盘加密（如 LUKS）。
• 进单用户模式后改密码前，一定要先mount -o remount,rw /，把根文件系统重新挂载为可写，否则passwd会写不进去。
• 如果改的是普通用户密码而你有 root 权限，直接passwd zhangsan就行，不需要知道旧密码。

6.3 服务启动失败：权限目录和日志两手抓

nginx、MySQL、Redis 这类服务启动失败，十有八九和权限有关。我排查时先看服务日志：

journalctl -u nginx.service -n 50 tail -n 50 /var/log/nginx/error.log

日志里出现Permission denied，再按五步法检查。常见场景：

• 日志目录属主不是服务用户，比如 nginx 默认用nginx用户跑，但日志目录属主是 root，导致写不了日志，服务直接退出。
• 运行目录/var/run/nginx属主不对，或者说 socket 文件创建不了。
• 配置里指定的文件路径不存在或权限过严。

我自己的排查口诀是：“进程身份、文件属主、目录链路、SELinux 上下文”四个字一起查。先看ps -ef | grep nginx确认进程跑在哪个用户下，再看这个用户对目标路径从根目录逐层有没有 x 权限。逐层ls -ld / /var /var/log /var/log/nginx，一般很快定位。

6.4 防患于未然的安全加固清单

账号和权限是系统安全的基础防线，我每次初始化服务器都会执行下面这套规则：

1. 禁用 root 远程登录：/etc/ssh/sshd_config里设PermitRootLogin no，然后重启 sshd。所有管理员用普通账号登录，再 sudo 提权。
2. 所有管理员加入专用管理组：如wheel，并在 sudoers 里给全组授权。不单独给个人加 sudo 权限，方便撤销。
3. 启用密码策略：在/etc/login.defs里设置密码最长使用天数、最短使用天数、最小长度，同时要求所有用户定期改密码。
4. 关闭无用账号：用awk -F: '{if ($3==0) print $1}' /etc/passwd检查 UID 0 的账号，除了 root 不应有第二个 UID 0 账号。
5. 定期检查系统用户：ps -eo user,pid,cmd | sort -u | less看系统里有没有可疑进程的属主。
6. 临时权限快照：对于重要目录，定期用getfacl -R导出 ACL 和基本权限，发生变更后做 diff，能快速发现权限被篡改的迹象。
7. 敏感命令审计：在 sudoers 里把危险命令（如vim、chmod、chown）单独列出来，并给它们设置日志审计，确保每次调用都有记录。

这些措施并不复杂，成本也低，但在被入侵时能显著提高攻击门槛。权限加固不是一次性做完就结束了，而是要在每次变更、每次上线、每次巡检中都重新审视。

个人实操感想

用了这么多年 Linux，我最大的感受就是：账号和权限管理不是几个命令的组合，而是一套贯穿系统生命周期的安全思维。创建用户时多想一句“这个用户需要什么权限”，配置 sudoers 时多想一句“这条命令会不会被滥用”，部署服务时多想一句“服务用户和文件属主是否一致”，大部分线上权限事故都能从源头避免。踩过的坑最深的有两个：一是只给了目录 777 没考虑后果，后来日志被清空、被别人放了恶意脚本；二是改了文件属主后没注意目录链路权限，导致服务怎么启动都失败，最后才意识到问题出在父目录的 x 权限上。所以我现在不管做什么权限操作，都习惯先用ls -ld把每一层目录过一遍，确认执行链路通，再继续下一步。这套习惯看似慢，但确实救过我很多次。如果你也想彻底掌握 Linux 的“人”和“权限”体系，建议自己搭一台虚拟机，从建用户开始，到配 sudoers、设 ACL、调特殊权限，全部走一遍，遇到 Permission denied 再回头按五步法排查，比看十篇文档都管用。