forwarded-tcpip vs. direct-tcpip
yawnmoth
forwarded-tcpip and direct-tcpip is the fact that the latter requires
forwarding be requested via a tcpip-forward SSH_MSG_GLOBAL_REQUEST
message whereas the latter does not. my question is... why would you
want to chose one over the other? PuTTY appears to only support
direct-tcpip, for example.
yawnmoth
According to wikipedia.org, direct-tcpip is for "client-to-server
forwarded connections" and forwarded-tcpip is for "server-to-client
forwarded connections". Ignoring the fact that I'm not even sure
where, in RFC4254, this is stated, under what circumstances would you
want to forward connections from the server to the client? I can't
see, for example, why an SSH server would want an SSH client, for
example, to make an HTTP request on its behalf and forward the result
back to the server.
Simon Tatham
> According to wikipedia.org, direct-tcpip is for "client-to-server
> forwarded connections" and forwarded-tcpip is for "server-to-client
> forwarded connections".
Yes. "direct-tcpip" is initiated by the client at any time with no
prior arrangement; the client just asks the server "Please make a
network connection to some address and port number, and gateway it
into an SSH channel which I'm now opening for the purpose".
"forwarded-tcpip" is sent by the server to the client after the
client has previously sent a GLOBAL_REQUEST "tcpip-forward". The
latter means "Please listen on the following port number, and when
connections come in to it, open an SSH channel for each one"; so the
former means "You know that port you asked me to listen on? Well,
someone's just connected to it. Here are their details, and here's
an SSH channel to carry the connection data."
> under what circumstances would you want to forward connections from
> the server to the client? I can't see, for example, why an SSH
> server would want an SSH client, for example, to make an HTTP
> request on its behalf and forward the result back to the server.
Note that "forwarded-tcpip" _cannot_ do this, since the message
doesn't specify the ultimate destination of the connection and so
the SSH server can't spontaneously ask the client to connect to any
old client-side address. (If the server maintainer really wanted to
abuse the connection in this way, the server could try sending a
"direct-tcpip" request and hope the client was implemented by
somebody who had also implemented a server and had inadequately
separated the code for the two, but any sensible client would
immediately refuse such a request.)
No. All port forwarding is done at the behest of the client. The
typical client-side user interface provides two very similar-looking
options, -L and -R. Each one specifies a port to listen on at one
end of the connection, and an address and port to which connections
should be forwarded at the other end.
So if I say 'ssh -L 1234:thingy:5678 host', the client opens port
1234 and listens on it, and every time a connection comes in, it
sends a "direct-tcpip" request asking the server to connect to
thingy:5678. Typically a client user will run that command, and then
in another window on the client machine run some other command that
connects to that port.
Conversely, if I say 'ssh -R 1234:thingy:5678', the client needs to
arrange for the _server_ to listen on port 1234, which it does by
sending a GLOBAL_REQUEST "tcpip-forward". The server notifies it
that a connection has come in by sending back a CHANNEL_OPEN
"forwarded-tcpip", at which point the client looks up the remote
port number in its "what do I do with this again?" table and makes a
local network connection to thingy:5678. And typically a client user
will run that ssh command, and then type into the resulting server
shell prompt another command that connects to the server's port
1234.
As for _why_ you'd want to do either of these things? Well, any
number of reasons. The typical reason for port forwarding is either
to apply the security protections of SSH to some type of network
connection that does not inherently protect itself, or for one
machine to gain access to a network address to which it can't route
directly but the other end can. For instance, suppose I was running
a version control server (svnserve, or CVS pserver, or whatever
these newfangled DVCSes have in that sort of area) on my home
machine, and wanted to check out some of my personal software from
it and run it on a co-lo server. So I log in to the co-lo with an
'ssh -R' option that forwards some port on the server back to the
svnserve port on my local machine, and then I can do my 'svn co' and
be confident that nobody got to fiddle with the source code as it
made its way across the network. Also, since my home svnserve port
was probably firewalled off from the global Internet on general
principles, this manoeuvre has the side effect of temporarily
authorising the co-lo machine to connect to it at all.
--
Simon Tatham What do we want? ROT13!
<ana...@pobox.com> When do we want it? ABJ!