Combining Transparent Proxying with SSH Port Forwarding
tamaster at spamblocked.earthlink.net
Thu Sep 11 05:24:21 EST 2003
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
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...
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"
More information about the openssh-unix-dev