摘要

  • RFC 9644 统一了 SSH 算法能力与有序策略的 YANG 表达，但没有定义逐会话的协商结果记录。
  • 可辩护的结论必须从注册表与模型版本出发，经过实现能力、获批配置、双方 SSH_MSG_KEXINIT、双向选择、主机密钥验证、NEWKEYS、用户认证，最后抵达应用操作结果。
  • 本文提出的“会话回执”是运营控制设计，不是 RFC 的规范要求；缺少哪段观察，就必须缩小结论，而不是用推测补齐。

从一句话倒推证据

假设变更工单已经关闭。安全团队提供了算法白名单，设备确认配置成功，资产系统也显示新算法“受支持”。这时若直接宣布“生产 SSH 已采用新策略”，实际上跨越了三个未经证明的边界：对端当时提供了什么、双方最终选中了什么、选中后是否完成了身份和业务操作。

RFC 9644 定义 ietf-ssh-common、ietf-ssh-client 和 ietf-ssh-server 三类可复用 grouping，并提供从 IANA SSH 注册表生成四个算法枚举模块的机制。它解决的是共同语义和配置可移植性，不是会话取证。模型能让控制器和设备用同一名称表达意图，却不会自动产生一次连接的事实。

因此需要把四个看似相近的判断拆开：名称已注册、实现声称支持、策略允许并排序、会话实际选中。前三项分别属于公共词汇、产品能力和组织意图；第四项才是运行事件。即使第四项成立，也还没有证明服务器身份、客户端认证和应用结果。

注册权不等于批准权

RFC 9644 的生成机制让 YANG 枚举随 IANA 源注册表更新：新修订记录变化，未分配或保留值不会被当作可用枚举，状态信息得到投射。这能减少公共注册表和管理模型之间的漂移。

但“有登记”并不表示“适合本组织使用”。注册表保存不同年代、不同状态的标识符；RFC 9142 也说明 SSH 密钥交换方法的要求与建议等级会变化。组织必须保留两份独立决策：当时采用了哪一版注册表与生成模块；本地风险权威又允许、降级或禁止了哪些值。

模型修订或哈希不是形式附件。没有它，审计者只能看到一串今天仍可识别的名称，却无法确认变更当时控制器和设备共享的词汇版本。证据链第一段应包含注册快照、生成模块修订，以及影响可见结构的 feature 和 deviation。

支持清单只是可能性空间

在启用可选的 algorithm-discovery feature 时，supported-algorithms 以 config false 形式提供实现能力。这对迁移评估很有价值：它能指出设备声称具备哪些密钥交换、主机密钥、加密和 MAC 能力。

但能力不会自动获得许可，也不会自动转化为使用。某算法可能被编译进产品，却被组织政策禁止；可能被政策允许，却没有被对端提供；也可能双方都提供，但因排序而未被选中。能力观察还必须绑定软件版本、构建选项和时间，因为升级会改变可能性空间。

空列表尤其容易制造误判。RFC 9644 规定，当相应配置列表不存在或没有条目时，可接受集合由实现决定。这不是一个跨厂商通用的“安全默认值”。如果运营者无法取得实现的有效默认行为，就应把许可集合标为未知，而不是在界面上补出一个看似确定的答案。

策略顺序只有遇到对端才产生选择

transport-params-grouping 保存密钥交换、主机密钥、加密和 MAC 的有序列表，顺序代表偏好递减。回执必须保存原始顺序、配置修订、批准者和实际接受配置的设备；为了报表美观进行字母排序，会抹掉策略信息。

RFC 4253 把实际选择放在双方交换中。客户端和服务器分别发送 SSH_MSG_KEXINIT 名称列表。密钥交换和主机密钥按照客户端偏好，在服务器也支持并满足方法约束的候选中选择。加密与 MAC 则分别为客户端到服务器、服务器到客户端两个方向独立确定。

所以单一“cipher=approved”字段不足以描述会话。证据必须保留双方提供列表和两个方向的结果。如果没有可接受交集，连接会断开。设备接受配置只能证明意图已写入，不能证明对端能够完成协商。

