4. 架构

4.1. 主机密钥

每个服务器主机都应当拥有主机密钥. 主机可以使用多种不同算法拥有多个主机密钥. 多个主机也可以共享同一个主机密钥. 如果主机拥有任何密钥, 则它必须至少拥有一个使用每种必需公钥算法的密钥, 即 DSS [FIPS-186-2].

服务器主机密钥在密钥交换期间用于验证客户端确实正在与正确服务器通信. 为实现这一点, 客户端必须预先知道服务器的公开主机密钥.

可以使用两种不同信任模型:

• 客户端有一个本地数据库, 将每个主机名 (按用户输入形式) 与对应公开主机密钥关联起来. 这种方法不需要集中管理的基础设施, 也不需要第三方协调. 缺点是名称到密钥关联数据库可能变得难以维护.

• 主机名到密钥的关联由受信 Certification Authority (CA, 认证机构) 认证. 客户端只知道 CA 根密钥, 并可以验证被接受 CA 所认证的所有主机密钥的有效性.

第二种替代方案缓解了维护问题, 因为理想情况下客户端只需要安全保存一个 CA 密钥. 另一方面, 每个主机密钥都必须先由中心机构适当认证, 才能进行授权. 此外, 这种方案把大量信任放在中心基础设施上.

协议提供一个选项, 允许首次连接主机时不检查服务器名与主机密钥之间的关联. 这允许在未预先传递主机密钥或证书的情况下通信. 连接仍能防止被动监听; 但会易受主动中间人攻击. 实现通常不应默认允许此类连接, 因为它们构成潜在安全问题. 然而, 在本文编写时 Internet 上还没有广泛部署的密钥基础设施, 因此该选项在这类基础设施出现前的过渡期内显著提升协议可用性, 同时仍提供比旧方案 (例如 telnet [RFC0854] 和 rlogin [RFC1282]) 高得多的安全级别.

实现应当尽最大努力检查主机密钥. 一种可能策略是只在首次连接某主机时不经检查接受其主机密钥, 将该密钥保存到本地数据库, 并在以后每次连接该主机时与保存的密钥比较.

实现可以提供额外方法验证主机密钥正确性, 例如从公钥的 SHA-1 哈希 [FIPS-180-2] 派生的十六进制指纹. 这类指纹可以通过电话或其他外部通信信道方便地验证.

所有实现都应当提供一个选项, 用于不接受无法验证的主机密钥.

本工作组成员认为, "易用性" 对终端用户接受安全方案至关重要; 如果新方案无人使用, 安全性就不会得到改善. 因此, 尽管允许不检查服务器主机密钥会降低相应配置下的协议安全性, 但提供该选项被认为会改善 Internet 的总体安全性.

4.2. 可扩展性

我们认为协议会随时间演进, 一些组织也会希望使用自己的加密、认证和/或密钥交换方法. 对所有扩展进行集中注册很繁琐, 对实验性或涉密功能尤其如此. 另一方面, 如果没有集中注册, 方法标识符会发生冲突, 从而使互操作变得困难.

我们选择用特定格式的文本名称来标识算法、方法、格式和扩展协议. DNS 名称用于创建本地命名空间, 让实验性或涉密扩展可以在其中定义, 而无需担心与其他实现冲突.

一个设计目标是尽可能保持基础协议简单, 并要求尽可能少的算法. 然而, 所有实现都必须支持最小算法集合以确保互操作性; 这并不意味着所有主机上的本地策略必然允许这些算法. 强制算法在相关协议文档中指定.

额外算法、方法、格式和扩展协议可以在单独文档中定义. 更多信息见第 6 节 Algorithm Naming.

4.3. 策略问题

协议允许完整协商加密、完整性、密钥交换、压缩以及公钥算法和格式. 加密、完整性、公钥和压缩算法可以在每个方向上不同.

每个实现的配置机制都应当处理以下策略问题:

• 分别为每个方向配置加密、完整性和压缩算法. 策略必须指定首选算法, 例如每个类别中列出的第一个算法.

• 用于主机认证的公钥算法和密钥交换方法. 不同公钥算法的受信主机密钥是否存在也会影响该选择.

• 服务器对每个用户要求的认证方法. 服务器策略可以要求部分或全部用户使用多重认证. 所需算法可以取决于用户尝试获取访问的位置.

• 允许用户通过连接协议执行的操作. 某些问题与安全相关; 例如, 策略不应允许服务器在客户端机器上启动会话或运行命令, 并且禁止允许连接到认证代理, 除非已请求转发此类连接. 其他问题, 例如哪些 TCP/IP 端口可由谁转发, 显然属于本地策略. 其中许多问题可能涉及穿越或绕过防火墙, 并与本地安全策略相互关联.

4.4. 安全属性

SSH 协议的主要目标是提高 Internet 上的安全性. 它试图以易于部署的方式实现这一目标, 即使这会以绝对安全性为代价.

• 所有使用的加密、完整性和公钥算法都是众所周知且成熟的算法.

• 所有算法都使用密码学上合理的密钥长度, 这些长度被认为可以在数十年内抵御最强密码分析攻击.

• 所有算法都经过协商; 如果某个算法被攻破, 无需修改基础协议即可轻松切换到其他算法.

为便于广泛快速部署, 协议作出了一些特定让步. 典型场景是验证服务器主机密钥确实属于期望主机; 协议允许省略该验证, 但不推荐这样做. 在广泛的 Internet 公钥基础设施出现之前, 这被认为能在短期内显著改善可用性.

4.5. 本地化和字符集支持

在大多数情况下, SSH 协议不会直接传递要显示给用户的文本. 不过, 某些位置可能会传递此类数据. 在适用时, 数据的字符集必须显式指定. 多数位置使用 ISO-10646 UTF-8 编码 [RFC3629]. 在适用时, 还会提供语言标签字段 [RFC3066].

一个重要问题是交互式会话的字符集. 这没有明确解决方案, 因为不同应用可能以不同格式显示数据. 客户端也可能采用不同类型的终端仿真, 实际使用的字符集由终端仿真决定. 因此, 协议没有提供直接指定终端会话数据字符集或编码的位置. 不过, 终端仿真类型 (例如 "vt100") 会传输到远端站点, 并隐式指定字符集和编码. 应用通常使用终端类型确定自身使用的字符集, 或通过某些外部方式确定字符集. 终端仿真也可以允许配置默认字符集. 无论如何, 终端会话的字符集主要被视为客户端本地问题.

用于识别算法或协议的内部名称通常绝不会显示给用户, 并且必须使用 US-ASCII.

客户端和服务器用户名本质上受服务器准备接受的内容约束. 不过, 它们有时可能显示在日志、报告等位置. 它们必须使用 ISO 10646 UTF-8 编码, 但某些情况下可能需要其他编码. 如何把用户名映射到被接受的用户名由服务器决定. 推荐使用直接的逐比特二进制比较.

出于本地化目的, 协议试图尽量减少传输的文本消息数量. 当这类消息存在时, 它们通常与错误、调试信息或某些外部配置数据有关. 对通常会显示的数据, 应当可以通过数值代码获取本地化消息, 而不是使用传输的消息. 其余消息应当可配置.