4. Architecture (架构)

4.1 Host Keys (主机密钥)

每个服务器主机应该具有一个主机密钥 (host key).主机可以使用多个不同的算法拥有多个主机密钥.多个主机可以共享相同的主机密钥.如果主机拥有密钥, 则它必须至少拥有一个使用每个必需的公钥算法的密钥 (DSS [FIPS-186-2]).

服务器主机密钥在密钥交换期间用于验证客户端确实在与正确的服务器通信.为了使这成为可能, 客户端必须预先知道服务器的公共主机密钥 (public host key).

可以使用两种不同的信任模型 (trust models):

客户端拥有一个本地数据库, 该数据库将每个主机名 (由用户键入) 与相应的公共主机密钥关联.此方法不需要集中管理的基础设施, 也不需要第三方协调.缺点是名称到密钥关联的数据库可能变得难以维护.
主机名到密钥关联由受信任的证书颁发机构 (certification authority, CA) 认证.客户端只知道 CA 根密钥, 并且可以验证由接受的 CA 认证的所有主机密钥的有效性.

第二种替代方案缓解了维护问题, 因为理想情况下, 只需要在客户端上安全地存储一个 CA 密钥.另一方面, 每个主机密钥必须在授权之前由中央机构适当地认证.此外, 对中央基础设施寄予了大量信任.

该协议提供了在首次连接到主机时不检查服务器名称-主机密钥关联的选项.这允许在没有预先通信主机密钥或认证的情况下进行通信.连接仍然提供针对被动监听 (passive listening) 的保护; 但是, 它变得容易受到主动中间人攻击 (man-in-the-middle attacks).实现不应该通常默认允许此类连接, 因为它们构成潜在的安全问题.但是, 由于在撰写本文时互联网上没有广泛部署的密钥基础设施可用, 此选项使该协议在过渡时期更加可用, 直到出现这样的基础设施为止, 同时仍然提供比旧解决方案 (例如, telnet [RFC0854] 和 rlogin [RFC1282]) 提供的安全级别高得多的安全性.

实现应该尽最大努力检查主机密钥.一个可能策略的示例是仅在第一次连接主机时接受主机密钥而不进行检查, 将密钥保存在本地数据库中, 并在该主机的所有将来连接上与该密钥进行比较.

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

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

本工作组的成员认为, "易用性" 对于终端用户接受安全解决方案至关重要, 如果不使用新解决方案, 则安全性不会得到改善.因此, 提供不检查服务器主机密钥的选项被认为可以改善互联网的整体安全性, 即使它在允许的配置中降低了协议的安全性.

4.2 Extensibility (可扩展性)

我们相信协议将随着时间的推移而发展, 一些组织将希望使用他们自己的加密,认证和/或密钥交换方法.所有扩展的集中注册是繁琐的, 特别是对于实验性或机密特性.另一方面, 没有集中注册会导致方法标识符冲突, 使互操作性变得困难.

我们选择使用特定格式的文本名称来标识算法,方法,格式和扩展协议.DNS 名称用于创建本地命名空间 (local namespaces), 其中可以定义实验性或机密扩展, 而不必担心与其他实现发生冲突.

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

可以在单独的文档中定义其他算法,方法,格式和扩展协议.有关更多信息, 请参见第 6 节算法命名.

4.3 Policy Issues (策略问题)

该协议允许完全协商加密,完整性,密钥交换,压缩以及公钥算法和格式.加密,完整性,公钥和压缩算法对于每个方向可以不同.

以下策略问题应该在每个实现的配置机制中解决:

每个方向单独的加密,完整性和压缩算法.策略必须指定哪个是首选算法 (例如, 每个类别中列出的第一个算法).
用于主机认证的公钥算法和密钥交换方法.不同公钥算法的受信任主机密钥的存在也会影响此选择.
服务器对每个用户要求的认证方法.服务器的策略可以要求某些或所有用户进行多重认证 (multiple authentication).所需的算法可以取决于用户试图从中获得访问的位置.
允许用户使用连接协议执行的操作.一些问题与安全性相关; 例如, 策略不应该允许服务器在客户端机器上启动会话或运行命令, 并且除非已请求转发此类连接, 否则不得允许连接到认证代理.其他问题, 例如哪些 TCP/IP 端口可以转发以及由谁转发, 显然是本地策略的问题.许多这些问题可能涉及穿越或绕过防火墙, 并且与本地安全策略相互关联.

4.4 Security Properties (安全属性)

SSH 协议的主要目标是提高互联网上的安全性.它试图以易于部署的方式做到这一点, 即使以绝对安全为代价.

使用的所有加密,完整性和公钥算法都是众所周知,完善的算法.
所有算法都使用被认为可以提供针对数十年来最强大的密码分析攻击的保护的密码学上合理的密钥大小.
所有算法都是协商的, 并且如果某个算法被破解, 很容易切换到其他算法而无需修改基础协议.

为了使广泛,快速的部署更容易, 做出了具体让步.出现这种情况的特殊案例是验证服务器主机密钥确实属于所需主机; 协议允许省略验证, 但不推荐这样做.这被认为可以在短期内显著提高可用性, 直到广泛的互联网公钥基础设施出现.

4.5 Localization and Character Set Support (本地化和字符集支持)

在大多数情况下, SSH 协议不直接传递会显示给用户的文本.但是, 在某些地方可能会传递此类数据.在适用的情况下, 必须明确指定数据的字符集.在大多数地方, 使用 ISO-10646 UTF-8 编码 [RFC3629].在适用的情况下, 还为语言标签 (language tag) [RFC3066] 提供了一个字段.

一个大问题是交互式会话的字符集.没有明确的解决方案, 因为不同的应用程序可能以不同的格式显示数据.客户端中也可能采用不同类型的终端仿真 (terminal emulation), 并且要使用的字符集实际上由终端仿真确定.因此, 没有提供直接指定终端会话数据的字符集或编码的地方.但是, 终端仿真类型 (例如, "vt100") 会传输到远程站点, 并且它隐式指定字符集和编码.应用程序通常使用终端类型来确定它们使用的字符集, 或者使用某些外部方式确定字符集.终端仿真还可能允许配置默认字符集.在任何情况下, 终端会话的字符集主要被视为客户端本地问题.

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

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

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