算法名称、密钥与身份是三件事

协商出的主机密钥算法描述签名或验证程序，不等同于服务器实际提供的密钥，也不等同于客户端最终认可的身份。RFC 8332 提供了清楚例子：同一种 RSA 公钥格式可以用于 rsa-sha2-256 或 rsa-sha2-512。仅知道“存在 RSA 密钥”，无法还原使用了哪个算法。

RFC 9644 也把客户端身份与服务器认证参数分开，并可引用 keystore 与 truststore。这个分离要求运营记录依次回答：协商了什么程序、看见了哪把主机密钥、依照什么规则验证、客户端以何种身份认证、应用权限是否授予。

不同观察点拥有不同视野。网络侧传感器也许能捕获协商，却看不到客户端内部的信任决定；客户端日志也许记录信任结果，却没有保存对端完整 offer。正确做法是合并可关联的观察并明确空白，而不是把“看不见”改写为“已通过”。

NEWKEYS 之后仍有两道门

RFC 4253 中的 SSH_MSG_NEWKEYS 表示新计算的密钥与算法开始生效。双方 offer 存在交集，不代表一定抵达这条边界；抵达 NEWKEYS，也不代表 RFC 4252 所规定的用户认证成功，更不代表应用操作获准并完成。

因此，一份最小可用的运营回执可以连接以下字段：

  • IANA 注册快照与生成 YANG 模块修订或哈希；
  • 实现身份、feature、deviation 与软件版本；
  • 带时间戳的能力观察；
  • 获批的精确有序列表、配置修订与批准者；
  • 双方 KEXINIT 的受保护捕获或哈希；
  • 密钥交换、主机密钥、加密与 MAC 的实际选择，并保留方向；
  • 主机密钥指纹、验证依据、结果和不确定性；
  • 完成 NEWKEYS 的证据；
  • 不泄露凭据的客户端认证方法与结果；
  • 应用操作、验收条件和结果；
  • 缺失观察与有权批准最终表述的责任人。

这些 RFC 并没有规定一份统一回执。它是针对模型、协议和应用之间责任断点所设计的运营控制，必须如实标明自己的非规范性质。

最小结论如何经受证据缺口

Heng Lu 的“最小初始规范”要求先选定必须兑现的判断，再决定系统规模。在这里，“SSH 是安全的”既宽泛又不可验收。更合适的句子是：对于某项已标识的操作和时间窗口，组织能够把获批策略连接到会话观察、获验证对端和应用结果。

“运行代码优先”则规定了发生矛盾时的顺序。注册表和 YANG 模型形成符号层，真实交换限定事件层。如果二者不一致，对“发生了什么”的描述应服从运行观察；差异本身进入调查，而不是让配置意图覆盖事实。

这使不完整证据也能产生诚实结论。只有配置时，可以说“策略已被接受”；观察到 KEXINIT 与 NEWKEYS、但看不到信任决定时，可以说“这些算法已激活”，不能说“预期服务器已确认”；运输与身份都成立、但没有应用结果时，仍不能宣布服务交付完成。

来源

  1. 最小初始规范
  2. 现实层与符号权力
  3. 运行代码优先
  4. RFC 9644 Datatracker 页面
  5. RFC 9644 信息页
  6. RFC 9644 HTML
  7. RFC 9644 纯文本
  8. RFC 9644 XML
  9. RFC 9644 内联勘误
  10. IANA SSH 协议参数
  11. IANA YANG 参数
  12. RFC 4250：SSH 分配编号
  13. RFC 4252：SSH 认证协议
  14. RFC 4253：SSH 传输层协议
  15. RFC 6187：SSH 中的 X.509v3 证书
  16. RFC 8332：RSA 密钥与 SHA-2 签名
  17. RFC 9142：SSH 密钥交换方法更新
  18. RFC 7950：YANG 1.1
  19. RFC 8341：网络配置访问控制
  20. RFC 8342：网络管理数据存储架构