在 AWS 中，我们的用户（系统管理员）可以使用 SSH 隧道访问内部区域数据库服务器，而不受任何本地防火墙的限制。 如您所知，要访问内部节点，用户必须首先通过公共区域网关服务器。 因为网关实际上是一个通道，所以我希望在网关服务器上控制来自隧道用户的流量。 例如，获取所有客户端当前连接的ip地址，识别用户访问的内部路径（例如DB服务器ip），以及控制未授权用户的连接。
为了我的梦想成真，我认为下面的想法真的很理想。 1) 将 sshd 端口更改为 22 以外的端口。重新启动 sshd 守护进程。 2）在 sshd 之前找到 ssh 代理（nginx、haproxy 或其他），让代理从客户端获取所有 ssh 流量。 3) ssh 代理将流量路由到 sshd 4）然后我可以通过分析 ssh 代理日志来查看所有用户的活动。就是这样。
这可能是梦想吗？
【问题讨论】：
标签： amazon-web-services ssh proxy tunnel sshd
聪明，但有一个严重缺陷：你不会获得任何新信息。
为什么？ SSH 中的第一个 S：“安全”。
您设想的“ssh 代理”将无法告诉您有关 SSH 连接内部发生的任何事情，这是协商隧道的地方。当然，连接是加密的，SSH 的一个重要点是它不能被嗅探。 ssh 代理在同一台机器上这一事实没有任何区别。如果它可以被嗅探，它就不安全了。
您的 SSH 代理可以告诉您的只是入站连接是从客户端计算机建立的，而 syslog 已经告诉您了。
在真正意义上，它根本不是“ssh 代理”——它只是入站连接上的一个简单的 TCP 连接代理。
因此，您将无法通过这种方法学习任何新信息。
听起来您需要 ssh 守护程序（可能是 openssh）来记录连接用户建立的隧道连接。
This blog post（具有讽刺意味的是，您需要绕过无效的 SSL 证书才能查看）提到了at Server Fault，并显示了对 openssh 源代码的简单修改以记录您想要的信息: 谁设置了隧道，到哪里。
或者，enable some debug-level logging on sshd。
所以，对我来说，额外的 TCP 代理似乎是多余的——您只需要执行实际隧道 (sshd) 的进程来记录它正在做什么或被要求做什么。
【讨论】：