接手过银河麒麟V10桌面系统的管理员，大多会有同一个感受：服务器的安全基线文档满天飞，桌面机的登录安全和密码策略却往往管得比较粗。大家知道要设密码，可很少有人把登录失败锁定、密码复杂度、图形锁屏入口这些点串成一套完整策略。我在运维里见过一个反复出现的通病：办公机上的普通账号用姓名缩写加123当密码，账号永不过期，还开着能被内网任意机器访问的远程登录服务，结果遭遇一轮密码扫描，机器直接沦陷。问题不在系统漏洞，而在登录和密码这两个最基础的关口根本没有留下防线。

这篇指南是银河麒麟V10桌面版系统管理员视角的实战配置笔记，覆盖密码质量、密码老化、登录失败锁定、LightDM自动登录、UKUI锁屏、SSH加固与sudo/su边界等内容，适合所有需要批量维护V10桌面机的运维和IT支持人员。我以Debian系构建的V10桌面版为例，PAM配置集中在/etc/pam.d/common-*系列；如果你的版本是RHEL系风格，把路径换成system-auth即可，原理完全一致。

1. 桌面版V10的账户安全现状：为什么先动登录和密码

1.1 桌面机往往是被忽视的突破口

很多单位对服务器的账户安全抓得紧，对桌面机却基本处于“散养”状态。服务器上会有账号周期巡检、强密码要求、登录失败锁定，桌面机往往装完系统、分好账号就再也不管。但桌面机恰恰是内网渗透里最喜欢碰的一类资产：它长期在线，防护能力弱，而且一旦被拿下一个普通用户，攻击者就可以用它做跳板扫描内网、尝试横向移动。更麻烦的是，桌面机的使用者不是专业IT人员，你告诉他“密码要设复杂一点”，他转头就设置成公司名加年份，满脑子记不住。

我在实际维护中看到的问题高度集中在四点：第一，密码长度和复杂度没有任何强制，用户想怎么设就怎么设；第二，密码永不过期，有人从入职到离职几年没改过密码；第三，连续输错密码没有锁定机制，攻击者可以慢慢爆破；第四，远程登录服务和自动登录开着，等于把大门钥匙挂在了门框上。这四点单看都是小事，叠在一起就是一台内网裸奔机器。所以这篇指南的顺序也很明确：先堵住口令相关的弱项，再收紧各个登录入口，最后用一套验证流程确认策略真的生效。

1.2 一次配置，多个入口生效：理解PAM

银河麒麟V10桌面版的登录认证由PAM统一管理。PAM的全称是“可插拔认证模块”，你可以把它理解成机场安检通道：不管你是坐国内航班还是国际航班，进安检口都要过同一套流程，刷证件、扫行李、核对登机牌。对应到系统里，图形登录、SSH登录、终端登录、sudo提权，本质上都是“不同的航班”，但它们都会经过PAM这条安检流水线，而安检规则集中写在几份配置文件里。

V10桌面版（Debian系）的PAM核心配置在/etc/pam.d/目录下，重点这几份：

后面要配的密码复杂度、登录失败锁定，全都是通过改这些PAM文件生效的。这么做的好处是覆盖面广：你改一处配置，图形登录、SSH、终端、sudo全都统一执行，不会出现“登录界面还在收弱密码，终端却已经强制复杂密码”的割裂感。坏处也很直接：改错了，可能连root都登不进去。所以每次动PAM配置前，一定要保留至少一个已建立好的root会话，并且先备份原文件，再开始操作。

2. 密码策略落地：从pwquality到login.defs再到chage

2.1 复杂度的真正裁判是pam_pwquality

很多人以为修改密码复杂度是改/etc/login.defs，其实login.defs管的是密码老化周期，比如最长使用多少天、过期前多少天提醒，它不做复杂度校验。真正的复杂度检查由PAM模块pam_pwquality负责，配置文件在/etc/security/pwquality.conf。

先看一下当前配置：

grep -Ev '^#|^$' /etc/security/pwquality.conf

如果是刚装好的系统，大概率看到的是空输出或者被注释掉的默认行。我给出一份适用于办公环境的推荐配置，逐行说明含义：

