必须在启用MFA时立即生成并离线保管10个一次性恢复码，它仅用于TOTP完全失效时手工重置配置，用一次即作废，不可重新生成；须打印锁入保险柜或加密存入可信密码管理器，严禁明文存储。
关键业务必须在启用MFA的**同时生成并离线保管恢复码**，不能等出问题再补。它不是备用登录方式，而是唯一合法的MFA重置凭证，用一次即作废，且无法重新生成——除非主动删掉配置重来。
生成时必须立即保存10个一次性码
运行 google-authenticator 启用TOTP后，终端会直接显示10组6位恢复码（格式如：XXXXXX XXXXXX …）。这些码与用户密钥强绑定，系统不会二次提供。
- 推荐做法：打印出来，锁进物理保险柜；或加密存入Bitwarden、1Password等可信密码管理器
- 严禁行为：复制粘贴到本地文本文件、Git仓库、邮箱草稿、云笔记、服务器/home目录下
- 注意：屏幕截图也存在风险，尤其在共享终端或远程桌面场景中
按权限分级保管，避免单点失控
恢复码本质是高危凭证，需匹配最小权限原则和职责分离机制：
- 普通业务账号：恢复码只由本人持有，管理员不得默认归档或备份
- 运维类系统账号（如deploy、backup）：建议拆分为两组（如5+5），由两名授权人员分别保管，重置操作需双人到场确认
- 每季度审计：检查哪些账号的恢复码已全部使用、超期（建议18个月更新）、或保管方式失效（如密码管理器主密钥变更未同步）
明确恢复路径，不参与日常登录
恢复码不走PAM校验流程，也不用于SSH登录。它的唯一用途是：当TOTP完全不可用（手机丢失、App崩溃、时间严重偏移）时，人工重置MFA配置。
- 标准恢复步骤：用已有SSH密钥或root权限登录 → 删除 ~/.google_authenticator → 重新运行 google-authenticator → 输入新生成的恢复码完成替换
- 若连SSH密钥也无法使用，则依赖带外通道（iDRAC/IPMI）进入单用户模式操作
- 切勿误以为输入恢复码就能“跳过验证”——它不触发任何自动流程，纯手工介入
避开三个常见失败原因
即使有恢复码，以下配置错误也会导致重置失败：
- 权限错误：/home/username/.google_authenticator 文件权限必须为 600，属主必须为对应用户，否则PAM拒绝读取
- 时间偏差：服务器时间误差超过30秒，TOTP校验失效；虽不影响恢复码本身，但重置前必须先校准（sudo chrony -q 或 sudo ntpdate -s time.google.com）
- PAM顺序错位：在 /etc/pam.d/sshd 中，TOTP行若放在 @include common-auth 之后且控制标志为 sufficient，会导致密码正确就跳过TOTP，削弱MFA意义，也模糊恢复边界
