Combining Transparent Proxying with SSH Port Forwarding

[Greg Houlette]

I've wondered if this topic has been discussed relative to enhancing
the current capabilities of OpenSSH.  Please forgive me if I don't
use the exact terminology that you may be used to in describing SSH
or Transparent Proxy operation.  I continue to learn.  Always...

Here's what I mean:

1) Port forwarding through SSH is generally a configuration that is
   "port selective".  What I mean by that is there is a port selection
   process via the localhost mapping of the SSH daemon on the local
   server and the SSH client on the remote system (the ports need NOT
   be the same) and a "shared" localhost mapping of the SSH client and
   any configured client programs on the remote system (the ports MUST
   be the same).  The remote client programs must be configured to use
   the "shared" localhost mapping of tunneled ports.  Once configured,
   the selected port traffic of these client programs is then forwarded
   through the SSH tunnel 'by proxy'.

2) Transparent proxying (as I understand it) eliminates the requirement
   to formally configure client programs (some of which may be server
   daemons) to explicitly send their traffic to a proxy service (local
   or remote).  This is accomplished through a mechanism of redirection
   of traffic (the specificity of which is under considerable control).
   By making this redirection effectively invisible and under specific
   control, the COMPATABILITY of the application of the proxying of
   traffic of the client programs (some of which may be server daemons)
   is considerably increased.  It can also allows enabling and disabling
   of the proxying on a process by process basis (specificity) on such
   criteria as performance impact and security requirements.

3) Combining Transparent Proxying with Port Forwarding using the SSH
   protocol would entail the addition of traffic redirection capability
   first to the SSH client, but additionally to the SSH server daemon.
   The tunneling selection criteria would then no longer be bound just
   to "port selection" (which any client program can access via the
   localhost mapping) as is currently defined.  Additionally, using the
   transparent proxying to perform protocol conversion would allow for
   the tunneling of other IP traffic such as UDP to be performed.  And
   it should be possible, if the capability for supporting multiple
   SSH sessions were build into the transparent proxy for the SSH
   client, to do more advanced and dynamic redirection of tunneled
   traffic such as load balancing, process by process tunnel mapping,
   and redundant reliability improvements via failover switching of
   tunnels.

I've believed for some time that the SSH capability could be enhanced
considerably by combining it with other traffic control capabilities.

Not a simple undertaking though...

GregH

All direct responses should use the following e-mail address rather
than the one in the from: header (which will get you NOWHERE).


-------------------------------------------------------------------------
Greg Houlette <tamaster at pobox dot com>    *  Give me the graphical UI
Do you know who owns your network today?     *  that will "condense fact
GPG 1.2.2 Public Keys available upon request *  from the vapor of nuance"