SSH2项目中客户端主机验证与密钥重协商问题分析

问题背景

在使用Node.js的ssh2库时，当客户端配置了hostHash和hostVerifier选项，并且服务器端尝试进行密钥重协商(rekey)时，会出现"Digest already called"的错误。这个问题涉及到SSH协议的安全验证机制和密钥交换过程。

技术原理

SSH协议中的主机验证

SSH协议在建立连接时需要进行主机验证，确保客户端连接的是预期的服务器。ssh2库提供了两种验证方式：

1. 固定主机密钥验证：通过预存的服务器公钥进行验证
2. 哈希验证：使用hostHash选项生成服务器密钥的哈希值进行验证

当使用hostHash选项时，客户端会计算服务器密钥的哈希值，并通过hostVerifier回调函数让开发者决定是否接受该哈希值。

密钥重协商机制

SSH协议允许在连接过程中进行密钥重协商(rekey)，这是为了增强安全性，特别是在长时间保持的连接中。重协商过程会：

1. 重新生成会话密钥
2. 重新协商加密算法
3. 可能更换主机密钥

问题根源

当同时满足以下条件时会出现问题：

1. 客户端配置了hostHash选项
2. 服务器发起密钥重协商请求
3. 重协商过程中需要重新验证主机密钥

错误发生在重协商阶段，当尝试再次计算主机密钥哈希值时，发现哈希对象已经被使用过，导致"Digest already called"错误。

解决方案

ssh2库的维护者通过以下方式修复了这个问题：

1. 在每次主机验证时创建新的哈希对象，而不是复用之前的
2. 确保哈希计算过程是独立的，不会相互干扰
3. 正确处理密钥重协商过程中的主机验证流程

最佳实践

开发者在使用ssh2库时应注意：

1. 主机验证选择：根据安全需求选择合适的主机验证方式
2. 密钥重协商：了解服务器是否会主动发起重协商
3. 错误处理：妥善处理连接过程中的错误，特别是验证相关的错误

总结

这个问题展示了SSH协议实现中主机验证与密钥管理机制的复杂性。ssh2库通过修复哈希对象的生命周期管理，确保了在密钥重协商场景下主机验证流程的正确性。对于开发者而言，理解SSH协议的各种安全机制和状态转换过程，有助于更好地使用相关库和排查连接问题。