Local port forwarding implementation, when to close channel

[blacktemplar]

Hi, I am trying to implement local port forwaring and my goal is to be as close as possible to the functionality of ssh -L .... I found issue #256 that is related and followed the ideas there. But the code there has an important drawback in my opinion, for every connection it creates an inner loop that never terminates (listens for client/server messages indefinitely), see:

loop {
    tokio::select! {
         _ = tokio::io::copy(&mut reader, &mut channel) => {},
         _ = tokio::io::copy(&mut channel, &mut writer) => {},
    };
}

This means we have infinitely running tokio tasks that amess if the port forwarding is running for a long time.

What is the suggested solution to that problem?

[Eugeny]

Both AsyncRead and AsyncWrite ends of the ChannelStream will "close" as soon as the SSH channel EOFs/is closed

[Eugeny]

Moreover, dropping the Write handle will EOF the channel from your side

[blacktemplar]

Hi @Eugeny thanks for your answer and your explanation. I see how this is related but I still don't know how it would directly help me with my problem. Are you saying that the original code in issue #256 does not lead to infinetly running tokio tasks for each connection or are you saying that there is a better way to do the local port forwarding?

In the end my question boils down to, when is the right point in time to close/drop the Channel and the TcpConnection. In the example in #256 it seems (at least to me) that it never gets closed. I am having a hard time finding specifications how OpenSSH does it (and my ability to read complex C code is quite limited) so probably this is not only a russh question but more a general ssh port forwarding question.

[Eugeny]

Yes, I've reworked that code into a working example: https://gist.github.com/Eugeny/9eb1c607ffa64b17453c8006e252ae45

[2024-09-27T20:11:14Z INFO  lpf] Listening on port 50000
[2024-09-27T20:11:16Z INFO  lpf] Accepted connection from 127.0.0.1:64052
[2024-09-27T20:11:17Z INFO  lpf] authenticated
[2024-09-27T20:11:19Z INFO  lpf] Channel writer loop ended, channel will send EOF
[2024-09-27T20:11:20Z INFO  lpf] Channel reader loop ended, channel received EOF
[2024-09-27T20:11:20Z INFO  lpf] Both copy loops ended

In this case the example relies on the server correctly closing the channel, however nothing prevents a broken server from just not doing that and leaving your copy loop waiting. It's also perfectly valid for the read end of the channel to stay open much longer than the write end - for example if you do a local port forward to an HTTP server, the write half will close immediately after sending the query, while the read half will be streaming the response for as long as necessary.

You can of course slap an explicit timeout on the read loop.