在AWS中，我們的用戶（系統管理員）可以使用SSH隧道訪問內部區域數據庫服務器，而不受任何本地限制。 如您所知，要訪問內部節點，用戶必須先通過公共區域網關服務器。 因爲網關實際上是一個通道，所以我希望控制來自網關服務器上隧道用戶的流量。 例如，要獲取所有客戶端的當前連接的IP地址，要標識內部路徑（例如DB服務器IP），用戶訪問的用戶還要控制未授權用戶的連接。在AWS中，通過ssh代理+ sshd訪問控制
爲了我的夢想成真，我覺得下面的想法真的很理想。 1）將sshd端口更改爲22以外的其他端口。重新啓動sshd守護進程。 2）在sshd之前找到ssh代理（nginx，haproxy或其他），並讓代理從客戶端獲取所有ssh流量。 3）ssh代理將流量路由到sshd 4）然後我可以通過分析ssh代理日誌來查看所有用戶的活動。而已。
夢可能嗎？
聰明，但有一個嚴重的缺陷：你不會獲得任何新的信息。
爲什麼？ 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）來記錄它正在做什麼或被請求做什麼。