1. 项目定位为什么需要加固 PAM 认证体系很多刚接触 Arch Linux 的朋友把系统装完就以为大功告成直到某天发现自己的工作站居然能被别人轻易破解密码或者误操作把用户锁死在外面才开始意识到认证安全的重要性。我这些年帮人维护过不少 Arch 环境也踩过不少 PAM 配置的深坑今天就把这套折腾心得完整梳理一遍希望能帮你少走弯路。先聊清楚项目背景。这个配置方案并不只是简单跑一遍archinstall装好系统核心目标在于“装完之后的安全加固”尤其聚焦在 PAMPluggable Authentication Modules这套 Linux 底层的可插拔认证框架上。PAM 相当于系统认证的“总闸门”无论是本地登录、SSH 远程登录、sudo 提权还是图形桌面环境的登录界面最终都要经过 PAM 的认证链路。你想象一下一个公寓楼的安保系统PAM 就是那个识别人脸、检查门禁卡、登记访客的总保安谁合法谁非法全由他来判断。这个项目适合三类人。第一类是刚装完 Arch 但还没做任何防护的新手想一次性把密码策略、登录限制、暴力破解防御都搞定第二类是已经用了一段时间、对系统安全有初步概念但还不清楚 PAM 到底怎么配、system-auth、password-auth、sudo这些文件之间到底是什么关系的中级用户第三类是想在服务器上跑 Arch、需要面对公网暴力破解轰炸的运维人员。我会从archinstall安装环节的注意事项讲起然后重点拆解 PAM 认证链路的原理、配置方法以及常见问题的排查思路最后给出一个可以直接抄作业的完整配置方案。需要提前说清楚的是PAM 配置非常敏感一旦写错轻则无法 sudo重则整个系统都登不进去所以文中每一个修改建议我都会附上原因和备份方案操作的时候务必按步骤来不要跳步。2. archinstall 安装阶段的三个安全选项很多人以为archinstall只是一个“省事版安装器”但其实它的分区、用户、网络这几步里藏着好几个和后期安全相关的决策点。我建议在安装阶段就做好基础铺垫省得系统都装完了再返工。2.1 磁盘加密LUKS2 分区的重要性archinstall在分区环节会问你“是否使用 LUKS2 加密”我强烈建议除非你只是跑一个临时虚拟机否则一律选择加密。这里说一个很容易忽略的细节LUKS2 加密不只保护你家里的敏感文件更重要的是保护 SSH 主机密钥和 PAM 配置本身——如果硬盘是明文你后面配置得再严密别人只要把硬盘拆下来挂到另一台机器上就能直接读取/etc/shadow的哈希、/etc/pam.d下的策略文件那所有的认证加固都等于白做。加密口令的选择也有讲究不要用纯数字的短密码。考虑到 LUKS2 的 PBKDF2 迭代次数默认是比较高的所以你设置的密码首先得能记住但绝不能是生日、电话号这类可猜测信息。我见过一个用户加密密码设成六个 1结果硬盘被偷之后三天就被暴力破解了整个系统裸奔。密码至少 16 位以上混合大小写、数字和符号这是底线。2.2 用户与 sudo 组最小权限思想的起点archinstall在配置文件里会让你新建一个普通用户需要你决定是否加入wheel组。默认情况下wheel组的用户是可以通过sudo提权的因为我后面要做的 PAM 加固方案里有一部分策略只针对sudo认证链路所以这个组别划分直接影响策略的生效范围。这里建议只把日常使用的那个用户加入wheel其他任何额外用户都不要给这个权限。如果后面确实需要多人管理再单独创建用户并逐步授权。最小权限听起来是安全教科书上的老话但实际操作里太多人图省事直接把自己设成唯一管理员该加的组一个不少不该加的一个没落。真出了问题比如某个 Web 服务被攻破后拿到低权限 shell如果这个低权限用户恰好也在wheel组里那对方的提权路径会非常顺畅。2.3 选择 systemd-boot 与安全启动的关联archinstall默认的引导程序在 UEFI 环境下通常是systemd-boot。很多人不关心这个但这个选择和硬件层安全有关。如果机器支持安全启动Secure Boot建议在安装完成后补配一个自定义的密钥流程对不同引导程序的兼容性要求不太一样systemd-boot做签名相对简单。因为我项目的主线是 PAM这里就不展开说具体签名步骤了但你要有这个意识PAM 管的是用户认证而 Secure Boot 管的是系统启动链的完整性两者属于不同层面叠加在一起才叫完整。安装阶段做完这三点你就有了一个基础还算扎实的 Arch 系统。接下来我们就该聊重头戏 PAM 了。3. PAM 认证系统的核心链路拆解PAM 到底是什么说得玄一点它是“认证插件的调度器”。说得接地气一点就是一个中间层——应用程序比如sshd、sudo、login自己不直接去读密码文件而是把“我要认证一个用户”这个请求丢给 PAMPAM 再根据配置文件去调用具体的认证模块。这样做的好处是认证方式可以灵活切换你想加一个指纹认证、想加一个硬件令牌、想限制某个时间段不允许登录都不用改程序本身只改 PAM 配置就行。3.1 PAM 的四种管理组类型PAM 的每个配置文件都按管理组拆成四条链分别是auth验证身份、account检查账户状态、password处理密码更新、session管理会话建立与结束。这四类对应了“你是谁”“你能不能进”“你想改密码”“进来了之后要分配什么资源”四个不同阶段。举个例子你通过 SSH 登录一台 Arch 服务器auth阶段会验证你输入的密码是否正确也可能触发一次性验证码模块account阶段会检查你的账户是否过期、是否被锁定、当前时间是否在允许登录的窗口内如果你这次登录过程中执行了passwd想改密码那就涉及password这条链它会校验新密码的强度比如通过pam_pwquality登录成功后session链会执行一些环境准备工作比如创建用户特定的运行目录、记录登录日志等。你可能已经在别的系统上见过/etc/pam.d/login、/etc/pam.d/sshd、/etc/pam.d/sudo这些文件它们每个都定义了不同服务的认证流程。而 Arch 默认安装后很多服务会通过一个公共配置做聚合——这个后面讲具体配置时会提到。3.2 关键配置文件与模块速查Arch 上 PAM 配置文件集中在/etc/pam.d/核心的公共文件是system-auth和password-auth。这两个文件的名字容易被混淆记住一个区分点system-auth是给本地认证比如login、图形登录管理器、su用的password-auth更偏向给远程服务如sshd用的。不过现代 Arch 里很多服务会显式include其中之一所以你在改的时候要保持两者一致性否则可能出现“本地密码很严格远程却很宽松”或者相反的诡异情况。再看几个我后面会用到的 PAM 模块pam_unix.so最基础的传统密码认证模块跟/etc/shadow打交道负责验证用户名密码、更新密码哈希。pam_pwquality.so密码强度校验模块可以设置最小长度、需要几种字符类型、与旧密码的相似度限制等。pam_faillock.so登录失败锁定模块用来记录失败次数并在达到阈值后锁定账户或来源 IP这是防御 SSH 暴力破解的主力。pam_limits.so会话级资源限制模块可以限制用户的最大登录进程数、CPU 时间等对防资源滥用有帮助。pam_env.so设置环境变量的模块常用于在登录阶段按用户或服务注入特定环境。pam_nologin.so如果存在/etc/nologin文件就禁止非 root 用户登录常用于系统维护期。重点是pam_unix.so的几个细节。它的try_first_pass参数表示优先使用上层模块已经读取到的密码避免让用户多次输入use_authtok参数用于密码修改时不要重复提示输入。还有sha512、rounds这类哈希参数Arch 默认通常已经采用 SHA-512 哈希并设置了足够的 rounds迭代次数你不需要为了“看起来更安全”去手动定义默认值完全够用。迭代次数越大暴力破解密码的成本越高但你自己登录时的验证延迟也会增加。默认值就是实用性和安全性的平衡点不建议动不动去往几万几十万调。3.3 认证栈的执行顺序问题PAM 之所以叫“栈”是因为配置文件里每一行的执行是严格按从上到下顺序来的。这个顺序极其重要。比如你要同时启用pam_pwquality.so和pam_faillock.so到底谁先谁后再比如pam_nologin.so放在整条栈的什么位置效果完全不同。这里用一个非常容易踩坑的例子说明很多人想实现“密码错误三次就锁账户”于是在system-auth的auth段里把pam_faillock.so放在了最前面。结果发现不仅仅是输错密码会被锁连“密码正确但账户过期”或“被策略拒绝”的情况也会被累计失败次数。更离谱的是如果你配置了双重认证密码加一个验证码第二次验证失败也会触发锁定这个体验非常糟糕。经验做法是pam_faillock.so的预检preauth要放在堆栈靠前的位置但最终判定authfail和authsucc要放在认证模块之后。也就是说先检查“之前有没有因为错误被锁定”这一步不消耗密码然后正常走密码验证验证失败后再记录失败次数验证成功后再清除失败计数。这个顺序不能乱。4. PAM 安全加固全流程实操讲完原理下面进入正题。我会按“先备份、再修改、后验证”的顺序给出一套可以直接照做的加固方案。整个方案分为密码策略、登录限制、sudo 强化三个层面每一层我都会说明目的和可能的风险。4.1 第一步全量备份 PAM 配置在动手之前先把/etc/pam.d/整个目录打一个压缩包同时把/etc/security/下与 PAM 相关的文件也备份好。命令如下sudo mkdir -p /root/pam-backup sudo cp -a /etc/pam.d /root/pam-backup/ sudo cp -a /etc/security /root/pam-backup/为什么要备份得这么仔细因为 PAM 的某个文件语法错误导致的结果通常不是“这条策略没生效”而是“所有相关服务直接拒绝认证”。你只有在改动前留存了完整快照才能在出问题时一键恢复。实测下来很多玩坏 PAM 的用户就是没有备份最后只能进 Live 环境挂载磁盘去改文件本来十分钟能解决的问题变成半小时起步。另外还要记一下当前系统里pam软件包的版本。可以运行pacman -Q pam如果后续升级了该软件包部分配置文件的默认内容可能会变你要留意 pacman 的.pacnew提醒。4.2 第二步设置强密码策略密码策略主要靠pam_pwquality.so实现。Arch 上该模块由pam包自带无需额外安装。但对应的配置文件在/etc/security/pwquality.conf里面有很多选项我一般建议至少开启下面几项minlen 12 dcredit -1 ucredit -1 lcredit -1 ocredit -1 minclass 3 maxrepeat 3这段配置的含义需要逐条解释。minlen 12表示密码最少 12 个字符但注意这个长度是包含“信用额度”的如果密码里包含数字、大写、小写、特殊字符每个类型会提供一定的“信用分”所以实际要求的字符数可能略低于 12。如果你希望严格卡死 12 个字符需要结合minclass等参数一起看。为了省心我会再加一个minlen 14宁可稍微严格一点因为现在硬件跑暴力穷举的速度实在太快12 个字符只包含小写字母的密码空间在 GPU 面前撑不了多久。dcredit -1、ucredit -1、lcredit -1、ocredit -1的作用是要求密码中至少包含一位数字、一位大写字母、一位小写字母和一位特殊符号。这里负号的意思是“至少需要多少个”正数才是“最多允许扣多少信用分”这个细节很多人弄反过。minclass 3表示至少使用 3 种字符类别。maxrepeat 3是限制同一字符不能连续重复超过 3 次比如aaaabbbb这种结构会被拒绝。改完pwquality.conf之后你还需要在 PAM 栈里引用这个模块。在 Arch 的system-auth里password段的pam_unix.so之前需要有一行password required pam_pwquality.so实际修改时用编辑器打开/etc/pam.d/system-auth在password段的合适位置加上这一行并把原来的注释行取消注释或调整顺序。完成之后先用普通用户执行一次passwd试试确保证书策略是强制生效而不是“建议”。4.3 第三步登录失败锁定与 SSH 防护防御暴力破解是我做 PAM 加固最看重的一环因为 Arch 服务器一旦暴露公网SSH 端口被扫描是很常见的事。pam_faillock.so是当前比较干净的解决方案。先看一个典型的system-auth里auth段如何组织auth required pam_faillock.so preauth auth sufficient pam_unix.so try_first_pass auth [defaultdie] pam_faillock.so authfail auth sufficient pam_faillock.so authsucc第一行preauth的作用是检查账户当前是否处于锁定状态。如果已经被锁定直接进入pam_faillock.so的后续处理不会给你瞎试密码的机会。第二行pam_unix.so是真正的密码核对。如果密码对了会走到第四行authsucc这里会清除累计失败计数。如果密码错了pam_unix.so会返回错误然后命中第三行authfail失败次数加一。除此之外你还需要在account段加上一行account required pam_faillock.so同时推荐设置下面几个参数写在/etc/security/faillock.conf里deny 5 unlock_time 900 even_deny_root root_unlock_time 3600deny 5是允许连续失败 5 次。unlock_time 900是锁定 15 分钟后自动解锁。even_deny_root表示 root 账户也参与失败锁定这其实是个有争议的选项——一方面root 是暴力破解的头号目标另一方面如果 root 被锁定而你又没配置其他管理通道可能会把自己锁在门外。所以 root 单独设一个root_unlock_time 3600锁定一小时后自动恢复这个折中方案我实践下来比较靠谱。需要强调的是如果在/etc/pam.d/sshd里没有显式包含system-auth或password-auth那上面的配置不会自动应用给 SSH。通常 Arch 默认的sshdPAM 文件很简洁它作为服务会加载system-auth。但你要亲自确认一下看里面有没有include system-auth或者substack system-auth。如果没有在 SSH 登录入口处也加上对应的auth和account引用否则你会发现本地 tty 登录被保护得死死的SSH 依然是裸奔状态。再提一个加强项如果你只通过 SSH 管理机器建议开启公钥认证、关闭密码认证。这可以在/etc/ssh/sshd_config里设置PasswordAuthentication no、PubkeyAuthentication yes。注意这虽然也是一种“认证策略”但不是 PAM 层面的强制方案而是 SSH 本身的认证方式选择。两相结合之后即使对方知道你的密码在没有私钥的情况下也进不来。4.4 第四步sudo 认证强化在 Arch 上普通用户通过 sudo 提权时PAM 也会走一套认证流程。默认情况下你只需要输一次用户密码就行。但如果你希望“sudo 也要有强度验证、也要有失败锁定”就需要在/etc/pam.d/sudo里做额外配置。我建议sudo文件包含以下内容auth required pam_faillock.so preauth include-auth account required pam_faillock.so include-account注意这里的include-auth属于 Arch 的pam包新式配置语法它会动态加载system-auth内容。如果你的系统版本较老没有这个关键字就手动把system-auth对应的auth和account段内容复制过来。关键在于你一定要理解pam_faillock的失败计数是全局的。什么是全局就是用户通过 SSH 输错密码 3 次再用 sudo 输错 2 次如果没解锁累计就变成 5 次直接触发锁定。这个行为是特性不是 bug它能防止攻击者分散目标、用多种入口试探同一密码但同时也会让误操作的用户更容易被锁。为了不给自己找麻烦我习惯把全局的deny设为 5 而不是更小的数字。另外可以考虑给 sudo 增加一条时间戳超时策略。默认 sudo 的凭证会缓存一段时间你在终端执行过 sudo 之后五分钟内再次执行都不会要求重新输密码。如果你想缩短这个窗口可以在/etc/sudoers里设置Defaults timestamp_timeout2或者在 PAM 层面配置pam_time模块做时间窗口限制。个人感受是前一种方式更直接。4.5 第五步统一收口与重启验证所有配置改完之后先做两件事第一件是检查配置文件语法第二件是开一个新的 SSH 会话再测试。PAM 没有专门的“编译”命令但你可以通过pam_nofail之类的模块做基本验证更常用的方式是检查系统日志看有没有语法报错。最简单的验证保持当前 SSH 会话不要断开开第二个窗口尝试登录故意输错密码触发锁定看看是否真的被拦截。如果第二个窗口的登录行为和你预期一致再逐步做正常登录、sudo、修改密码等各项测试。如果真出了状况比如当前会话还可以正常用但新会话全部被拒不要慌。因为 root 的auth栈可能也被 PAM 限制锁死了你可以用已有的 root 会话把配置改回来或者重启进入单用户模式GRUB 启动菜单按e编辑内核参数加single或init/bin/bash。这也是为什么前面强调备份的重要性。5. 实战案例一次完整的 SSH 暴力破解拦截记录理论讲多了容易空洞我分享一个实际经历。之前帮某团队加固了一批跑 Web 服务的 Arch 服务器服务器的 SSH 端口暴露在公网攻击日志里来自不同 IP 的扫描记录几乎没停过。我先用默认未加固的配置做了一次对比测试把sshd日志调到VERBOSE开了 12 小时搜集到的失败尝试达到近千次来源 IP 遍布好几个国家。有些 IP 是用常见用户名admin、root、test组合弱密码批量尝试。当时如果系统是按默认配置运行理论上只要某个弱密码撞上已知用户名服务器就会被攻破。之后我做了三件事把sshd_config里的密码认证彻底关闭只允许密钥登录在 PAM 栈里启用了pam_faillock.so并设置deny5、unlock_time900额外在auth链前面挂了一个基于pam_exec.so的脚本做来源 IP 归属地过滤这是比较野的路子正常用不到就不推荐你照抄了。改完第二天又有一轮暴力扫描过来但效果已经完全不同。攻击者可以用密钥登录之前就会在 PAM 阶段被拦下不管密码对不对只要连续失败 5 次这个账户就会被锁定 15 分钟。对于攻击者来说即便他手里有一批弱密码字典也没办法在同一次会话里持续尝试。一个更细节的改进是我把pam_faillock的记录文件路径指到了/var/log/faillock而非默认的/var/run/faillock这样重启后失败记录还在能看出攻击趋势但这个做法有点非主流主要适合需要做安全审计的场景。经过这个案例我最大的体会是PAM 的加固不能指望单点策略它是“多层冗余”的思路。密码策略弱但用户量少也许还能撑一撑密码策略强但暴露面大也不一定稳真正稳的组合是密钥认证 失败锁定 较短会话超时 定期审计日志。几个手段叠在一起攻击者在一个环节被卡住很难再往下推进。6. 常见问题速查配置踩坑记录与恢复路径这里把我这些年实操里见过的高频问题整理成表有些问题是问出来的有些是自己或同事踩过后排查出来的直接给你结论和解决思路。问题现象大概率原因处理方式修改完 PAM 后本地所有用户无法登录root 也被拒/etc/pam.d/system-auth语法错误或引用了不存在的模块重启进单用户模式删除改动或回滚备份无备份时可临时用 Live 环境挂载磁盘修复SSH 可以密钥登录但密码登录报错“Permission denied”/etc/pam.d/sshd没有正确包含system-auth或者pam_faillock锁定触发检查 SSH 会话能否正常开新连接在/var/log/faillock里看失败记录确认sshd_config与 PAM 策略是否冲突密码设置时总是提示“密码太短”即使很长的密码也不行pwquality.conf的minlen和dcredit等参数叠加计算干扰临时代替把minlen降低测试确认其他复杂度选项是否过严不要盲目一次加多个强约束一项项加用户在多个入口尝试密码失败次数被快速累计到锁定pam_faillock的失败计数是全局的统一作用于本地、SSH、sudo如果误伤概率大把deny数值从 5 调到 8~10或为 root 设置更长的解锁时间避免自身管理员被锁某服务器上pam_pwquality完全不起作用password段没有引用该模块只在pwquality.conf改配置是无效的把password required pam_pwquality.so加到password链前面系统启动时出现 “PAM configuration error”某项 PAM 配置对 32 位库或容器环境不兼容或某个模块缺失查看/var/log/everyone.log或 journalctl定位错误行后修复如确认是某模块不存在安装对应包或移除该行最常见也最低级的错误是编辑 PAM 文件时把行顺序写颠倒比如把pam_faillock的authfail放到了preauth前面。这种情况下用户每输入一次错误密码系统不会先查是否锁定而是直接记录并再次放行起不到拦截作用。这类错误不会导致服务崩溃所以不容易在日志里发现但攻防有效性会大幅缩水。我的习惯是在每次改完 PAM 后快速建一个受控用户做 10 次左右错误密码测试观察日志确认锁定行为是否真的触发。还有一点很多人混淆“锁定”和“拒绝认证”的区别。pam_faillock锁定后即使输入正确密码也会提示认证失败这是预期行为。而某些防火墙方案是用fail2ban封禁来源 IP两者面向的维度不同pam_faillock面向的是账户fail2ban面向的是 IP。账户锁定能防止攻击者用同一个账户反复试IP 封禁能防止分布式来源的持续扫描。两者不冲突可以一起用但你要清楚它们各自是干嘛的别把日志里的现象归错因。还有一个容易被忽略的环境问题。如果你在容器或 WSL 里跑 Arch部分 PAM 模块比如需要记录 utmp 或设备文件的模块会因为虚拟化环境的限制无法正常工作安装时没必要强上所有模块。容器里做认证加固的思路和物理机不完全一样有些策略放在宿主机或镜像构建阶段更合适。具体问题具体分析不要照搬全套。7. 一些个人的配置习惯与推荐扩展写到这里主体内容基本讲完了最后分享几条我用下来的习惯不一定都适合你但至少能帮你避开一些坑。先说我个人的组合习惯。Arch 桌面机和服务器我用的是两套不太一样的配置。桌面机重点放在本地登录、sudo 和屏幕锁上pam_faillock的deny设得比较宽松比如 8因为桌面使用情境下误触密码错几次太常见了锁住自己很烦。服务器则严格得多启用密钥登录后我可以把密码认证直接关掉再用pam_faillock做二次防线deny能设 3 就设 3攻击者的尝试空间被压缩得很小。写过一次测试脚本模拟同一个 IP 的 SSH 连续错误发现pam_faillock触发后日志清晰系统负载基本没变化还是挺可靠的。另一个好习惯是把 PAM 相关配置纳入版本管理使用etckeeper之类的工具把/etc整个纳入 Git 仓库。这样每次改动都有 commit 记录出了问题能迅速回滚到上一个版本也能配合备份脚本把/root/pam-backup定期归档到外部存储。别等到系统崩了才想起来自己没有备份那种刺激不想经历第二次。关于扩展到生物识别或硬件令牌pam_fprintd这类模块我也在部分笔记本上试过。整体上 Arch 对这类模块的支持算上游里比较好的但指纹识别器的驱动水平因硬件而异稳定性参差不齐。而且生物识别不适合当唯一认证因素做双因素里的第二因素还行。如果你要给 root 或 sudo 加上双因素认证可以研究pam_google_authenticator或pam_u2f思路还是那句把额外的验证模块以正确的顺序插进auth链。不过这些属于高级玩法建议先把本文的基础方案吃透再说。最后再提醒一次控制好改动的节奏。我曾经看到过有人在一天内同时改了system-auth、password-auth、sudo、login、sshd五个文件还不做备份最后被锁在系统外只能进 Live 环境。PAM 相关的任何改动都请遵循“一次改一点、立刻验证、有问题马上回滚”的原则。这样做虽然慢但慢就是快安全加固本身就是个持续迭代和验证的过程。希望这篇文章能帮你把 Arch 的认证安全从“玄学”变成“清单”踩在别人踩过的坑上面走自己的稳定路线。