引言：大学三年级这年，终于是有一节课的演讲作业头一次引起我真正想要认真研究和学习的欲望。UCI 2023 Fall CompSci 132 的网络协议演讲作业允许我们选择 OSI 2-7 层中的任何一个协议进行研究，完成后我认为将这份原创的演讲以抄本和幻灯图片的方式在网站上保留下来是很有意义的。正文抄本将会包括英文原稿和中文翻译。

您好，各位。今天，我很高兴为您带来一个题目，名为“SSH的实现及其与类似协议的关系”。在今天的讨论中，我们将深入探讨各种协议，如SSH、Telnet、FTP、SFTP、HTTP和SSL。我的目标是阐明它们之间的差异以及它们被应用的具体场景。如果这些术语对您来说听起来不熟悉或令人困惑，我希望我提供的见解将对您有很大的帮助。

首先，我想从讨论为什么我选择 SSH 作为这个项目的标题开始。我第一次接触 SSH 是通过我的 ICS33 和 ICS46 教授，他们要求我们使用 UCI Openlab 作为我们课程作业的编译环境。经过几个学期的使用，我对 SSH 的好奇心极大地增长了。然而，SSH 的用途远不止帮助学生完成作业。它是一个强大的远程服务器管理、加密文件传输、用户认证和端口转发工具，被企业和个人广泛使用。根据相关统计数据，由于 SSH 的诸多优势，它在远程操作协议市场上占据了重要份额。早在 2000 年，SSH 用户的数量已经达到了两百万。现在，在 2023 年，这个数字已经增长到几乎无法计数的地步。许多IT部门的员工，尤其是运营部门的员工，可能在他们的日常工作中频繁使用 SSH。

让我们从介绍一些关于这个协议的基本信息开始。SSH 最初是为 类 Unix 系统 开发的，它的主要目的是远程登录和命令执行。随着时间的推移，使用这个协议的应用程序增多，使其与几乎所有系统兼容。SSH 于 1995 年开发，它默认在 端口 22 上运行。它被设计为替代极不安全的 Telnet。SSH 的加密登录和双向数据加密使远程连接非常安全。即使有人在中间截获数据，没有密钥他们也无法阅读。由于登录过程，包括密码，都是加密的，黑客再也不能通过流量分析来尝试盗取远程服务器密码，因此显著增强了服务器在暴露于公共互联网时的安全性。

Telnet 一直与 SSH 相比较，主要是因为它的安全级别较低。尽管 SSH 由于其加密过程更复杂且稍慢，但大多数个人和企业用户已经转向使用 SSH。Telnet 于 1969 年开发，那时的计算机网络要简单得多，用户也少得多。因此，Telnet 选择了在网络上使用明文传输，包括用户名和密码。尽管 Telnet 的安全扩展有所发展，但统计数据显示，大多数安装的 Telnet 系统并没有这样做。这意味着真实数据包可以在两个主机之间的任何点被截获，如路由器、交换机和网关。然而，到了 20 世纪 90 年代末，随着网络安全重要性的日益被广泛认识，SSH 应运而生。

Telnet 的传输过程非常直接。作为基于 TCP/IP 协议 的应用程序，客户端通过与服务器建立握手来启动流程，以确认连接。一旦收到肯定的连接确认，客户端就开始以明文形式传输用户名和密码信息。为了适应不同操作系统中的各种快捷键和基本操作，Telnet 在连接建立后的任何传输发生之前，将客户端的动作转换为 NVT（网络虚拟终端）数据包，包括用户名和密码。这些未加密的数据包一旦被服务器接收并确认，便被转换为正确的命令格式进行执行。这些命令的结果随后被封装回 NVT，并发送给客户端，完成一个命令周期。当客户端希望断开连接时，它会向服务器发送相应的命令，从而结束传输过程。

相比之下，SSH 比 Telnet 复杂得多。然而，由于 SSH 也是基于 TCP/IP 协议建立连接的，因此传输的第一步始终是握手和建立连接。由于幻灯片尺寸限制，TCP 握手过程被简化为仅两个箭头，尽管实际过程更为详细。在握手之后，传输前的过程真正反映了 SSH 在安全性方面的进步。第二步涉及版本协商。目前，主流的SSH 有两个版本：SSH 2.0，代表第二代，以及 SSH 1.X，代表第二代之前的所有版本。两代之间的主要区别是增加了几个扩展协议，包括稍后在本演示中提到的端口转发和隧道技术。SSH 2.0 还引入了新的加密和解密算法，增强了 SSH 的整体设计结构，并重新设计了认证系统。回到我们的主题，在双方同意版本之后，第三步是算法协商。客户端和服务器彼此发送他们支持的算法，并就一个共同的算法过程达成一致，主要是为了接下来的密钥交换和加密传输做准备。第四步涉及交换密钥，以解密随后将要传输的数据。直到这第四阶段结束，所有数据仍以明文形式传输，因为此时还不需要加密，因为密钥交换通过数学原理巧妙地避免了明文的需要。具体来说，客户端和服务器都生成自己的公钥和私钥。客户端的公钥是使用服务器提供的素数和公钥生成的，而服务器的密钥是随机的。此后，双方都可以使用数学运算在本地获得只有他们知道的密钥。随后的传输过程与 Telnet 非常相似。在第五步中，客户端可以选择加密用户名和密码进行身份验证，或使用服务器记录的私钥。一旦身份验证通过，就开始数据传输。值得注意的是，从第五步开始，客户端和服务器之间的所有通信都是加密的，没有密钥几乎无法解密。