# 最小密码长度 minlen = 12 # 至少包含1个数字（负值表示“至少出现N次”） dcredit = -1 # 至少包含1个大写字母 ucredit = -1 # 至少包含1个小写字母 lcredit = -1 # 至少包含1个特殊字符 ocredit = -1 # 最多允许连续3个相同字符，例如 aaa maxrepeat = 3 # 同一类字符最多连续出现4次，例如 abcd1234 会被扣分 maxclassrepeat = 4 # 新密码中不能包含用户名 reject_username # 提示重试次数 retry = 3

改完后执行：

vi /etc/security/pwquality.conf

然后重启相关服务吗？不需要。PAM模块的配置是每次认证时实时读取的，改完文件立刻对新改密码操作生效。但是要注意一个关键点：复杂度策略只影响“修改密码”这个动作，不会回头强制检查存量密码。也就是说，你配了minlen=12，但用户现有密码还是abc123，它不会被自动判死，只有用户下一次改密码时，新密码才必须满足这些要求。想让存量密码也被强制洗一遍，就得靠老化策略和chage命令。

2.2 老化策略：login.defs 管新建用户，chage 管存量用户

密码老化周期配置在/etc/login.defs里。V10桌面版刚装好的默认值通常是：

PASS_MAX_DAYS 99999 PASS_MIN_DAYS 0 PASS_WARN_AGE 7

99999等于永远不会过期，这显然不行。办公场景我给的标准是：最长使用90天，最短使用7天（防止用户改完立刻又改回旧密码），过期前14天提醒。

sed -i 's/^PASS_MAX_DAYS.*/PASS_MAX_DAYS 90/' /etc/login.defs sed -i 's/^PASS_MIN_DAYS.*/PASS_MIN_DAYS 7/' /etc/login.defs sed -i 's/^PASS_WARN_AGE.*/PASS_WARN_AGE 14/' /etc/login.defs

但这里有个非常容易踩的坑：login.defs只对之后“新建”的用户生效，已经存在的用户不受影响。所以新策略落地后，必须针对存量账号批量设置老化参数，我用chage命令配合一个循环来搞定：

# 列出所有能登录系统的普通用户（排除root和系统账号） for u in $(awk -F: '($3 >= 1000 && $1 != "nobody") {print $1}' /etc/passwd); do chage -M 90 -m 7 -W 14 "$u" done

awk的条件可以根据现场情况调整，有的环境普通用户UID从1000开始，有的从1001开始，先跑一遍看输出对不对再执行。执行完可以抽查一个账号：

chage -l username

输出里Maximum number of days between password change应该是90，Warning days before password expiration应该是14，说明存量账号已经被纳入老化管理。

2.3 用户习惯改不了，就强制第一次登录改密

就算设了90天过期，用户也可能用passwd改完又改回原来的Name123!。这不是复杂度能完全解决的，但可以让策略在“第一次登录”就强制改密。做法是把用户的密码过期日期设为0，代表密码已过期，下一次登录必须修改：

chage -d 0 username

执行后，用户无论是图形界面登录还是SSH登录，都会被系统要求先设置新密码，且新密码必须满足pam_pwquality的复杂度规则。这个操作特别适合给新发出去的机器设初始密码：管理员设一个临时初始密码，然后chage -d 0丢给使用者，强制他改成自己记得住的强密码，管理员自己也不知道最终密码，这也是账号安全里比较推荐的做法。

3. 登录失败锁定：pam_faillock配置及几个容易翻车的顺序问题

3.1 为什么不用脚本而是选PAM模块

暴力破解的防御思路很简单：连续输错N次就锁定一段时间。有人会写个Shell脚本监控日志，看到失败次数多就封IP，这个可以做，但不够通用。更好的方案是在PAM层做登录失败锁定，因为PAM覆盖所有认证入口，不管你是图形界面登录、SSH还是终端，只要是密码认证失败，都逃不过这层计数。V10桌面版常用的模块是pam_faillock，它在认证流程里分三个阶段工作：preauth（认证前先检查是否已被锁定）、authfail（认证失败时记录次数）、authsucc（认证成功后重置计数）。

3.2 标准配置步骤

建议先备份：

