SSH 首次连接依赖用户手动核对主机密钥指纹，易遭中间人攻击。德国柏林工业大学 2022 年初大规模测量显示，仅万分之一域名部署 SSHFP 记录，且不足半数配置正确，自动化验证落地率极低。
SSHFP 自动化验证机制：
SSHFP 记录将主机公钥指纹存入 DNS，OpenSSH 客户端可自动查询对比，免除用户交互。RFC 4251 定义三种验证途径：人工核对、证书颁发机构签署、DNS 分发。人工方式依赖带外获取指纹且易出错；CA 方式需向所有客户端分发根密钥并签署所有主机密钥，部署复杂；DNS 方式仅需管理员在权威服务器添加 SSHFP 记录，客户端开启 VerifyHostKeyDNS 即可实现零交互验证，前提是域名启用 DNSSEC 防止记录篡改。
部署规模与配置质量：
2022 年初测量期间，全球域名中仅 1/10,000 存在 SSHFP 记录；在已部署记录的样本中，正确配置比例低于 50%。研究代码与数据已公开，论文于 CANS 2022 发表，并在 DNS-OARC 39 报告初步结果。原文未给出具体数据的域名总量、记录类型分布（RSA/ECDSA/Ed25519）、错误配置分类（指纹不匹配、算法不支持、DNSSEC 缺失）及各顶级域差异。
运维落地的关键约束：
生产环境启用 SSHFP 需满足三个前提：权威 DNS 支持 SSHFP 记录类型、域名已签署 DNSSEC 且验证链完整、客户端配置 VerifyHostKeyDNS=yes 或 ask。若任一环节缺失，自动验证将回退至人工提示，失去安全增益。此外，密钥轮换时需同步更新 DNS 记录并等待 TTL 过期，否则会导致验证失败；原文未给出密钥轮换的最佳实践周期或自动化工具链建议。
对运维团队而言，SSHFP 能消除首次连接的人为风险，但极低的部署率揭示了 DNSSEC 普及与记录维护的现实阻力。建议在已启用 DNSSEC 的内网或受控环境先行试点，配合配置管理工具自动化密钥与记录同步，再评估向公网服务推广的成本收益。
原文: APNIC Blog（2022-12-02）｜编译自 APNIC Blog，事实以原文为准。
来源：APNIC Blog