核心是让认证依赖YubiKey内不可导出私钥并绑定可信上下文：优先FIDO2/ECDSA-SK（ssh-keygen -t ecdsa-sk），次选PIV或GPG；严格绑定服务器主机名防钓鱼，PAM分层控制避免锁死，预配10个离线恢复码，启用Secure Boot+IMA确保可信链。
服务器多因素认证配合YubiKey这类硬件U密钥，核心是把“你拥有的东西”（物理设备）真正用起来，而不是只当个备用令牌。它不是加个插件就完事，关键在于让认证流程依赖设备内芯片的不可导出私钥，并绑定可信上下文（比如服务器主机名或域名），从而防钓鱼、抗重放、杜绝私钥泄露。
选对模式：优先用 FIDO2/ECDSA-SK，次选用 PIV 或 GPG 智能卡
FIDO2 是目前最简洁、最安全的路径，尤其适合 SSH 登录：
- 用 ssh-keygen -t ecdsa-sk 直接生成密钥，私钥全程不出设备，触碰即签名
- 要求客户端系统装好 libfido2，服务端 OpenSSH ≥ 8.2；云控制台（如 AWS EC2 网页 SSH）不支持，必须终端直连
- 若服务器版本老旧（如 RHEL 7/CentOS 7），可退回到 PIV 模式：用 YubiKey 配置为智能卡，通过 OpenSC + ssh-pkcs11-helper 提供 PKCS#11 接口
- GPG 模式适合已有 GnuPG 工作流的环境：在 YubiKey 上生成仅含 Authentication 能力的 RSA 密钥，由 gpg-agent 代理 SSH 连接，私钥永不导出
绑定可信上下文：让密钥只认你的服务器
硬件密钥的安全性一大来源就是“域名/主机名绑定”：
- FIDO2 密钥在注册时会记录目标服务器的 hostname 或 FQDN（如 prod-db.example.com），登录时自动校验；如果攻击者伪造一个相似域名（如 prod-db-example.com），密钥直接拒绝响应
- PIV/GPG 模式虽无自动域名检查，但可通过 authorized_keys 中的 environment= 和 from= 选项 限制密钥仅用于特定主机或执行受限命令
- 不要把同一枚 YubiKey 的同一个密钥用于多个不相关系统，避免单点失陷扩散风险
服务端配置要分层，避免“一锁锁死”
别把所有用户、所有登录方式都强制走 U 密钥——这容易导致运维中断：
- 对普通用户 SSH 登录，设为 required 使用 FIDO2 密钥；对 root 或关键管理账户，建议组合策略：密码 + U 密钥，或密钥 + PAM 二次验证
- PAM 栈中慎用 pam_u2f.so required，推荐用 sufficient 或配合 auth [success=ok default=ignore] 实现降级逻辑
- 务必预配至少 10 个离线一次性恢复码，存于加密 USB 或打印后锁进保险柜；禁止回退到纯密码登录
- 启用 Secure Boot + IMA（Integrity Measurement Architecture），确保从固件到 SSH 服务的启动链可信，防止运行时篡改认证模块
客户端使用要轻量、可验证
日常连接不能靠记忆命令，得有稳定、可复现的操作习惯：
- 生成密钥时加 -C "admin@prod-db" 注释，方便识别用途；触碰提示出现后才操作，避免误按
- 上传公钥用 ssh-copy-id -i ~/.ssh/id_ecdsa_sk.pub user@host，比手动复制更少出错
- 测试连接时加 -o IdentityAgent=none，绕过可能冲突的 ssh-agent，确保走的是硬件签名路径
- 定期运行 ssh-add -l 查看当前加载的密钥，确认显示 “cardno:xxx” 或 “ecdsa-sk” 字样，而非普通文件路径