cp /etc/pam.d/common-auth /etc/pam.d/common-auth.bak cp /etc/pam.d/common-account /etc/pam.d/common-account.bak

然后编辑/etc/pam.d/common-auth，在pam_unix.so这行之前插入以下内容：

auth required pam_faillock.so preauth silent audit deny=5 unlock_time=900 auth [default=die] pam_faillock.so authfail silent audit deny=5 unlock_time=900 auth sufficient pam_faillock.so authsucc silent audit deny=5 unlock_time=900 auth [success=1 default=ignore] pam_unix.so nullok_secure

参数含义：deny=5表示连续失败5次锁定，unlock_time=900表示锁定900秒，也就是15分钟。silent和audit一个是减少冗余输出，一个是在审计日志里记录细节，建议加上。这里要特别注意：common-auth文件原本的内容里可能还有pam_deny.so、pam_permit.so这些行，不用删，只要把三行pam_faillock插在pam_unix.so之前即可，原有流程顺序不要乱动。

接着编辑/etc/pam.d/common-account，在文件末尾追加一行：

account required pam_faillock.so

这行的作用是让账户阶段也会检查锁定状态。改完后PAM配置即时生效，不需要重启服务，但已经建立的旧会话不受影响，新登录才走新策略。

3.3 三个最容易翻车的顺序问题

我一开始配pam_faillock的时候翻过好几次车，问题基本都出在顺序和位置。

第一个坑：把preauth放到了pam_unix.so后面。这样用户每次都得先走完整密码验证，再检查锁定，等于给爆破者留足了验证密码的机会，锁定机制形同虚设。preauth必须在认证流程最前面。

第二个坑：authfail那行的控制标识写错。我见过有人写成required而不是[default=die]，结果失败计数也能记，但某些条件下认证结果判断会异常，明明用户输对了密码，却因为之前的失败记录被判定为认证失败。标准写法里[default=die]的含义是“一旦走到这行说明认证已失败，直接终止本层认证”，这个语义不要随意改。

第三个坑：文件里存在auth sufficient pam_permit.so这类“无条件放行”的行，而且位置在pam_faillock之前。这样所有请求都会提前被放行，后续的锁定检查根本不会执行。新装系统里通常没有这一行，但如果你做过自定义或者装了某些一键加固脚本，先检查一下，确保没有类似的放行逻辑插在前面。

3.4 锁定后怎么查看、解锁和看日志

某个账号被锁定后，用faillock命令查看：

faillock --user username

如果确实有失败记录，会看到When和Count等字段。确认无误后手动解锁：

faillock --reset --user username

查看全局锁定相关日志，V10桌面版的认证日志通常在/var/log/auth.log：

grep faillock /var/log/auth.log | tail -50

这里有个很实用的经验：用户被锁定时，输对的密码也会登录失败，因为preauth阶段就直接拒绝了。如果你配置后发现某账号“密码明明是对的但登不进去”，第一反应去看faillock --user，八成是之前手滑输错了几次触发了锁定。这种问题在图形登录界面尤其常见，因为用户以为的打错一次和系统统计的连续失败次数不一定一致。

4. 登录入口的全面体检：LightDM、锁屏、SSH与提权边界

4.1 LightDM：自动登录和访客登录必须关掉

图形桌面登录在V10桌面版上默认由LightDM管理。安全配置里最容易被忽略的，就是LightDM的自动登录和访客登录。自动登录意味着开机后直接进桌面，根本不经过PAM认证，前面配的锁定和复杂度等于自动失效；访客登录则是给攻击者提供了一个无密码的临时入口，虽然权限受限，但足够做信息收集和内网探测了。

检查/etc/lightdm/lightdm.conf，重点关注这几项：

[Seat:*] autologin-user= autologin-user-timeout=0 allow-guest=false

autologin-user一定要留空或者直接把行删掉，allow-guest必须设为false。另外还要注意，有的管理员会习惯性地在/etc/lightdm/lightdm.conf.d/目录下写自定义配置片段，这些片段优先级可能覆盖主配置，检查时要一起看：

grep -rEv '^#|^$' /etc/lightdm/lightdm.conf /etc/lightdm/lightdm.conf.d/ 2>/dev/null

