5. Compatibility With Old SSH Versions (与旧版 SSH 的兼容性)

如前所述, 本协议规定的 protoversion 为 "2.0". 更早版本的协议未正式成文, 但众所周知其使用 "1.x" 形式的 protoversion (例如 "1.5" 或 "1.3"). 撰写本文时, 许多 SSH 实现已使用协议版本 2.0, 但仍有设备使用先前版本. 在过渡期内, 需要能够以兼容已安装的使用旧协议版本的 SSH 客户端与服务器的方式工作. 本节信息仅与支持 SSH 1.x 兼容性的实现相关. 对 1.x 协议唯一已知的说明仅见于随源码分发的 README 文件 [ssh-1.2.30].

5.1. Old Client, New Server (旧客户端, 新服务器)

服务器实现可以支持可配置的兼容性标志, 以启用与旧版本的兼容. 当该标志开启时, 服务器应该将其 protoversion 标识为 "1.99". 使用协议 2.0 的客户端必须能够将其识别为与 "2.0" 等同. 在此模式下, 服务器不应该在标识字符串之后发送回车符 (ASCII 13).

在兼容模式下, 服务器在发送其标识字符串之后, 在收到客户端标识字符串之前, 不应该再发送任何数据. 服务器随后可判断客户端是否使用旧协议, 并在需要时回退到旧协议. 在兼容模式下, 服务器不得在标识字符串之前发送附加数据.

当不需要与旧客户端兼容时, 服务器可以在标识字符串之后立即发送其初始密钥交换数据.

5.2. New Client, Old Server (新客户端, 旧服务器)

由于新客户端可以在发送其标识字符串之后立即发送附加数据 (在收到服务器标识字符串之前), 当客户端发现服务器为旧实现时, 旧协议数据可能已损坏. 发生此情况时, 客户端应该关闭与服务器的连接, 并使用旧协议重新连接.

5.3. Packet Size and Overhead (分组大小与开销)

一些读者会担心新首部, 填充以及报文认证码 (MAC) 导致的分组增大. 最小分组大小约为 28 字节 (取决于协商算法). 对大分组而言增幅可忽略, 但对单字节分组 (类 telnet 会话) 则非常显著. 然而, 若干因素使这在几乎所有情况下都不成问题:

TCP/IP 首部最小为 32 字节. 因而实际增幅大约是从 33 字节到 51 字节.
以太网分组数据字段最小为 46 字节 [RFC0894]. 因而增幅不超过 5 字节. 若计入以太网首部, 增幅小于 10%.
互联网中类 telnet 数据的总体占比可忽略, 即便分组变大亦然.

分组大小增幅唯一可能产生显著影响的场景是 PPP [RFC1661] 上的慢速调制解调器线路 (PPP 会压缩 TCP/IP 首部, 从而凸显分组增幅). 然而, 使用现代调制解调器时, 传输所需时间约为 2 毫秒, 远快于人工输入.

还存在与最大分组大小相关的问题. 为尽量减少屏幕刷新延迟, 交互式会话不希望分组过大. 最大分组大小对每个信道单独协商.