SSH 流量看起来与 HTTP 和 HTTPS 不同。ssh -p80...通过查看已经包含 SSH 版本而不是 HTTP 版本或 TLS ServerHello 的第一个响应数据包，可以检测通过端口 80 或 443（即）简单地通过隧道传输的 SSH 流量。但是您也可以简单地在网络内强制使用 HTTP 代理，这使得使用普通 SSH 成为不可能。

这使得在其他协议中建立 SSH 隧道成为可能，例如使用 CONNECT 请求简单地通过代理创建隧道，甚至使用纯 HTTP、使用 WebSockets、使用 DNS 或类似方法将 SSH 连接隐藏在完整的 TLS 连接中。这很难检测到，尽管一些统计分析可能会有所帮助，因为 SSH 显示出与正常 HTTP 流量不同的行为。但是这样的分析可能很容易与当今常见的 WebSockets 流量混淆。

最后，这是一场竞赛，你应该问问自己，为什么你仍然专注于 SSH 隧道。这些隧道只不过是在内部和外部之间传输数据的工具。这样的数据传输也可以使用普通的 HTTP/HTTPS 完成，可以使用 USB 记忆棒等完成。因此，专注于单个向量确实可以防止数据泄漏或防止攻击者进入网络，恕我直言，这是错误的方式。并且对于制定政策：在允许的情况下拥有白名单比在不允许的情况下拥有黑名单更安全。

一种让它变得更难的方法可能是安装一个 HTTP 代理，这样就不能再直接通过 80/443 建立连接，除非它是一个有效的 HTTP 连接，但即使使用Proxytunnel 之类的东西也可以绕过它。绕过这个的另一种方法是运行一个 Web 控制台并通过 80/443 正常访问它。

让他们更难可能不会阻止他们，但最终，如果您在政策中规定不允许这样做并且您监控网络，那么可以向违反此规则的人发出警告。

在这里，他们通过阻止 HTTP 代理的 CONNECT 方法阻止了 SSH 通过 443 端口。

第二种解决方案是使用虚假的“登录”页面。使用代理可以要求输入密码，这通常由浏览器询问，或者在可以使用代理的应用程序中输入身份验证字段。但是您可以通过使用要求登录/密码的虚假登录页面绕过代理服务器。

这种方法很糟糕，因为只有显示此页面的应用程序才能通过代理。例如，Putty 无法显示此页面，因此无法向代理验证自身。

第一个问题应该是为什么用户/管理员使用反向 ssh 隧道。我在一家公司工作，该公司的远程管理 VPN 实施得很差，只允许连接到带有不良工具的 citrix 服务器，因此我们使用 SSH 远程隧道来充分远程管理我们的服务器。只允许从堡垒主机出来的隧道。主机设置为禁用密码身份验证、禁用 root 登录和启用基于密钥的身份验证。反向隧道允许 ssh 连接回传到 DMZ，然后从堡垒主机用户只能访问少数其他堡垒主机。而不是通过 MITM 拦截代理、IDS、阻止对管理员家庭 IP 和 DPI 防火墙的访问来阻止 ssh 隧道。为用户/管理员提供更好的解决方案，