4.1 用户管理全流程
4.1 用户管理全流程
本节摘要：账号管理的完整生命周期包括创建、登录配置、密钥绑定、锁定与回收， passwd 文件记录每个账号的身份与认证信息。本节从一次 SSH 暴力破解事件讲起，覆盖登录账号与系统账号的区别、密钥登录基线、离职回收流程与账号体检清单。
事故现场：日志里四万次失败登录
某团队的一台公网测试机，某天安全同事例行检查登录日志，一条命令拉出统计：
grep "Failed password" /var/log/auth.log | awk '{print $(NF-3)}' | sort | uniq -c | sort -rn | head -5
41203 185.220.101.45 8812 45.155.205.233 2214 141.98.10.62
一个地址四万一千次失败登录——教科书级的暴力破解尝试。2.2 节的文本流水线在这里换了战场，方法原样复用。进一步的坏消息是成功记录里也有可疑条目：
grep "Accepted password" /var/log/auth.log | tail -5
Aug 16 03:41:02 sshd[20981]: Accepted password for deploy from 185.220.101.45 port 51022 ssh2
攻击者用同一个地址成功登录了 deploy 账号——密码是弱密码，被字典撞开了。所幸是测试机，但排查与加固的完整流程值得走一遍，因为它就是本节的目录：攻击者进来了多久、干了什么、怎么堵上、怎么防复发。
时间线分析显示登录发生在凌晨三点四十一分，之后的操作记录里只有翻看目录与一次下载配置文件的动作，没有提权痕迹。处置四连：立即改密码并锁定账号、换成密钥登录并关闭密码认证（1.3 节已经建过密钥体系）、把攻击网段加入防火墙黑名单、全环境排查同密码的机器。加固七件套在后面各节逐一展开。
一、账号的本质：一个数字身份
Linux 里用户名只是给人看的，内核认的是用户标识号。看本机账号概况：
cut -d: -f1,3 /etc/passwd | head -6
root:0 daemon:1 bin:2 sys:3 deploy:1000
零号是 root，一号到九百九十九大多保留给系统账号——运行服务的专用身份，3.2 节里的 svc-app 就是这类。一千以上是人类账号。系统账号的设计思想是隔离：服务进程用自己的低权限身份跑，被攻破时伤害有限。这就是最小权限原则在账号层的落地。
passwd 文件每行七列，值得逐列认识一遍，它是账号体检的主要对象：
deploy:x:1000:1000:Deploy Operator:/home/deploy:/bin/bash
依次是：用户名、密码占位符（x 表示真密码在影子文件里）、用户标识号、组标识号、备注全名、家目录、登录 Shell。最后一列信息量极大——nologin 这个值意味着账号不能交互登录，服务账号的标准配置；改成它，一个账号就从"能登录的人"变成"只能跑进程的身份"。
影子文件单独存密码哈希与时效策略，权限只许 root 读——密码体系的核心保护。 ageing 字段控制密码过期天数、最短更换间隔、到期前警告期，企业环境的密码策略就落在这里。
二、创建账号：每一步都是安全决策
创建一个人类账号：
sudo useradd -m -s /bin/bash -c "后端开发 张三" zhangsan sudo passwd zhangsan
m 建家目录，s 指定 Shell，c 写备注——备注列写清姓名与角色，半年后你才认得这个账号是谁。passwd 设置初始密码，有的团队强制首次登录改密，稳妥。
创建一个服务账号，参数取向完全不同：
sudo useradd -r -s /usr/sbin/nologin -d /opt/app svc-app
r 表示系统账号，取一个低段标识号；Shell 直接设为不可登录；家目录指向应用目录而非家目录区。两个命令的对照就是两种身份的设计逻辑：人类账号要能登录好管理，服务账号要不能登录够安全。
账号信息核验与修改：
id zhangsan
uid=1001(zhangsan) gid=1001(zhangsan) groups=1001(zhangsan)
id 输出的 groups 列表是权限判定的直接依据——3.2 节的属组判定就查这里。改账号用 usermod，最常见的操作是把用户加进某个组，留给 4.2 节展开。
三、密钥登录：从"改强密码"到"不用密码"
暴力破解的根源不是密码不够长，是密码这种凭证本身可被穷举。密钥是不可穷举的：私钥不离开你的电脑，服务器只存公钥，登录时用数学挑战应答代替口令传输。1.3 节演示过密钥的生成与分发，这里补齐管理面。
给新同事开账号的标准动作三连：建账号、放公钥、验证登录：
sudo mkdir -p /home/zhangsan/.ssh sudo cp /tmp/zhangsan-id-ed25519.pub /home/zhangsan/.ssh/authorized_keys sudo chmod 700 /home/zhangsan/.ssh sudo chmod 600 /home/zhangsan/.ssh/authorized_keys sudo chown -R zhangsan:zhangsan /home/zhangsan/.ssh
两条权限命令不是洁癖：SSH 服务对授权文件的权限有硬性要求，太开放会直接拒绝密钥认证——这是"配了密钥还是提示密码"的第一嫌疑现场。装完公钥，关闭密码登录（1.3 节的配置改法），这个账号从此免疫字典攻击。
⚠️ 常见坑：公钥复制后忘记改属主与权限，密钥登录静默失败，回退到密码登录，而你以为已经安全了。验证动作必不可少：改完配置后开新会话确认"密钥能进、密码被拒"，两个方向都验才算数。
四、回收：离职比入职更重要
账号安全的最大黑洞不是黑客，是离职账号。人走了账号还能登录，等于给前员工留了一把没收回的钥匙。标准回收流程四步：先改密锁定（保数据留取证），再禁用登录，限期后归档数据删除账号。
sudo usermod -L zhangsan
L 选项在密码哈希前加一个感叹号，账号立即无法通过密码认证——影子文件里的这个小符号就是锁。确认无遗留后删除：
sudo userdel -r zhangsan
r 连家目录与邮箱一起清掉。删除前务必确认没有属主是他的在役文件——3.2 节讲过属主错位的后果。查漏一条命令：
sudo find / -xdev -uid 1001 2>/dev/null
uid 参数按数字身份找文件，比按名字找更彻底——名字可以重复，数字不会。找出的文件 chown 移交给继任者后再删账号。
把回收与入职流程对齐成清单：入职当天建号、装钥、进组、告知规范；离职当天锁号、次日复查、七天内清档。两端都写进交接文档，账号治理就有了制度闭环。
图 4-1 账号生命周期与安全基线
常见疑问解答
root 账号能删掉吗
不能也不必。内核与无数工具默认 root 存在，删了系统残废。正确做法是让 root"够不着"：禁止远程登录、本地也仅救援时用、日常一切操作走 sudo。root 从日常操作里消失，它就从一个风险点降级成一个休眠的系统机制。
共享一个团队账号不是更方便吗
短期方便，长期灾难。共享账号的第一宗罪是不可审计——出了问题查到的是"大家"，等于没人；第二宗罪是不可回收——一个人离职就要改全员密码。正确的共享在文件层（4.2 节的组与共享目录），从不在身份层。一人一号是底线，没有例外。
密钥比密码安全 那密钥丢了怎么办
私钥丢失等于钥匙丢了：立刻从服务器的授权文件里删掉对应公钥那一行，风险即解除——这正是密钥体系的优雅之处，撤销是精准的、按行的。然后生成新钥重新部署。所以授权文件的管理要像账本：谁的一行、何时加的、为什么加，注释清清楚楚。
服务账号需要设置密码吗
不需要。服务账号不交互登录，密码字段直接置锁定状态，认证路径整个关闭。给它设密码反而是多开了一扇没人看门的门。
怎么知道哪些账号能登录
看 passwd 文件最后一列：Shell 是 nologin 或 false 的不能登录，是正常 Shell 的能。再配合影子文件看锁定标志。两文件交叉一筛，可登录账号名单立等可取——这个名单应该和你的在职人员名单严格一致。
五、账号与自动化：配置管理的入场
账号管理做到十几台机器规模时，手工逐台操作就到极限了：新同事入职要登二十台机器建号，离职要再登一遍删号，漏一台就是漏洞。出路是配置管理——把"机器上应该有哪些账号、哪些公钥、哪些组关系"写成声明式的清单，用自动化工具（常见的几种开源方案皆可）批量执行与校对。清单即文档，执行即审计，漂移即告警。这一步是运维从"操作员"到"工程师"的分水岭：你不再逐台敲命令，而是维护一份"系统应该长什么样"的描述。账号是最适合先做自动化的对象——它结构简单、变更频繁、出错代价高，三个特征全中。本章的命令你都要熟，但熟的目的不是当人肉复读机，而是知道自动化工具在底层替你做了什么。工具坏了你要能手工接上，这是自动化的前提素养。
账号管理还有个经常被低估的维度：命名规范。账号名用姓氏拼音还是工号、服务账号是否统一前缀、临时账号如何标记有效期，这些约定写在纸上是几行字，落到实践里是查询效率与审计准确率。统一了命名，找出所有临时账号、列出某服务的全部相关账号才是一条命令的事；各自为政的命名，每项检查都是考古。规范的价值从来不在优雅，在批量操作与自动化时的可预期性。
本节要点回顾
- 内核认数字身份 用户名只是外号：查漏按标识号，比按名字彻底
- 两类账号两种建法：人类账号好登录，服务账号不可登录，参数取向相反
- 密钥登录是免疫字典攻击的唯一解：配完必须双向验证，防静默回退
- 影子文件是密码策略的家：时效三字段落实企业密码制度
- 离职回收是账号安全的最大黑洞：锁号 查漏 清档 三步有期限
- 登录日志要定期统计：失败分布与成功来源，攻击会自己留下脚印
下一节把个体组织起来——组的设计与 sudo 授权，权力的分配与闸门。
补一个和入侵取证相关的小技巧：账号的登录痕迹不止在登录日志一处，家目录下的命令历史文件、最近访问时间戳、 authorized_keys 文件的修改时间，都是行为侧写的数据源。开篇那次事件的取证就用了组合拳：登录日志确定入侵时间窗，命令历史文件还原操作清单，公钥文件的修改时间证明攻击者留了后门钥匙（后门公钥被清除并记入报告）。取证时注意先做副本再分析，原始文件的时间戳本身就是证据——直接翻看都会更新访问时间。这些细节平时用不上，用上时就是关键。
最后说明账号管理与入职流程的衔接细节：理想状态下，账号创建应该由工单系统驱动——入职工单触发建号动作、离职工单触发回收动作，运维侧只消费工单不接收聊天软件里的口头申请。口头申请的最大问题是无法审计"谁批准的"，出了问题责任链断裂。工单驱动看似繁琐，实则把账号操作嵌进了公司的管理流程，运维的工作也从"被动响应"变成了"流程执行"。小团队没有工单系统时，退而求其次用共享表格登记申请与批准记录，也比口头强。