我们在通过远程端口转发进行 SSH 连接时遇到问题。
该场景是企业网络，内部网络上的服务器（我们称之为“源”）必须通过 SSH 登录到 DMZ（“目标”）中的服务器。由于 DMZ 中的目标服务器被内部网络的连接锁定（甚至无法从内部网络看到），因此我们在 DMZ 中有一个跳转主机（“jumphost”）。我们通过在 jumphost 上设置远程端口转发来做到这一点。
我们从内部网络上的源服务器运行这个命令，到 jumphost：
origin> ssh -R *:1234:target:22 myusername@jumphost
这是为了在 jumphost 上建立一个 SSH 会话，使其开始侦听端口 1234（只是一个示例任意端口号），并将该端口上的连接转发到目标服务器端口 22 (SSH)。
然后我们在端口 1234 上建立第二个 SSH 会话，仍然是从源服务器到 jumphost，然后实际上连接到端口 22 上的目标服务器 - 这是我们的“真正的”SSH 会话，我们可以在其中完成我们的工作目标服务器：
origin> ssh jumphost -P 1234
配置
跳转主机已配置为允许远程端口转发，在 sshd_config 中有以下设置：
AllowTcpForwarding yes
GatewayPorts yes
此外，在源服务器和跳转主机之间有防火墙开口，用于端口 22（用于设置远程端口转发的初始 SSH 连接）和端口 1234（用于转发端口上的后续 SSH 连接）。jumphost和target之间也有防火墙，已经在22端口开放。
结果
当我们建立第二个连接（通过转发端口的连接）时，该连接立即关闭（“连接被远程主机关闭”）。
在目标服务器上运行 tcpdump 没有显示任何活动，即似乎连接被阻塞。
但是，我们能够成功地建立从跳转主机到目标的常规 SSH 会话。只有通过转发端口进入时，连接才会关闭，尽管两者都连接到端口 22 上的目标。
更重要的是，如果我们将端口转发点指向内部网络上的服务器（即从内部网络上的源连接到 DMZ 中的跳转主机，然后返回到内部网络上的第三台服务器），那么 SSH会话建立成功。
猜测和问题
所有这一切让我相信某些网络安全设置正在发挥作用，它阻止通过跳转服务器上的转发端口连接到 DMZ 内的目标服务器。不幸的是，我没有足够的知识知道：
(1) 来自源服务器的 SSH 连接是否通过跳转服务器上的转发端口“不同”，从网络安全策略的角度来看，它可以在技术上被阻止，如果是，如何？需要做些什么来解除这种限制？
(2) 不允许通过此连接的任何其他原因 - 防火墙配置、路由器配置、源站或 jumphost 上的 SSH 设置，还有其他什么？
(3) 它会不会因为源服务器不知道目标服务器而失败，因此第一个 ssh 命令不能按预期工作？换句话说，第一个 ssh 命令（“target”）中指定的主机名是在客户端（源）还是在我们连接到的服务器（jumphost）上解释的？
最让我难过的是可以从跳转主机到目标建立常规的 SSH 会话，我认为通过转发端口进入的 SSH 连接是相同的，但不知何故不是。
非常感谢任何输入。
看起来您应该使用本地端口转发而不是远程端口转发。您可能需要参考 Dirk Loss 的以下有用博客文章：
它包括以下说明图：
为了阅读该图，您需要知道它描述了创建和使用 SSH 隧道所涉及的 4 个不同角色之间的关系：
sshOpenSSH 命令行客户端）；sshd用于维护隧道另一端的ssh 服务器（即OpenSSH 服务器守护进程）；了解两种不同类型的转发对应于两种不同的用例也很重要：
本地转发：应用程序客户端通过 ssh 客户端连接的位置
远程转发：应用程序客户端通过 ssh 服务器连接
之所以称为远程转发，是因为转发是在远程（在 ssh 服务器）而不是在本地（在 ssh 客户端）执行的。我还发现“远程转发 = 反向转发”是一个有用的助记词。
如您所见，为了通过代理服务器上的服务器启动从主机
ssh客户端到第三台主机的连接，您必须使用本地端口转发。远程端口转发适用于您希望隧道的入口点位于运行服务器的主机而不是运行客户端的主机的情况。originsshdjumphosttargetsshdssh在手册页中，本地端口转发语法如下所示：
这可以更直观地写成如下：
或者，使用您的命名约定：
如果我们修改您的命令以使用本地端口转发，那么我们最终会得到以下结果：