做了这么多年Linux运维我发现高级用户和普通用户的密码破解这个搜索词的热度一直很高。很多人把它理解成怎么把别人的密码搞到手但在安全这个圈子里研究破解从来不是最终目的搞清楚攻击者是怎么思考的、破解为什么能成功才是真正的价值所在。这篇文章我打算从权限模型、密码存储机制、攻击者视角到实际加固操作把普通用户和高级用户这套密码安全体系从头到尾讲一遍。适合Linux运维、安全工程师以及所有手里管着服务器账号的同学参考。1. 先搞清楚高级用户和普通用户到底差在哪1.1 权限模型Linux为什么要把用户分成三六九等Linux不是故意为难人它的用户隔离从Unix时代就定下了底层哲学。系统里每个用户都有一个UID用户IDroot的UID固定是0它不受任何权限检查限制可以读写任何文件、杀掉任何进程、修改任何配置相当于整个系统的万能钥匙。普通用户的UID通常从1000开始权限被限制在自己的家目录和系统明确授权的区域内。把这两类用户放在一起看root拥有全部权限操作失误会直接影响整个系统普通用户权限有限就算被攻破或者操作失误破坏范围基本可控。这正是Linux最小权限原则的体现。中间还有一个特殊类别sudo权限组Debian/Ubuntu系叫sudo组RHEL/CentOS系叫wheel组组里的用户平时是普通用户身份但可以通过sudo命令临时提权到root执行特定操作。这个设计比直接拿root干活优雅得多。用一个生活化的比喻普通用户像公司里持有自己工位钥匙的普通员工root像持有数据中心所有机柜钥匙的运维总监。而sudo用户则是有门禁卡、但每次刷卡都留记录的项目负责人——比普通员工权限大但每一步操作都有痕迹可查。1.2 密码存储机制破解到底在破什么很多刚入门的朋友对破解密码有个误解以为系统里存着你的明文密码破解就是想办法把它读出来。实际情况完全不是这样。Linux的密码哈希存放在/etc/shadow文件里只有root和shadow组能读。系统存储的不是密码本身而是密码加盐后经过哈希算法计算的摘要值。早期用MD5后来普遍换成SHA-512再新的系统开始用yescrypt、bcrypt这类慢哈希算法。这里说的盐salt是随机生成的一串字符串和密码拼在一起再做哈希计算目的是让同样的密码产生完全不同的哈希值防止攻击者用预计算结果批量反查。这就带出一个关键结论密码破解的本质不是反解密而是猜。攻击者拿到shadow文件里的哈希值之后只能不断用候选密码做同样的加盐哈希计算看结果是否与文件里的一致。因为哈希算法是单向的不存在把哈希还原成密码的数学捷径除非算法本身被发现有漏洞。所以破解速度快慢取决于候选密码的数量、哈希算法的计算开销以及攻击者手里的硬件算力。普通用户和root/高级用户的密码哈希存放在同一个shadow文件里格式长得一样但被攻破后的影响面天差地别。root密码泄露意味着系统完全沦陷攻击者可以清理日志、安装后门、读取所有数据普通用户密码泄露攻击者至少只能在一个有限权限范围内活动。这就是分层防御的意义所在。2. 从攻击者视角看密码为什么会被破解2.1 破解手段的底层逻辑一场概率游戏我不打算在这里展开任何攻击工具的使用教程但作为防御者你必须理解攻击者手里的牌。最常见的两类手段是字典攻击和暴力穷举。字典攻击的思路是大量真实世界的密码并不是随机生成的而是人的习惯产物——姓名、生日、键盘顺序、常见单词组合。攻击者把这些高频密码整理成字典逐个尝试。暴力穷举则不带任何先验知识把所有字符组合按长度挨个算一遍。两者可以结合使用先跑字典再对字典词做变形扩展最后上纯暴力。这里有个数学上的冷酷事实一个8位的纯数字密码组合数量是10的8次方用现代GPU每秒能算几亿次哈希几乎就是几分钟的事。而一个16位的大小写字母加数字加符号的随机密码组合数量直接膨胀到接近10的30次方量级攻击者面对的是指数级的困难。哈希算法同样决定破解成本。MD5和SHA-1这类老算法计算极快攻击者每秒可以跑几十亿次bcrypt、argon2这类慢哈希会故意把单次计算拖到几百毫秒破解速度骤降到每秒几次。这也是为什么近年新系统默认迁移到yescrypt这类算法的原因——让破解者付出更高的时间成本。2.2 真实攻击面弱口令和错误配置才是突破口说句得罪人的话绝大多数系统被攻破不是因为攻击者技术有多高明而是防守方给的破绽太明显。我自己在运维过程中见到的典型情况列几条管理员图省事给所有账号设同一个密码甚至直接就是123456这种弱密码服务器开在公网上SSH端口直接暴露root账号密码又简单测试环境用完不清理残留带默认密码的测试账号为了让同事方便操作顺手把所有用户都加进了sudo组还配置了免密sudo家用路由器后台还在用出厂默认的admin/adminWiFi密码本身也是8位纯数字。这些单看每个都感觉没那么严重但凑在一起就等于把系统大门的钥匙挂在了门框上。密码破解这个热门话题背后真正的风险几乎都不是技术被突破而是习惯太差。3. 实操把普通用户加入sudo权限组与正确提权3.1 为什么推荐sudo而不是直接切root很多刚接触Linux的朋友喜欢拿到服务器就root登录然后一路到底。我不建议这个习惯原因有三点第一是审计。sudo会把每次提权执行的命令、时间、发起用户完整记录到日志里出问题能追溯到具体的人。直接在root下操作所有操作混在一起出了事很难还原现场。第二是最小权限。用sudo可以精确控制允许谁、在哪台机器、执行什么命令不需要一次性交出全部管理员权限。给开发同事临时开放某个服务根本不需要让他拥有完整的root能力。第三是密码安全。团队协作时sudo模式不需要分享root密码每个人用自己的账号提权密码泄露面小得多。一旦有人离职只需要禁用那一个人的账号不用全世界换一遍root密码。多用户环境里我一直坚持能不用root就不用root能用sudo解决的问题绝不直接切root。3.2 具体操作加组、配置、验证把普通用户加入sudo权限组标准做法是这样以Ubuntu/Debian为例# 把用户加入sudo组-a 表示追加-G 指定附加组 sudo usermod -aG sudo username # 验证用户是否已进入该组 groups username # 切换为该用户后测试提权 sudo -l如果要给某个用户更精细的提权范围用visudo编辑/etc/sudoers文件。这里有个重点千万不要直接拿vim改sudoers语法错了会直接导致所有sudo不可用后果很严重。visudo在保存前会做语法校验是唯一安全的编辑入口。# 允许dev用户免密执行systemctl命令仅示例生产环境慎用免密 dev ALL(ALL) NOPASSWD: /usr/bin/systemctl这里必须专门提醒一个坑很多教程喜欢教人配NOPASSWD免密sudo觉得省事。但在共享环境里免密sudo意味着任何拿到普通用户会话权限的人都能直接提权成root等于绕过了密码防护这一层。我的建议是除非是特定自动化脚本的运行账号而且运行环境完全可控否则不要用NOPASSWD。关于把普通用户变成root这个需求我理解大家方向有两个一是日常操作想要root的全部权限这个用sudo就够了二是确实需要长期以某个特权身份运行程序那就需要把普通用户提升为管理员本质还是加sudo组。直接把某个用户的UID改成0这种做法极度危险在生产环境千万不要试。RHEL/CentOS系对应的组名是wheel操作命令完全一致只是组名不同sudo usermod -aG wheel username加组之后建议立刻验证两件事用新用户登录执行sudo whoami确认能返回root再检查一遍/etc/sudoers里有没有多余的全局配置。很多权限事故都是因为加了个组就不管了。4. 密码策略与系统加固让破解无从下手4.1 密码复杂度这种基础功课系统层面怎么落实你可能会说密码复不复杂是用户自己的事系统管不了。但作为管理员系统层面完全可以强制密码策略靠的就是PAM模块。以Ubuntu为例修改/etc/pam.d/common-password可以配置密码的最小长度、复杂度要求、历史记录# 密码最小长度16位包含至少一个数字、一个大写字母、一个小写字母和一个特殊符号 password requisite pam_pwquality.so retry3 minlen16 dcredit-1 ucredit-1 lcredit-1 ocredit-1再配合/etc/login.defs里的密码有效期配置PASS_MAX_DAYS 90 PASS_MIN_DAYS 7 PASS_WARN_AGE 14PASS_MAX_DAYS控制密码最多用90天PASS_MIN_DAYS防止用户被要求改密码后马上改回原密码PASS_WARN_AGE提前14天提醒。这套组合能解决大部分密码长期不换的问题。这里有个容易忽略的细节login.defs只在用户下次修改密码或管理员强制修改时生效不会立刻让存量密码失效。如果想立即让某个用户下次登录就改密码用chage命令chage -d 0 username还有一个坑很多系统配了复杂度但用户每次改密码都在旧密码123456和新密码1234567之间反复横跳等于没换。配置pam_pwhistory模块让系统记住最近5次密码才能从机制上堵住这个漏洞。4.2 服务层面加锁SSH、fail2ban与日志审计密码防护不能只靠账号体系本身服务层面的加固同等重要。先拿最常被爆破的SSH来说有几个必做操作# 编辑 /etc/ssh/sshd_config PermitRootLogin no # 禁止root直接SSH登录 PasswordAuthentication no # 禁用密码登录只允许密钥认证 MaxAuthTries 3 # 单次连接最多尝试3次 AllowUsers specific_user # 白名单只允许特定用户登录禁止root直接SSH登录应该算所有服务器的默认基线。攻击者爆破root既没有审计留痕又直接影响系统最高权限把这条路封死配合sudo提权既安全又不影响管理效率。其次是fail2ban。它会监控认证日志发现同一个IP短时间内反复认证失败就自动封禁一段时间。配置文件一般在/etc/fail2ban/jail.local针对SSH的默认配置就够用核心参数是maxretry和bantime。我建议maxretry设为5bantime设为3600秒既拦截了爆破又不会误伤正常用户。最后是日志审计。定期查看/var/log/auth.logDebian系或/var/log/secureRHEL系重点关注异常登录IP、非工作时间的大量失败记录。配合last和lastb命令查看成功和失败的登录历史last -20 # 最近20条成功登录记录 lastb -20 # 最近20条失败登录记录需要root我见过不少团队安全设备买了一堆但日志从来不看。系统安全不是一个装上就完事的状态而是一个持续观察和响应的过程。哪怕每天只花两分钟扫一眼认证日志都能发现很多隐患。5. 常见问题与排查技巧实录5.1 密码过期用户又不在本地远程怎么处理运维中很常见的一个场景某用户密码过期下次登录被强制要求改密码。如果他在本地终端还好办但如果只能通过SSH远程登录就会陷入密码过期无法登录无法登录无法改密码的死循环。实际上SSH登录时只要密码还没被禁用通常会被提示Permission denied (publickey,password)或者直接给出必须修改密码的提示部分配置下是可以在登录过程中直接改的更稳妥的办法是管理员用root登录执行chage -d 0 username让该用户下次登录时必须改密然后让用户配合在可交互终端完成修改。如果服务端禁用了root SSH那就只能通过其他已授权管理通道处理或者临时配置一次安全的管理员会话。这类场景的处理思路核心是先确保管理员自己有不受影响的通道再对受困用户做定向操作。5.2 sudoers配置出错把自己锁在外面怎么办这是每个Linux运维迟早会遇到的事。手动编辑/etc/sudoers时一个语法错误可能导致所有sudo命令无法执行甚至连sudo visudo都跑不了因为visudo本身也需要提权。解决方案分两种。如果本机还有另一个能登录的管理员账号且它在sudo组里直接登进去用root权限修复即可。如果整个sudo功能都瘫痪了只能重启进入单用户模式recovery mode在root shell里修正sudoers文件。为了防止这种情况我养成了一个习惯每次改sudoers之前先备份一份cp /etc/sudoers /etc/sudoers.bak.$(date %F)然后用visudo -c做语法检查确认无误后再退出。即使这样我还是建议在远程管理服务器上保留至少一个可以直接以root登录的备用通道关键时刻能救命。5.3 问题速查表现象常见原因处理建议用户突然无法sudo不在sudo组或被sudoers规则限制用root或管理员账号检查组和sudoers配置SSH频繁被爆破公网暴露且开启密码登录禁用密码登录、启用密钥认证、配置fail2ban用户忘记密码长期未更新或记录丢失管理员执行passwd username重新设置并评估是否启用定期改密策略密码符合要求但仍提示太弱PAM复杂度策略与login.defs不匹配统一检查pam_pwquality和pam_pwhistory配置新用户被拒绝登录账号未初始化或家目录权限错误检查/var/log/auth.log修复家目录所有者和权限某人离职后还能登录账号未及时禁用立即执行usermod -L username锁定并检查其所属组这张表我建议收藏。绝大多数权限和密码问题都不是什么高深的技术故障而是管理流程上的疏漏。排查的顺序永远是从日志入手先确认现象再定位配置最后动手改。关于家用WiFi密码顺带多一句嘴。路由器的管理后台如果还用出厂默认密码WiFi密码又设得太简单被蹭网和后台被改只是时间问题。把管理后台密码改复杂、开启WPA2/WPA3加密、关闭WPS功能这几件事花不了十分钟但能挡住绝大多数风险。最后分享一点我个人的经验安全不是某一个时刻的加固动作而是日常习惯的累积。我从管理第一台服务器开始就把能用密钥不用密码、能用sudo不用root、能加日志不加侥幸这三条准则写在备忘录里。这些年踩过的坑确实不少但正因为这些底线一直守着真正意义上的严重事故一次都没出过。你手里的每一台机器、每一个账号都值得用同样的态度去对待。