In AWS, our users(system admins) can access internal zone DB servers by using SSH tunneling without any local firwall's restrictions. As you know, to access internal node a user must go through public zone gateway server first. Because the gateway is actually a passage, I wish control the traffic from tunneled users on the gateway server. For example, to get the currently connected ip addresses of all clients, to idendify the internal path(eg DB server ip) the user accessed futhermore I wish control the connection of unauthorized users.
To my dreams come true, I think below idea is really ideal. 1) Change sshd port to something other than 22. Restart sshd daemon. 2) Locate ssh proxy(nginx, haproxy or else) prior to sshd and let the proxy get the all ssh traffic from clients. 3) The ssh proxy route the traffic to sshd 4) Then I can see all user's activity by analize ssh proxy log. That's it.
Is it possible dream ?
Clever, but with a critical flaw: you won't gain any new information.
Why? The first S in SSH: "secure."
The "ssh proxy" you envision would be unable to tell you anything about what's going on inside the SSH connections, which is where the tunnels are negotiated. The connections are encrypted, of course, and a significant point of SSH is that it can't be sniffed. The fact that the ssh proxy is on the same machine makes no difference. If it could be sniffed, it wouldn't be secure.
All your SSH proxy could tell you is that an inbound connection was made from a client computer, and syslog already tells you that.
In a real sense, it would not be an "ssh proxy" at all -- it would only be a naïve TCP connection proxy on the inbound connection.
So you wouldn't be able to learn any new information with this approach.
It sounds like what you need is for your ssh daemon, presumably openssh, to log the tunnel connections established by the connecting users.
This blog post (which you will, ironically, need to bypass an invalid SSL certificate in order to view) was mentioned at Server Fault and shows what appears to be a simple modification to the openssh source code to log the information you want: who set up a tunnel, and to where.
Or, enable some debug-level logging on sshd.
So, to me, it seems like the extra TCP proxy is superfluous -- you just need the process doing the actual tunnels (sshd) to log what it is doing or being requested to do.