[erlang-questions] ssh direct-tcpip port forwarded tunnel

[Alex Wilson]

Ah, sorry, you are correct.

direct-tcpip is the wrong way around for what you want, it's used for the equivalent of ssh -L, client-listens-server-connects forwarding. The tcpip-forward + forwarded-tcpip channel setup is used for -R, server-listens-client-connects. The client sends tcpip-forward to ask the server to listen on a port, then the server accepts a TCP connection on that port, and then sends a request over SSH to open a forwarded-tcpip channel back to the client, which the client should then accept. Then all the data from the TCP connection is forwarded to that channel and vice versa (see http://www.ietf.org/rfc/rfc4254.txt)

While there is some code that appears to handle these messages in the SSH daemon at the moment, it doesn't look like it's really functional for this kind of remote forwarding tunnel. The daemon looks like it will accept any tcpip-forward request, but it never opens a port or anything and there is no way to generate the forwarded-tcpip channel open requests going back to the client at the moment. I also can see no implementation of server-side handling of direct-tcpip -- I don't want to jump to conclusions, but it looks like maybe this was written in just to prevent crashes with these messages and nothing more -- you should probably take it as a blank slate, not as something to just be fixed up a little to get it going.

Also, I'm pretty sure a subsystem callback module won't work for this, as it's not a subsystem request and it doesn't open a channel -- tcpip-forward is just a global request on its own, then later a channel can be created by the daemon sending open with forwarded-tcpip. So no subsystem will get started (never calls ssh_connection:start_subsytem). I think you'll have to modify the code in ssh_connection and ssh_connection_handler to correctly deal with these messages and provide some sort of interface to set policy / implement the port listening in order to use them. Implementing direct-tcpip would probably be simpler (as there's no real state to deal with), but of course it won't get you what you want if you need the -R functionality.



On 10 Jun 2014, at 5:51 pm, Tom van Neerijnen <tom@REDACTED> wrote:

> Thanks anyway but I think your solution is the wrong way around.
> I'm specifically writing a SSH server, not a SSH client, and my admittedly naive understanding of your example (I've been erlanging for all of a few weeks) and ssh_connection:direct_tcpip is that this would work if I were writing a client but not for a server.
> I may be misunderstanding tho so bear with me while I explain and if I am indeed wrong please let me know where I would hook ssh_connection:direct_tcpip up to a running ssh:daemon.
> 
> I've tracked down the reason it's not working for me to ssh_connection:handle_msg(#ssh_msg_global_request{name = Type, want_reply = WantReply, data = Data}, Connection, _).
> A request for tcpip-forward obviously has want_reply set to true but the function in this case always returns a ssh_msg_request_failure.
> I'm going to have a crack at having it look up from available subsystems (or what ever port forwarding is, I'll give the RFC a better read to understand it) in a similar way to Python's Twisted Conch.
> 
> If I'm missing something obvious please let me know, otherwise if I get it working I'll submit a pull request.