Linux口令哈希由PAM调用glibc在CPU完成，存于/etc/shadow，不依赖HSM；HSM仅用于SSH密钥托管、PAM双因素认证、LUKS2密钥解封等增强场景，不参与基础口令验证。
Linux系统账户口令不直接存储明文，而是通过单向哈希（如SHA-512）加盐（salt）后存入/etc/shadow。硬件安全模块（HSM）本身不参与日常登录验证，但可通过特定方式增强密钥管理与认证环节的安全性。
口令存储机制本身不依赖HSM
标准Linux PAM和shadow机制完全在操作系统内完成哈希运算，口令散列值始终驻留本地磁盘。HSM无法替代crypt(3)或glibc的哈希流程，也不介入login、su或sshd的密码校验路径。
- 所有用户口令哈希均生成于CPU，由PAM模块（如
pam_unix.so）调用系统级加密库完成 -
/etc/shadow中每行包含哈希字符串、盐值、迭代次数等字段，格式为$6$salt$hash（SHA-512）或$y$j9T$...（yescrypt） - HSM不持有、不缓存、不转发任何用户口令或其派生密钥
可集成HSM的增强场景
HSM真正发挥作用的位置在需要长期密钥保护或高保障身份核验的扩展环节，而非基础口令验证：
-
SSH密钥托管：使用
openssh8.2+支持的sk-provider接口，将FIDO2安全密钥或PKCS#11 HSM作为私钥存储后端，实现无文件私钥登录 -
PAM双因素认证：通过
pam_pkcs11.so或pam_succeed_if.so联动HSM签发的X.509证书，要求用户插入智能卡并输入PIN才能完成第二因子验证 -
全盘加密密钥保护：LUKS2支持将主密钥封装（wrapped key）交由HSM执行解封操作，例如使用
clevis bind luks -t tpm2 ...或PKCS#11后端，使磁盘解锁依赖硬件可信根
实际部署注意事项
集成HSM需明确边界：它不提升口令哈希强度，而是转移密钥生命周期风险点。常见误区需避免：
- 不要试图用HSM重写
pam_unix——既无标准接口，也破坏POSIX兼容性 - HSM厂商提供的PKCS#11库必须通过
libp11或OpenSSL engine正确加载，且需配置/etc/pkcs11/modules/xxx.module - 启用HSM相关PAM模块时，务必保留本地fallback路径（如
[default=bad default=ignore]），防止HSM离线导致全员锁死 - 审计日志应同时记录HSM操作（如
pkcs11-tool --sign调用）与系统认证事件（auth.log），便于关联分析
口令安全的核心仍在策略与实践：强盐值、足够迭代轮数（SHA-512默认5000轮，建议调至65536）、定期轮换、禁用弱算法（如MD5、DES）。HSM是纵深防御中的一环，不是口令存储的替代方案。