SSH 的强大安全性导致了许多附加功能的发展，如 SSH 转发。SSH 转发解决了 OSI 模型第七层其他协议的安全问题。如幻灯片中所示，考虑一个使用 端口 888 进行通信的应用程序，但该应用程序或协议本身没有加密或解密数据的能力。SSH 转发可以有效地减轻这种风险，确保即使来自这类应用程序的数据也通过加密的 SSH 通道安全传输。

在这个具体示例中，转发服务使 SSH 能够监控本地主机 端口 888 上的所有数据。一旦需要发送数据包，它就被打包并以 SSH 格式加密，然后路由到预定的目标服务器。当加密的数据包到达目的地并被解密后，服务器端的 SSH 读取它并将数据包转发到相应的本地端口，在这个例子中是 端口 888。在完成这一系列步骤后，不会有明文通过公共互联网传输，从而增强了互联网传输的整体安全性。

由于其强大的转发能力，SSH 作为 OSI 应用层 的协议，也可以解决 OSI 模型的前三层和物理层相关的问题。例如，在幻灯片中，白色线条代表客户端之间的物理连接。您可以看到，虽然 主机A 和 主机B 没有直接连接，但它们都与 主机C 连接。SSH隧道可以促进 主机A 到 主机B 的数据传输，有效解决缺乏直接连接的问题。这样就绕过了需要额外物理基础设施如路由器、电缆和交换机的需求。

要更好地理解 SSH 隧道，将 主机C 想象为一种路由器是有帮助的。在 主机C 是可信的场景中，来自 主机A 的数据通过 主机C 传输到 主机B。在演示图中，主机A 只与 主机C 开启一个 SSH 通道，并表明其意图将数据转发给 主机B。在传输过程中，主机A 的SSH客户端将其本地 端口688 的数据映射到本地 端口22。这些数据现在被 SSH 加密，发送给 主机C。主机C 在验证后，重复这一过程，并将完整的数据包（包括目的端口信息）发送给 主机B。主机B 接收到数据后，解密数据，然后将其转发到相应的本地端口，这种情况下是 端口2333。

然而，如果在测试转发规则之后确定它们工作正常，并且 主机C 被认为是可信的，那么 主机A 和 主机B 实际上可以忽略 主机C，因为它不会改变数据。在图表中，代表数据流的箭头可能实际上并不存在，但数据仍然得到传输，这类似于在两个位置之间挖掘隧道。这种比喻就是为什么它被称为 SSH隧道。对于用户和高层应用来说，即使在这种情况下也可以忽略 端口22，因为一切看起来就像数据是直接从 主机A 的端口688传输到 主机B 的 端口2333。

接下来，我将解释 SSH 与 FTP 以及 SFTP 之间的关系。FTP 代表文件传输协议，通常使用 端口20 和 端口21。与 SSH 一样，FTP 位于 OSI模型 的第七层，即应用层，也是基于 TCP/IP 的。FTP 的主要功能是在计算机和服务器之间传输文件。用户可以选择使用 SSL 加密传输内容，或选择匿名传输。然而，SFTP 虽然看起来像是在 SSH 上实现的 FTP，但实际上运作方式完全不同。在 FTP 协议中，客户端可以选择两种模式之一：PORT 或 PASV。在 PORT 模式下，客户端向服务器提供一个开放的动态端口，然后服务器向该端口发送文件传输请求。在 PASV 模式下，是服务器开放一个动态端口，客户端发送传输请求。虽然这种设计灵活，但在复杂的网络环境中可能导致问题。例如，如图所示，如果左侧的客户端本地网络有端口控制或防火墙，即使客户端开放了一个动态端口，防火墙可能也不会与之同步，导致外部服务器发送的传输请求被拒绝。PASV 模式不适合一些大规模服务或需要许多客户端同时在线的服务。因此，SFTP 成为这些问题的关键解决方案。

SFTP，作为 SSH 2.0 的一个重要扩展，显著地偏离了大部分 FTP 的传输逻辑。例如，它不是使用 SSL 来加密数据和安全认证信息，而是依赖于一个经过认证且有效的 SSH 连接。这意味着 SFTP 协议本身不提供身份验证；相反，它依赖于底层的 SSH 来提供这项功能。因此，在 SSH 默认禁止匿名传输的情况下，SFTP 也不支持匿名传输。由于加密通过 SSH 处理，所有数据都通过 端口22 进出。这消除了客户端和服务器需要开放随机动态端口的需求。这也意味着，如果一个 SSH 通道成功建立，理论上 SFTP 请求不可能被本地网络内的防火墙阻挡。SFTP 的传输逻辑包括将文件分割成数据包并添加头部，以帮助客户端重新组装它们。这些数据包的加密传输过程本质上与 SSH 中使用的过程相同。

为了更生动地理解 SSH，我认为最直接的方法是将其与 HTTP/HTTPS 进行比较。如表格的最后两行所示，Telnet 与 SSH 之间的区别类似于 HTTP 与 HTTPS 之间的区别。除了 HTTP/3 外，这四种协议都是基于 TCP/IP 的。Telnet 和 HTTP 在数据安全性方面存在不足，而 SSH 和 HTTPS 与前者相比有些许慢。本质上，从 Telnet 过渡到 SSH 类似于从 HTTP 过渡到 HTTPS。尽管 HTTPS 和 SSH 的加密方法略有不同，但过去 20 年已经证明了这两种协议的成功。^{1 2 3 4 5 6 7 8}