最近帮朋友处理一台被爆破的服务器翻日志的时候看到几千条密码尝试记录从 root/admin 这种默认账号开始一路试到各种常见弱口令就差没把字典整个跑一遍了。好在机器上没放什么重要数据但这件事再次印证了一个老规矩Linux 服务器的密码策略和登录会话管理永远不能靠默认配置。很多新手运维容易忽略一个事实——密码复杂度和登录超时看起来是小配置实际是服务器安全的第一道门也是最容易被自动扫描工具拿下的入口。只要你把密码设短了、设简单了或者把 SSH 会话一直挂在那里不管暴力破解和撞库脚本就有机可乘。这篇文章把密码复杂度策略和登录超时设置这两块从原理到实操全部展开讲透包括 PAM 模块怎么工作、参数怎么填才不是摆设、TMOUT 和 SSH 层超时怎么配合、改完配置怎么验证以及我踩过的各种坑。适合刚接手服务器的运维、搞开发的兼职网管还有想系统加固自己云主机的同学。1. 为什么先搞定密码复杂度和登录超时这是最容易被攻破的两道门1.1 弱口令和暴力破解比想象中来得更频繁只要服务器暴露在公网哪怕只开了一个 22 端口每分每秒都有扫描器在探测。我习惯定期查看 secure 日志或 auth.log几乎每天都能看到来自不同地区的 IP 在尝试 SSH 登录尝试的用户名从 root、admin 到 git、mysql、postgres密码也是从 123456、password、admin888 一路尝试过来。这种攻击不需要针对你纯粹是自动化的地毯式扫描。有一个容易被低估的事实这些字典攻击的命中率往往取决于管理员的密码强度。设一个 8 位纯数字密码和一个 16 位大小写加符号混合密码被破解的难度完全不是一个量级。密码复杂度策略解决的就是让弱密码从一开始就不存在的问题而不是等密码被撞穿以后再去补救。1.2 登录超时解决的是人走了、门还开着的问题有次我在一台服务器上调试服务中途走开接了个电话回来发现终端还留在 root 会话里而那个会话正好是我在公网环境下的 SSH 连接。那一刻我想如果刚才有人拿到这个终端或者这个会话被某种方式利用后果不堪设想。登录超时设置的防线就是让空闲的交互式会话自动退出。常见的有两种一种是 Shell 层的 TMOUT 变量控制用户登录后空闲多久自动登出另一种是 SSH 守护进程层的 ClientAliveInterval 与 ClientAliveCountMax 组合用于检测死连接、清理无响应的会话。这两者解决的问题有重叠但覆盖的层级完全不同很多资料把它们混为一谈实际配合起来才能形成完整防线。1.3 这两项配置的影响范围远比表面看起来大密码复杂度策略不只在人手动改密码时生效它还会影响脚本批量创建用户的行为影响程序通过 API 重置密码的流程甚至影响云平台初始化密码的合规性。策略设得太松等于没设设得太死又可能卡住自动化任务。登录超时同样有影响面TMOUT 设得太短用户编辑配置、跑个长命令的间隙就被踢下线操作被打断设得太长又等于没设。这个平衡点需要在实战中拿捏。下面的每一节都会结合具体场景给出建议值。2. 密码复杂度策略从 PAM 到 pwquality 的完整链路2.1 认识 PAM 机制密码策略到底在哪里执行Linux 的登录验证、密码修改等认证环节默认通过 PAMPluggable Authentication Modules可插拔认证模块框架来统一管理。你执行 passwd 修改密码时系统会走 /etc/pam.d/ 目录下对应的认证规则比如系统通用规则在 system-authRHEL/CentOS 系或者 common-passwordDebian/Ubuntu 系。在这个链条里真正负责密码强度检查的模块是 pam_pwquality.so。旧一些的系统用的是 pam_cracklib.so两者底层库不同但参数设计逻辑非常像。Ubuntu 和 CentOS 的新版本基本都默认支持 pam_pwquality.so如果你的系统里还没启用需要确认一下 PAM 配置文件里有没有一行类似password requisite pam_pwquality.so retry3如果没有就需要手动加进去。这一步是所有密码复杂度配置的起点。2.2 pwquality.conf 核心参数逐个拆解直接改 /etc/pam.d/system-auth 当然可以不过更推荐用 /etc/security/pwquality.conf 这个配置文件来管理策略因为它是专门为 pwquality 模块服务的结构清晰不需要动 PAM 规则。系统里可能自带了默认文件通常大部分参数都是注释状态启用后才会生效。常用的配置如下# 密码最小长度不是简单的字符数而是综合计算的分值 minlen 12 # 至少包含的数字个数负数表示至少正数表示最多 dcredit -1 # 至少包含的大写字母个数 ucredit -1 # 至少包含的小写字母个数 lcredit -1 # 至少包含的特殊字符个数 ocredit -1 # 用户最多尝试几次 retry 3这里要强调一个很多教程没讲清楚的坑minlen 并不等于最少字符数。它是 pwquality 根据密码复杂度计算出来的一个指标——密码里每包含一类字符计算出的分值会相应提高。举例来说如果全都用数字实际需要的字符数可能比 minlen 值还多如果各类字符都有可能刚好达标。如果想稳一点建议 minlen 设成 12 或更大并搭配各类 credit 都设为 -1这样既保证长度又保证字符多样性踩坑几率小。还有 enforce_for_root 这个选项它的作用是让 root 用户改密码也遵守这套强度规则。生产环境建议开启毕竟一台机器上 root 被拿下等于全线崩溃。设置方法是在 pwquality.conf 里加一行enforce_for_root2.3 密码有效期与老化规则别让密码一次修改永久有效密码复杂度解决的是强不强的问题而密码老化解决的是隔多久必须换一次的问题。运维人员经常忽略后者结果导致 3 年前设的密码一直在用哪怕当时是强密码也有泄露或被拖库的风险。相关配置在 /etc/login.defs 中# 密码最长有效期天 PASS_MAX_DAYS 90 # 两次密码修改的最短间隔天防止用户修改后立刻又改回旧密码 PASS_MIN_DAYS 7 # 密码过期前多少天开始提醒 PASS_WARN_AGE 14这里设置的数值会作用于后续新建的用户对已经存在的用户需要用 chage 命令来调整。比如强制某个用户 90 天后必须改密码chage -M 90 用户名查看用户当前的密码老化状态chage -l 用户名一般建议 PASS_MIN_DAYS 设成 7这样能避免用户在同一天改完密码又马上改回去导致策略形同虚设。PASS_WARN_AGE 设 14 天给足心理缓冲期免得用户登录时突然被强制改密手忙脚乱。3. 登录超时设置Shell 层与 SSH 层缺一不可3.1 会话空闲自动登出TMOUT 的落地姿势TMOUT 是 bash以及部分其他 shell内置的一个环境变量单位为秒。在交互式 Shell 中如果用户在设定时间内没有任何输入Shell 会自动退出。这个机制直接作用于会话本身是最常用的登录超时方案。推荐写到 /etc/profile.d/ 下面比如创建一个 timeout.shcat /etc/profile.d/timeout.sh EOF # 会话空闲超时时间单位秒这里设置 10 分钟 TMOUT600 readonly TMOUT export TMOUT EOFreadonly 很关键防止用户在登录后自己把变量清掉。写成独立脚本而不是直接塞进 /etc/profile便于后续维护和排查也符合多数发行版的加载约定。文件创建后需要重新登录或者 source 一下才能对当前会话生效。对于已有登录会话可以手动执行source /etc/profile.d/timeout.sh然后按几个键验证一下。真正等到超时自动退出需要的时间比较久耐心点即可。TMOUT 有个容易踩的坑它只作用于交互式 Shell。如果你用 screen 或 tmux 挂了一个会话TMOUT 不会杀死 screen/tmux 里运行的进程这在某些场景下反而是好事——长任务不受影响。但如果要强制清理所有空闲会话单靠 TMOUT 不够需要配合会话审计手段。3.2 SSH 层的无效连接清理ClientAliveInterval 与 ClientAliveCountMax很多人不知道SSH 协议本身不支持直接设置空闲超时。sshd_config 里有 ClientAliveInterval 和 ClientAliveCountMax 这两个参数但它们做的并不是计时登出而是服务端定期向客户端发送心跳探测包确认连接是否还活着。常见的配置# 每 300 秒发送一次保活探测 ClientAliveInterval 300 # 连续 2 次无响应就断开 ClientAliveCountMax 2综合来看客户端若在约 600 秒内没有任何响应连接就会被服务端断开。这种方式最大的价值在于清理那些网络断开、客户端崩溃或休眠后残留的僵尸会话防止服务器连接数被无效占用。把 ClientAliveInterval 和 TMOUT 放在一起看TMOUT 管的是人没有操作ClientAlive 管的是通道已经不畅通。很多发行版默认可能没有启用这两个参数或者值比较宽松。建议在加固时至少加上 ClientAliveInterval 300 和 ClientAliveCountMax 2。如果你的场景是大量短连接负载均衡取值可以再短一些避免僵尸会话堆积。3.3 两层超时怎么配合一个典型场景我一般的推荐配置组合是TMOUT600 加 ClientAliveInterval300、ClientAliveCountMax2。用户闲下来超过 10 分钟Shell 层自动把会话退出如果网络出问题SSH 层也能在 10 分钟左右把死连接清掉。两层各管一摊互不冲突。有个容易被忽略的细节如果用户正在跑一个耗时的任务比如编译、打包、数据库迁移TMOUT 并不会把任务杀掉因为 bash 只有在交互提示符处才是空闲状态命令执行期间不算空闲。这是 TMOUT 设计上很人性化的一点。但如果任务是在交互式提示符下挂起的比如按了 CtrlZ 挂起一个前台进程长时间没操作TMOUT 依然会让 Shell 退出这一点要提前给使用者讲清楚。4. 配置落地的完整实操备份、修改、验证、回滚4.1 配置前准备先看当前系统在用什么模块动手之前第一步是确定你的系统属于哪个家族使用了哪套 PAM 规则。我习惯先看几个关键文件cat /etc/os-release grep -E pam_pwquality|pam_cracklib /etc/pam.d/system-auth /etc/pam.d/common-password 2/dev/null ls /etc/security/pwquality.conf如果是 RHEL 系重点是 /etc/pam.d/system-auth 和 /etc/pam.d/password-authDebian/Ubuntu 系重点看 /etc/pam.d/common-password。确认模块之后再做下一步。备份环节不能省cp /etc/security/pwquality.conf /etc/security/pwquality.conf.bak.$(date %F) cp /etc/ssh/sshd_config /etc/ssh/sshd_config.bak.$(date %F) cp /etc/login.defs /etc/login.defs.bak.$(date %F)备份文件名带日期方便日后定位问题和回滚。4.2 密码策略配置实操在 pwquality.conf 里建议填上以下内容然后保存minlen 12 dcredit -1 ucredit -1 lcredit -1 ocredit -1 retry 3 enforce_for_root如果系统里没有启用 pam_pwquality.so还需要在正确的 PAM 配置里补一行。RHEL/CentOS 通常在 system-auth 的 password 段Debian/Ubuntu 在 common-password 中。以 Ubuntu 为例需要确保 /etc/pam.d/common-password 里有类似password requisite pam_pwquality.so retry3如果原本是 pam_cracklib.so也可以直接替换为 pam_pwquality.so前提是系统已安装 libpam-pwquality 软件包。安装方式# Debian/Ubuntu apt install libpam-pwquality # RHEL/CentOS/Rocky yum install libpwquality改完后验证新策略是否生效。最直接的方法是用一个普通用户或新建临时测试用户尝试设置不符合规则的密码观察是否被拒绝。注意要用 passwd 命令来测不能通过 sudo 或 root 直接修改因为 PAM 策略会在 passwd 过程中强制执行。如果设置不满足复杂度要求会看到类似 BAD PASSWORD: The password is too simple 的提示。4.3 登录超时配置实操先配置 TMOUT 脚本cat /etc/profile.d/timeout.sh EOF TMOUT600 readonly TMOUT export TMOUT EOF然后配置 sshdcat /etc/ssh/sshd_config EOF ClientAliveInterval 300 ClientAliveCountMax 2 EOF修改 sshd 配置之后建议先做语法校验sshd -t输出为空就说明语法没问题。然后重新加载 sshd而不是直接 restart避免粗暴断开所有现有连接systemctl reload sshd有些发行版没有 systemd可以用/etc/init.d/ssh reloadreload 操作对当前连接的影响很小新配置会在新建连接时生效。4.4 效果验证不要关机重启就算完事实际验证超时是否生效可以临时把 TMOUT 改小测试。比如先执行export TMOUT10然后 10 秒不动终端如果 Shell 自动退出说明机制正常。再回到正式配置的 600 秒。SSH 层的验证可以看日志或者用另一个终端连接后拔掉网线/断网观察连接是否在预期时间内被清理。一般不用等太久几分钟就能在 auth.log 或 secure 日志里看到服务端主动断开的相关记录。如果验证过程中发现策略没生效大概率是以下几种原因PAM 模块没装、配置文件路径不对、改完没 reload、验证方式不对直接出现 shell 时没有被 TMOUT 控制。5. 高频问题与避坑经验我把常见的坑都踩了一遍5.1 配置了密码策略为什么老用户还可以用弱密码登录这是最容易让人误解的地方。pwquality 只会在设置或修改密码时校验强度它不会拦截已经存在的弱密码登录。也就是说如果你给某用户设置密码时用了弱密码策略不会自动重审它只有在下一次修改密码时才强制遵守新规则。所以加固完密码策略后还必须主动检查现有用户的密码强度最好让所有用户都重新设置一次密码或者通过 chage -M 90 强制他们在下次登录时改密。如果实在不想打扰线上用户至少在创建账号时严格遵循策略并且在流程上限定期改密。5.2 TMOUT 把正在跑的任务带崩了怎么办前面提到 TMOUT 只作用于交互式 Shell一般不会杀掉正在前台运行的命令。但有一种情况很容易被坑你写了一个脚本里面用 sleep 模拟长时间等待或者脚本在等待用户输入时挂起结果 TMOUT 超时把会话退出脚本进程收到 SIGHUP 后中断。排查这类问题时记住两点一是别把 TMOUT 设得太极端比如低于 60 秒对于正常运维操作太伤体验二是必须长期任务时优先使用 nohup、screen、tmux 或 systemd 服务来运行不要直接挂在交互式会话里。用 nohup 很简单nohup long-running-command 这样会话退出任务也能继续跑。5.3 老系统只用 pam_cracklib新老配置习惯的差异如果你还在维护 CentOS 6 或者更老的 Ubuntu可能只能见到 pam_cracklib.so。它的参数跟 pwquality 大同小异比如password requisite pam_cracklib.so retry3 minlen12 dcredit-1 ucredit-1 lcredit-1 ocredit-1区别主要是模块名和配置文件组织方式。老系统里没有独立的 pwquality.conf直接在 PAM 配置行后面写参数。新老切换时不要把两套配置混用否则可能出现策略重复叠加、行为不符合预期的现象。先看当前系统加载了哪个模块再来决定改哪里。5.4 安全性和易用性的平衡别把服务器折腾成堡垒我把密码复杂度设到过很极端的程度——长度 20四类字符全部必须有有效期 30 天。结果团队开发环境里的同事怨声载道经常有人忘记密码频繁找回最后反而增加了社工风险。后来我调整成生产环境 minlen16、四类字符至少各 1 个、90 天有效期开发环境 minlen12、至少数字和大小写、120 天有效期。这样既挡住了最常见的弱口令爆破又不会严重干扰正常使用。提示核心目标是把密码强度提升到字典攻击不可行的程度而不是把密码设到人脑记不住。12 位以上的混合密码已经完全能挡住暴力破解16 位是性价比很高的选择。5.5 千万别忘记 SSH 登录本身的降级策略很多人装完系统默认允许 root 直接 SSH 登录也允许密码登录。如果你的密码策略配置得再强root 账号依然是暴力破解的重点目标。建议同步做两件事一是把 root 直接 SSH 登录关掉改用普通用户加 sudo二是在有条件的场景下禁用密码登录、改用密钥验证。这个不在标题的核心范围内但跟密码复杂度强相关顺手做了效果会好很多。编辑 /etc/ssh/sshd_configPermitRootLogin no PasswordAuthentication no注意修改前一定要确认自己的密钥能正常登录否则改完你就是第一个被锁在门外的人。建议保留一个备用登录通道比如云平台控制台的 VNC 或救援模式。写在最后的个人体会我自己在多次服务器加固中最大的感受是安全配置不是越狠越好而是要确保每一处配置都真正发挥作用。比如 TMOUT 设了 600 秒但用户常年用密钥登录、所有会话都通过跳板机短时间操作那这个值就恰到好处反过来如果公司有人喜欢在晚上挂机跑数据TMOUT 直接设 60 秒肯定天天出问题。密码复杂度同理。与其追求一个谁也记不住的超强密码不如把长度基线拉到 12 位以上配合多类型字符要求再叠加合理有效期就已经能挡住绝大多数自动爆破工具。额外把 root 远程登录关掉、配好跳板机审计安全收益会大得多。还有一个小技巧分享给所有运维同行做任何系统安全配置前先花两分钟把原来的配置文件和当前状态记录到本地笔记标注好修改时间和原因。一个月后回来排查问题时你会发现这份记录比任何记忆都靠谱。服务器安全没有一劳永逸但只要把基础门槛抬上去就已经比大量裸奔的机器高一大截了。
最近帮朋友处理一台被爆破的服务器翻日志的时候看到几千条密码尝试记录从 root/admin 这种默认账号开始一路试到各种常见弱口令就差没把字典整个跑一遍了。好在机器上没放什么重要数据但这件事再次印证了一个老规矩Linux 服务器的密码策略和登录会话管理永远不能靠默认配置。很多新手运维容易忽略一个事实——密码复杂度和登录超时看起来是小配置实际是服务器安全的第一道门也是最容易被自动扫描工具拿下的入口。只要你把密码设短了、设简单了或者把 SSH 会话一直挂在那里不管暴力破解和撞库脚本就有机可乘。这篇文章把密码复杂度策略和登录超时设置这两块从原理到实操全部展开讲透包括 PAM 模块怎么工作、参数怎么填才不是摆设、TMOUT 和 SSH 层超时怎么配合、改完配置怎么验证以及我踩过的各种坑。适合刚接手服务器的运维、搞开发的兼职网管还有想系统加固自己云主机的同学。1. 为什么先搞定密码复杂度和登录超时这是最容易被攻破的两道门1.1 弱口令和暴力破解比想象中来得更频繁只要服务器暴露在公网哪怕只开了一个 22 端口每分每秒都有扫描器在探测。我习惯定期查看 secure 日志或 auth.log几乎每天都能看到来自不同地区的 IP 在尝试 SSH 登录尝试的用户名从 root、admin 到 git、mysql、postgres密码也是从 123456、password、admin888 一路尝试过来。这种攻击不需要针对你纯粹是自动化的地毯式扫描。有一个容易被低估的事实这些字典攻击的命中率往往取决于管理员的密码强度。设一个 8 位纯数字密码和一个 16 位大小写加符号混合密码被破解的难度完全不是一个量级。密码复杂度策略解决的就是让弱密码从一开始就不存在的问题而不是等密码被撞穿以后再去补救。1.2 登录超时解决的是人走了、门还开着的问题有次我在一台服务器上调试服务中途走开接了个电话回来发现终端还留在 root 会话里而那个会话正好是我在公网环境下的 SSH 连接。那一刻我想如果刚才有人拿到这个终端或者这个会话被某种方式利用后果不堪设想。登录超时设置的防线就是让空闲的交互式会话自动退出。常见的有两种一种是 Shell 层的 TMOUT 变量控制用户登录后空闲多久自动登出另一种是 SSH 守护进程层的 ClientAliveInterval 与 ClientAliveCountMax 组合用于检测死连接、清理无响应的会话。这两者解决的问题有重叠但覆盖的层级完全不同很多资料把它们混为一谈实际配合起来才能形成完整防线。1.3 这两项配置的影响范围远比表面看起来大密码复杂度策略不只在人手动改密码时生效它还会影响脚本批量创建用户的行为影响程序通过 API 重置密码的流程甚至影响云平台初始化密码的合规性。策略设得太松等于没设设得太死又可能卡住自动化任务。登录超时同样有影响面TMOUT 设得太短用户编辑配置、跑个长命令的间隙就被踢下线操作被打断设得太长又等于没设。这个平衡点需要在实战中拿捏。下面的每一节都会结合具体场景给出建议值。2. 密码复杂度策略从 PAM 到 pwquality 的完整链路2.1 认识 PAM 机制密码策略到底在哪里执行Linux 的登录验证、密码修改等认证环节默认通过 PAMPluggable Authentication Modules可插拔认证模块框架来统一管理。你执行 passwd 修改密码时系统会走 /etc/pam.d/ 目录下对应的认证规则比如系统通用规则在 system-authRHEL/CentOS 系或者 common-passwordDebian/Ubuntu 系。在这个链条里真正负责密码强度检查的模块是 pam_pwquality.so。旧一些的系统用的是 pam_cracklib.so两者底层库不同但参数设计逻辑非常像。Ubuntu 和 CentOS 的新版本基本都默认支持 pam_pwquality.so如果你的系统里还没启用需要确认一下 PAM 配置文件里有没有一行类似password requisite pam_pwquality.so retry3如果没有就需要手动加进去。这一步是所有密码复杂度配置的起点。2.2 pwquality.conf 核心参数逐个拆解直接改 /etc/pam.d/system-auth 当然可以不过更推荐用 /etc/security/pwquality.conf 这个配置文件来管理策略因为它是专门为 pwquality 模块服务的结构清晰不需要动 PAM 规则。系统里可能自带了默认文件通常大部分参数都是注释状态启用后才会生效。常用的配置如下# 密码最小长度不是简单的字符数而是综合计算的分值 minlen 12 # 至少包含的数字个数负数表示至少正数表示最多 dcredit -1 # 至少包含的大写字母个数 ucredit -1 # 至少包含的小写字母个数 lcredit -1 # 至少包含的特殊字符个数 ocredit -1 # 用户最多尝试几次 retry 3这里要强调一个很多教程没讲清楚的坑minlen 并不等于最少字符数。它是 pwquality 根据密码复杂度计算出来的一个指标——密码里每包含一类字符计算出的分值会相应提高。举例来说如果全都用数字实际需要的字符数可能比 minlen 值还多如果各类字符都有可能刚好达标。如果想稳一点建议 minlen 设成 12 或更大并搭配各类 credit 都设为 -1这样既保证长度又保证字符多样性踩坑几率小。还有 enforce_for_root 这个选项它的作用是让 root 用户改密码也遵守这套强度规则。生产环境建议开启毕竟一台机器上 root 被拿下等于全线崩溃。设置方法是在 pwquality.conf 里加一行enforce_for_root2.3 密码有效期与老化规则别让密码一次修改永久有效密码复杂度解决的是强不强的问题而密码老化解决的是隔多久必须换一次的问题。运维人员经常忽略后者结果导致 3 年前设的密码一直在用哪怕当时是强密码也有泄露或被拖库的风险。相关配置在 /etc/login.defs 中# 密码最长有效期天 PASS_MAX_DAYS 90 # 两次密码修改的最短间隔天防止用户修改后立刻又改回旧密码 PASS_MIN_DAYS 7 # 密码过期前多少天开始提醒 PASS_WARN_AGE 14这里设置的数值会作用于后续新建的用户对已经存在的用户需要用 chage 命令来调整。比如强制某个用户 90 天后必须改密码chage -M 90 用户名查看用户当前的密码老化状态chage -l 用户名一般建议 PASS_MIN_DAYS 设成 7这样能避免用户在同一天改完密码又马上改回去导致策略形同虚设。PASS_WARN_AGE 设 14 天给足心理缓冲期免得用户登录时突然被强制改密手忙脚乱。3. 登录超时设置Shell 层与 SSH 层缺一不可3.1 会话空闲自动登出TMOUT 的落地姿势TMOUT 是 bash以及部分其他 shell内置的一个环境变量单位为秒。在交互式 Shell 中如果用户在设定时间内没有任何输入Shell 会自动退出。这个机制直接作用于会话本身是最常用的登录超时方案。推荐写到 /etc/profile.d/ 下面比如创建一个 timeout.shcat /etc/profile.d/timeout.sh EOF # 会话空闲超时时间单位秒这里设置 10 分钟 TMOUT600 readonly TMOUT export TMOUT EOFreadonly 很关键防止用户在登录后自己把变量清掉。写成独立脚本而不是直接塞进 /etc/profile便于后续维护和排查也符合多数发行版的加载约定。文件创建后需要重新登录或者 source 一下才能对当前会话生效。对于已有登录会话可以手动执行source /etc/profile.d/timeout.sh然后按几个键验证一下。真正等到超时自动退出需要的时间比较久耐心点即可。TMOUT 有个容易踩的坑它只作用于交互式 Shell。如果你用 screen 或 tmux 挂了一个会话TMOUT 不会杀死 screen/tmux 里运行的进程这在某些场景下反而是好事——长任务不受影响。但如果要强制清理所有空闲会话单靠 TMOUT 不够需要配合会话审计手段。3.2 SSH 层的无效连接清理ClientAliveInterval 与 ClientAliveCountMax很多人不知道SSH 协议本身不支持直接设置空闲超时。sshd_config 里有 ClientAliveInterval 和 ClientAliveCountMax 这两个参数但它们做的并不是计时登出而是服务端定期向客户端发送心跳探测包确认连接是否还活着。常见的配置# 每 300 秒发送一次保活探测 ClientAliveInterval 300 # 连续 2 次无响应就断开 ClientAliveCountMax 2综合来看客户端若在约 600 秒内没有任何响应连接就会被服务端断开。这种方式最大的价值在于清理那些网络断开、客户端崩溃或休眠后残留的僵尸会话防止服务器连接数被无效占用。把 ClientAliveInterval 和 TMOUT 放在一起看TMOUT 管的是人没有操作ClientAlive 管的是通道已经不畅通。很多发行版默认可能没有启用这两个参数或者值比较宽松。建议在加固时至少加上 ClientAliveInterval 300 和 ClientAliveCountMax 2。如果你的场景是大量短连接负载均衡取值可以再短一些避免僵尸会话堆积。3.3 两层超时怎么配合一个典型场景我一般的推荐配置组合是TMOUT600 加 ClientAliveInterval300、ClientAliveCountMax2。用户闲下来超过 10 分钟Shell 层自动把会话退出如果网络出问题SSH 层也能在 10 分钟左右把死连接清掉。两层各管一摊互不冲突。有个容易被忽略的细节如果用户正在跑一个耗时的任务比如编译、打包、数据库迁移TMOUT 并不会把任务杀掉因为 bash 只有在交互提示符处才是空闲状态命令执行期间不算空闲。这是 TMOUT 设计上很人性化的一点。但如果任务是在交互式提示符下挂起的比如按了 CtrlZ 挂起一个前台进程长时间没操作TMOUT 依然会让 Shell 退出这一点要提前给使用者讲清楚。4. 配置落地的完整实操备份、修改、验证、回滚4.1 配置前准备先看当前系统在用什么模块动手之前第一步是确定你的系统属于哪个家族使用了哪套 PAM 规则。我习惯先看几个关键文件cat /etc/os-release grep -E pam_pwquality|pam_cracklib /etc/pam.d/system-auth /etc/pam.d/common-password 2/dev/null ls /etc/security/pwquality.conf如果是 RHEL 系重点是 /etc/pam.d/system-auth 和 /etc/pam.d/password-authDebian/Ubuntu 系重点看 /etc/pam.d/common-password。确认模块之后再做下一步。备份环节不能省cp /etc/security/pwquality.conf /etc/security/pwquality.conf.bak.$(date %F) cp /etc/ssh/sshd_config /etc/ssh/sshd_config.bak.$(date %F) cp /etc/login.defs /etc/login.defs.bak.$(date %F)备份文件名带日期方便日后定位问题和回滚。4.2 密码策略配置实操在 pwquality.conf 里建议填上以下内容然后保存minlen 12 dcredit -1 ucredit -1 lcredit -1 ocredit -1 retry 3 enforce_for_root如果系统里没有启用 pam_pwquality.so还需要在正确的 PAM 配置里补一行。RHEL/CentOS 通常在 system-auth 的 password 段Debian/Ubuntu 在 common-password 中。以 Ubuntu 为例需要确保 /etc/pam.d/common-password 里有类似password requisite pam_pwquality.so retry3如果原本是 pam_cracklib.so也可以直接替换为 pam_pwquality.so前提是系统已安装 libpam-pwquality 软件包。安装方式# Debian/Ubuntu apt install libpam-pwquality # RHEL/CentOS/Rocky yum install libpwquality改完后验证新策略是否生效。最直接的方法是用一个普通用户或新建临时测试用户尝试设置不符合规则的密码观察是否被拒绝。注意要用 passwd 命令来测不能通过 sudo 或 root 直接修改因为 PAM 策略会在 passwd 过程中强制执行。如果设置不满足复杂度要求会看到类似 BAD PASSWORD: The password is too simple 的提示。4.3 登录超时配置实操先配置 TMOUT 脚本cat /etc/profile.d/timeout.sh EOF TMOUT600 readonly TMOUT export TMOUT EOF然后配置 sshdcat /etc/ssh/sshd_config EOF ClientAliveInterval 300 ClientAliveCountMax 2 EOF修改 sshd 配置之后建议先做语法校验sshd -t输出为空就说明语法没问题。然后重新加载 sshd而不是直接 restart避免粗暴断开所有现有连接systemctl reload sshd有些发行版没有 systemd可以用/etc/init.d/ssh reloadreload 操作对当前连接的影响很小新配置会在新建连接时生效。4.4 效果验证不要关机重启就算完事实际验证超时是否生效可以临时把 TMOUT 改小测试。比如先执行export TMOUT10然后 10 秒不动终端如果 Shell 自动退出说明机制正常。再回到正式配置的 600 秒。SSH 层的验证可以看日志或者用另一个终端连接后拔掉网线/断网观察连接是否在预期时间内被清理。一般不用等太久几分钟就能在 auth.log 或 secure 日志里看到服务端主动断开的相关记录。如果验证过程中发现策略没生效大概率是以下几种原因PAM 模块没装、配置文件路径不对、改完没 reload、验证方式不对直接出现 shell 时没有被 TMOUT 控制。5. 高频问题与避坑经验我把常见的坑都踩了一遍5.1 配置了密码策略为什么老用户还可以用弱密码登录这是最容易让人误解的地方。pwquality 只会在设置或修改密码时校验强度它不会拦截已经存在的弱密码登录。也就是说如果你给某用户设置密码时用了弱密码策略不会自动重审它只有在下一次修改密码时才强制遵守新规则。所以加固完密码策略后还必须主动检查现有用户的密码强度最好让所有用户都重新设置一次密码或者通过 chage -M 90 强制他们在下次登录时改密。如果实在不想打扰线上用户至少在创建账号时严格遵循策略并且在流程上限定期改密。5.2 TMOUT 把正在跑的任务带崩了怎么办前面提到 TMOUT 只作用于交互式 Shell一般不会杀掉正在前台运行的命令。但有一种情况很容易被坑你写了一个脚本里面用 sleep 模拟长时间等待或者脚本在等待用户输入时挂起结果 TMOUT 超时把会话退出脚本进程收到 SIGHUP 后中断。排查这类问题时记住两点一是别把 TMOUT 设得太极端比如低于 60 秒对于正常运维操作太伤体验二是必须长期任务时优先使用 nohup、screen、tmux 或 systemd 服务来运行不要直接挂在交互式会话里。用 nohup 很简单nohup long-running-command 这样会话退出任务也能继续跑。5.3 老系统只用 pam_cracklib新老配置习惯的差异如果你还在维护 CentOS 6 或者更老的 Ubuntu可能只能见到 pam_cracklib.so。它的参数跟 pwquality 大同小异比如password requisite pam_cracklib.so retry3 minlen12 dcredit-1 ucredit-1 lcredit-1 ocredit-1区别主要是模块名和配置文件组织方式。老系统里没有独立的 pwquality.conf直接在 PAM 配置行后面写参数。新老切换时不要把两套配置混用否则可能出现策略重复叠加、行为不符合预期的现象。先看当前系统加载了哪个模块再来决定改哪里。5.4 安全性和易用性的平衡别把服务器折腾成堡垒我把密码复杂度设到过很极端的程度——长度 20四类字符全部必须有有效期 30 天。结果团队开发环境里的同事怨声载道经常有人忘记密码频繁找回最后反而增加了社工风险。后来我调整成生产环境 minlen16、四类字符至少各 1 个、90 天有效期开发环境 minlen12、至少数字和大小写、120 天有效期。这样既挡住了最常见的弱口令爆破又不会严重干扰正常使用。提示核心目标是把密码强度提升到字典攻击不可行的程度而不是把密码设到人脑记不住。12 位以上的混合密码已经完全能挡住暴力破解16 位是性价比很高的选择。5.5 千万别忘记 SSH 登录本身的降级策略很多人装完系统默认允许 root 直接 SSH 登录也允许密码登录。如果你的密码策略配置得再强root 账号依然是暴力破解的重点目标。建议同步做两件事一是把 root 直接 SSH 登录关掉改用普通用户加 sudo二是在有条件的场景下禁用密码登录、改用密钥验证。这个不在标题的核心范围内但跟密码复杂度强相关顺手做了效果会好很多。编辑 /etc/ssh/sshd_configPermitRootLogin no PasswordAuthentication no注意修改前一定要确认自己的密钥能正常登录否则改完你就是第一个被锁在门外的人。建议保留一个备用登录通道比如云平台控制台的 VNC 或救援模式。写在最后的个人体会我自己在多次服务器加固中最大的感受是安全配置不是越狠越好而是要确保每一处配置都真正发挥作用。比如 TMOUT 设了 600 秒但用户常年用密钥登录、所有会话都通过跳板机短时间操作那这个值就恰到好处反过来如果公司有人喜欢在晚上挂机跑数据TMOUT 直接设 60 秒肯定天天出问题。密码复杂度同理。与其追求一个谁也记不住的超强密码不如把长度基线拉到 12 位以上配合多类型字符要求再叠加合理有效期就已经能挡住绝大多数自动爆破工具。额外把 root 远程登录关掉、配好跳板机审计安全收益会大得多。还有一个小技巧分享给所有运维同行做任何系统安全配置前先花两分钟把原来的配置文件和当前状态记录到本地笔记标注好修改时间和原因。一个月后回来排查问题时你会发现这份记录比任何记忆都靠谱。服务器安全没有一劳永逸但只要把基础门槛抬上去就已经比大量裸奔的机器高一大截了。
平方复杂度无法被常规优化消除｜TaoToken 统一 Key 通道实测)