如果确认有autologin-user=xxx这一行，去掉后重启lightdm服务：

systemctl restart lightdm

4.2 UKUI桌面锁屏与唤醒认证

密码策略做得再好，用户离开座位不锁屏，也是白搭。V10桌面版默认是UKUI桌面环境，锁屏设置可以通过gsettings调整。我的建议是设置两分钟无操作进入待机并立即锁屏，唤醒时必须重新输密码：

# 设置无操作延迟（秒） gsettings set org.ukui.screensaver idle-delay 120 # 启用锁屏 gsettings set org.ukui.screensaver lock-enabled true # 待机后不额外延迟，立即锁定 gsettings set org.ukui.screensaver lock-delay 0

不同版本的UKUI桌面，schema名称可能有差异，有的版本键名是org.ukui.screensaver.lock-enabled，有的是org.ukui.screensaver idle-delay。如果执行gsettings set时报错提示找不到schema，可以用dconf-editor图形化工具进去搜screensaver，确认准确的键名再改。批量部署时可以写个脚本，把所有办公机的锁屏策略统一起来。

有一个细节容易被忽略：如果用户选择“休眠”而不是“待机”，唤醒后系统可能直接回到桌面而不要求密码。要让休眠唤醒也走认证，需要确认电源管理设置里对“从休眠恢复”这个动作要求输密码。这一步不是标准配置项，建议在发机前实际休眠一次、唤醒一次做验证。

4.3 SSH：远程管理入口的收敛

桌面机虽然以图形界面为主，但很多管理员喜欢开SSH远程维护。SSH一旦开放，就是最直接的暴力破解入口。编辑/etc/ssh/sshd_config：

PermitRootLogin no MaxAuthTries 3 LoginGraceTime 30 PubkeyAuthentication yes PasswordAuthentication no

这里我要特别提醒：如果还没有部署SSH公钥，不要急着把PasswordAuthentication改成no，否则你会把自己锁在外面。建议流程是：先把公钥复制到目标机器，验证公钥登录没问题，再关掉密码登录。改完配置执行：

systemctl restart ssh

MaxAuthTries 3配合前面的pam_faillock，SSH的暴力破解会被双保险限制住：同一连接最多尝试3次，密码错误累计5次又会锁定账号。不过要注意，pam_faillock和MaxAuthTries的计数逻辑不完全一样，pam_faillock是跨连接累计的，这更好，因为攻击者断开重连也逃不掉。

4.4 sudo/su 的权限边界要单独收紧

密码策略控制了登录，但登录进来之后，普通用户能不能提权到root，也要纳入安全基线。V10桌面版里绝大多数用户是普通账号，可很多办公机器为了让员工能装软件，直接给了一堆sudo权限，这等于把“普通用户”升级成了“准管理员”。

检查当前拥有sudo权限的用户：

grep -E '^sudo|^wheel' /etc/group

原则是最小化，只保留确实需要做系统维护的账号。如果某些用户只是偶尔需要执行一两条管理命令，可以考虑限定命令范围，而不是放行全部。另外，su命令默认允许任何人切换到root，只要知道root密码。如果不希望普通用户随意su，可以配置pam_wheel.so，只允许指定组使用su：

# /etc/pam.d/su auth required pam_wheel.so group=sudo

这样只有sudo组的成员能su到root，其他用户会被拒绝。配置前先确认组名是sudo还是wheel，V10桌面版默认通常是sudo组。

5. 配置完成后的五分钟验证清单与三个高频坑

5.1 五分钟验证流程

每次配完登录安全和密码策略，我都会强制自己做一遍完整验证，否则心里不踏实。验证流程如下：

1. 用passwd给测试账号设置一个弱密码，例如123456，看系统是否拒绝。如果拒绝了，输出里通常会有BAD PASSWORD之类的提示。
2. 设置一个满足复杂度的密码，比如Kylin@2024Cloud，确认修改成功。
3. 在一个终端里连续输错5次密码，然后输入正确密码，确认仍然被拒绝，进程退出码非0。
4. 用faillock --user 测试账号查看锁定记录，确认计数为5，然后faillock --reset解锁。
5. 在图形登录界面重复第3步，确认图形登录也走锁定策略。
6. 如果是远程管理场景，再从SSH连一次，确认MaxAuthTries和pam_faillock都正常。
7. 查日志确认没有大量认证失败的异常记录。

