问SOCKS协议如何用于SSH动态端口转发？

EN

我想说，SSH客户端和服务器“让开”是描述动态端口转发的非常糟糕的方法，而且可能是由于几个作者重复编写得不好或过于简化的描述的结果。

正如其他人所描述的，SOCKS是一种标准化的方法，用于告诉任何兼容的TCP代理应该将代理连接转到何处。实质上，SOCKS协议就像使用一个旧的手动切换电话：“接线员，请给我接通X镇的电话号码Y！”这样做之后，操作员就不会(应该)监听连接，您可以使用任何您想要的语言与另一端的人交谈。

在SSH动态转发中，应用程序客户端打开到动态转发端口( SOCKS服务器端口)的TCP连接，发出标准SOCKS请求连接到特定的IP地址和端口，然后可以使用本机通过该TCP连接使用的任何协议恢复。它需要能够提出最初的SOCKS请求，但它不需要进一步了解任何信息。(连接结束时可能有一些特定于袜子的小东西，但否则，就端点而言，转发的连接将是完全透明和协议中立的。)

另一端的应用服务器只看到来自SSH服务器的一个简单的旧TCP连接:它不需要知道连接正在被转发，也不需要知道客户端涉及SOCKS协议。

(当你的电话响了，你接了电话，你就不需要做什么特别的事情了，即使你的电话恰好来自技术博物馆，它有一个功能强大的手动电话交换机，与固定电话网相连。)

因此，严格地说，当动态转发功能被激活时，SSH客户端还将充当一个SOCKS服务器，具有特定的附加属性，即使用SOCKS服务器的所有连接都将在加密的SSH隧道内传递到远程SSH服务器，并从那里恢复为常规TCP连接。

或者，换句话说，SSH客户端与动态转发启用的+ SSH连接+ SSH服务器的组合将充当一个SOCKS代理，该代理已被扩展到SSH连接所覆盖的距离，因此SOCKS代理的入站侧与SSH客户端位于同一位置，出站端位于SSH服务器上，在这两者之间发生的事情看起来像是外部观察者未描述的加密SSH通信。

注意，只有SSH客户端和SSH服务器之间的跳转才会受到SSH的保护。但是，应用程序客户端和SSH客户机/SOCKS服务器之间的跳转通常在单个主机中。唯一可能未加密的部分(除非应用程序协议包括自己的加密)是SSH服务器和应用服务器之间的跳转。

SSH协议允许通过一个TCP连接复用多个独立的数据流。每个数据流被称为一个通道。通过TCP连接发送的所有数据都是加密的。发送方将将来自不同通道的数据聚合到一个数据流中，然后对数据流进行加密。接收方将解密数据并将聚集的数据流分离回各自的信道中。

在端口转发的情况下，SSH客户端通过使用SSH协议的TCP连接连接到远程SSH服务器。在客户机->服务器转发的通常情况下，SSH客户端也在侦听某些端口上的TCP连接。到此端口的连接将通过服务器转发到某个目标。

当“发起者”(也称“应用程序客户端”)连接到SSH客户端的侦听端口时，SSH客户端将向服务器请求一个“直接tcpip”频道发送通道开放请求。此请求的参数包括主机名/IP地址和通道应该连接的端口。SSH服务器将与指定的主机和端口建立另一个TCP连接，我将称之为“目标”。现在有三个TCP连接：

1. 在发起人和SSH客户端之间
2. 在SSH客户端和SSH服务器之间
3. 在SSH服务器和转发目标之间

SSH客户端和服务器通过SSH连接在发起者和目标之间双向中继数据。

因此，在转发来自发端者的连接时，SSH客户端必须告诉SSH服务器应该将连接转发到哪里。如果您使用命令行选项运行ssh来转发端口，例如：

ssh -L 1234:example.com:2345 ...

然后，关于在哪里转发连接的信息来自命令行参数；ssh记住，到端口1234的连接被转发到example.com端口2345。

如果使用运行SOCKS服务器的选项调用ssh，例如：

ssh -D 1234

然后，连接到SOCKS端口的每个发起者应该首先发送一个SOCKS协议消息，指定要连接到的主机和端口。ssh将使用SOCKS消息中的信息来构造直接的tcpip通道开放请求。

使用SOCKS协议？

客户端(web浏览器)与ssh服务器(通过ssh客户端)通信。

应用程序客户端和应用服务器之间的通信是否仍然封装在SSH协议中(如此安全)？

是。

参照系