Linux服务器安全加固：密码复杂度策略与SSH登录超时设置实战-开发者社区

最近帮朋友处理一台被爆破的服务器，翻日志的时候看到几千条密码尝试记录，从 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 的登录验证、密码修改等认证环节，默认通过 PAM（Pluggable Authentication Modules，可插拔认证模块）框架来统一管理。你执行 passwd 修改密码时，系统会走 /etc/pam.d/ 目录下对应的认证规则，比如系统通用规则在 system-auth（RHEL/CentOS 系）或者 common-password（Debian/Ubuntu 系）。

在这个链条里，真正负责密码强度检查的模块是 pam_pwquality.so。旧一些的系统用的是 pam_cracklib.so，两者底层库不同，但参数设计逻辑非常像。Ubuntu 和 CentOS 的新版本基本都默认支持 pam_pwquality.so，如果你的系统里还没启用，需要确认一下 PAM 配置文件里有没有一行类似：

password requisite pam_pwquality.so retry=3

如果没有，就需要手动加进去。这一步是所有密码复杂度配置的起点。

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_root

2.3 密码有效期与老化规则：别让密码"一次修改，永久有效"

密码复杂度解决的是"强不强"的问题，而密码老化解决的是"隔多久必须换一次"的问题。运维人员经常忽略后者，结果导致 3 年前设的密码一直在用，哪怕当时是强密码，也有泄露或被拖库的风险。

3. 登录超时设置：Shell 层与 SSH 层缺一不可

3.1 会话空闲自动登出：TMOUT 的落地姿势

TMOUT 是 bash（以及部分其他 shell）内置的一个环境变量，单位为秒。在交互式 Shell 中，如果用户在设定时间内没有任何输入，Shell 会自动退出。这个机制直接作用于会话本身，是最常用的登录超时方案。

推荐写到 /etc/profile.d/ 下面，比如创建一个 timeout.sh：

cat > /etc/profile.d/timeout.sh << 'EOF' # 会话空闲超时时间，单位秒，这里设置 10 分钟 TMOUT=600 readonly TMOUT export TMOUT EOF

readonly 很关键，防止用户在登录后自己把变量清掉。写成独立脚本而不是直接塞进 /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 两层超时怎么配合：一个典型场景

我一般的推荐配置组合是：TMOUT=600 加 ClientAliveInterval=300、ClientAliveCountMax=2。用户闲下来超过 10 分钟，Shell 层自动把会话退出；如果网络出问题，SSH 层也能在 10 分钟左右把死连接清掉。两层各管一摊，互不冲突。

有个容易被忽略的细节：如果用户正在跑一个耗时的任务，比如编译、打包、数据库迁移，TMOUT 并不会把任务杀掉，因为 bash 只有在交互提示符处才是空闲状态，命令执行期间不算"空闲"。这是 TMOUT 设计上很人性化的一点。但如果任务是在交互式提示符下挂起的（比如按了 Ctrl+Z 挂起一个前台进程），长时间没操作，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-auth；Debian/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 retry=3

如果原本是 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' TMOUT=600 readonly TMOUT export TMOUT EOF

然后配置 sshd：

cat >> /etc/ssh/sshd_config << 'EOF' ClientAliveInterval 300 ClientAliveCountMax 2 EOF

修改 sshd 配置之后，建议先做语法校验：

sshd -t

输出为空就说明语法没问题。然后重新加载 sshd，而不是直接 restart，避免粗暴断开所有现有连接：

systemctl reload sshd

有些发行版没有 systemd，可以用：

/etc/init.d/ssh reload

reload 操作对当前连接的影响很小，新配置会在新建连接时生效。

4.4 效果验证：不要关机重启就算完事

实际验证超时是否生效，可以临时把 TMOUT 改小测试。比如先执行：

export TMOUT=10

然后 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 retry=3 minlen=12 dcredit=-1 ucredit=-1 lcredit=-1 ocredit=-1

区别主要是模块名和配置文件组织方式。老系统里没有独立的 pwquality.conf，直接在 PAM 配置行后面写参数。新老切换时，不要把两套配置混用，否则可能出现策略重复叠加、行为不符合预期的现象。先看当前系统加载了哪个模块，再来决定改哪里。

5.4 安全性和易用性的平衡：别把服务器折腾成堡垒

我把密码复杂度设到过很极端的程度——长度 20，四类字符全部必须有，有效期 30 天。结果团队开发环境里的同事怨声载道，经常有人忘记密码，频繁找回，最后反而增加了社工风险。

后来我调整成：生产环境 minlen=16、四类字符至少各 1 个、90 天有效期；开发环境 minlen=12、至少数字和大小写、120 天有效期。这样既挡住了最常见的弱口令爆破，又不会严重干扰正常使用。

提示：核心目标是把密码强度提升到"字典攻击不可行"的程度，而不是把密码设到人脑记不住。12 位以上的混合密码已经完全能挡住暴力破解，16 位是性价比很高的选择。

5.5 千万别忘记 SSH 登录本身的降级策略

很多人装完系统默认允许 root 直接 SSH 登录，也允许密码登录。如果你的密码策略配置得再强，root 账号依然是暴力破解的重点目标。建议同步做两件事：一是把 root 直接 SSH 登录关掉，改用普通用户加 sudo；二是在有条件的场景下禁用密码登录、改用密钥验证。这个不在标题的核心范围内，但跟密码复杂度强相关，顺手做了效果会好很多。

编辑 /etc/ssh/sshd_config：

PermitRootLogin no PasswordAuthentication no

注意：修改前一定要确认自己的密钥能正常登录，否则改完你就是第一个被锁在门外的人。建议保留一个备用登录通道，比如云平台控制台的 VNC 或救援模式。

写在最后的个人体会

我自己在多次服务器加固中最大的感受是：安全配置不是越狠越好，而是要确保每一处配置都真正发挥作用。比如 TMOUT 设了 600 秒，但用户常年用密钥登录、所有会话都通过跳板机短时间操作，那这个值就恰到好处；反过来，如果公司有人喜欢在晚上挂机跑数据，TMOUT 直接设 60 秒肯定天天出问题。

密码复杂度同理。与其追求一个"谁也记不住"的超强密码，不如把长度基线拉到 12 位以上，配合多类型字符要求，再叠加合理有效期，就已经能挡住绝大多数自动爆破工具。额外把 root 远程登录关掉、配好跳板机审计，安全收益会大得多。

还有一个小技巧分享给所有运维同行：做任何系统安全配置前，先花两分钟把原来的配置文件和当前状态记录到本地笔记，标注好修改时间和原因。一个月后回来排查问题时，你会发现这份记录比任何记忆都靠谱。服务器安全没有一劳永逸，但只要把基础门槛抬上去，就已经比大量裸奔的机器高一大截了。

Linux服务器安全加固：密码复杂度策略与SSH登录超时设置实战