这套流程跑完，基本可以确定策略是真的生效了，而不是只写进了配置文件。

5.2 坑位一：改了老化策略，现有用户却永远不弹改密提示

这是最经常被问的问题。login.defs改成了90天，结果老用户的密码状态还是never，完全没有到期倒计时。原因前面提过：login.defs只对新建用户生效。解决办法就是批量执行chage，这段命令建议直接写进你的运维脚本里：

for u in $(awk -F: '($3 >= 1000 && $1 != "nobody") {print $1}' /etc/passwd); do chage -M 90 -m 7 -W 14 "$u" done

执行后用passwd -S 用户名查看状态，出现P 01/01/2025 0 90 7 -1这串输出，才说明老化策略已经覆盖到该账号。

5.3 坑位二：登录密码改了，一解锁就弹“密钥环”框

很多用户改了登录密码之后，下一次解锁桌面会弹出一个窗口，要求输入旧密码才能解锁“密钥环”。这个跟登录安全和密码策略无关，它是桌面环境自带的密钥环机制在独立保存密码和证书。用户登录密码变了，密钥环密码还停留在旧状态，于是系统要求用户手动更新一次。从安全角度这不是坏事，但它会极大影响用户对密码策略的配合度。

处理办法有两种：一是在弹出的窗口里输入旧登录密码，让密钥环正常解锁并自动更新到新密码；二是如果用户觉得麻烦，可以删除当前用户下的密钥环文件，重新初始化：

rm -rf ~/.local/share/keyrings/*

删除后重启会话，系统会重新创建密钥环。这个操作会让Wi-Fi密码、浏览器保存的凭据等需要重新录入，建议给用户提前说明，不要直接删用户数据。

5.4 坑位三：PAM策略改了，图形登录却“不锁头”

如果你按第3章的配置改完后，终端登录已经能正常锁定，但图形登录界面连续输错却不受影响，大概率是LightDM的PAM配置文件没有走common-auth。排查方法很简单：看/etc/pam.d/lightdm这个文件，里面有没有@include common-auth这一行。V10桌面版默认是有的，但如果别人改过，或者你装的是旧版本，可能缺失。补上这一行，然后重启LightDM即可。

还有一种可能：图形登录界面用的不是LightDM自带的greeter，而是切换到xrdp、VNC这类远程桌面服务登录。这类服务有自己独立的PAM配置，pam_faillock覆盖不到是正常现象。对远程桌面入口，我的建议是不要直接暴露到网络上，要么绑定管理网段，要么通过跳板机访问，不要指望一套PAM配置解决所有入口。

5.5 应急恢复预案

配置PAM最怕的就是把自己锁在门外。以防万一，每次改动前要有一个可执行的应急方案。我的惯例是：在机器上保留一个已经验证过的root会话，不关闭；同时在另一台机器上保持SSH root登录可用。万一真的把PAM改崩溃了，先尝试用普通账号登录sudo su恢复备份；如果连普通账号都登不进，就利用物理控制台切到tty2试试本地root登录；再不行，重启进入恢复模式，用维护Shell恢复/etc/pam.d/common-auth.bak。

关键点其实不是“怎么恢复”，而是“提前备份”。只要备份在，恢复永远是几分钟的事。我见过太多直接在vi里改完PAM就关闭会话的案例，最后只能拿Live系统去挂载硬盘救场，这种血泪经验写出来，希望后来的人别再踩。

配置这种事，最怕改完就忘了自己改过什么。我现在每台V10桌面机做完这套配置，都会把/etc/pam.d/common-*的改动差异用diff导出保存，命令记录到/root/security-baseline.txt，同时保留.bak文件。看上去多花两分钟，下次系统升级、重装或者排查问题，直接照方抓药，能省下好几个晚上的时间。安全配置从来不是“配完就一劳永逸”，桌面机用户习惯一变，账号出口就变，过几个月回头看一眼策略，总是能找到新的可收紧的地方。