Client Callback For TCPIP-Forward (Remote Port Forwarding) Missing

[judgeman5]

Maybe I'm missing something, but is there a reason a callback isn't implemented on the client side when the server requests a remote port forward using the forward_tcpip function from the server handle. I know from the RFC docs that a client should always reject a forward_tcpip request, but couldn't we still provide a callback for it and make the default functionality deny/do_nothing. The forward_tcpip function on the server was implemented, so I don't see why we can't add a callback that can accept it on the client end.

Without this functionality, the server can't call reverse port forwards to the client, unless done through a custom task that the client needs to interpret, then open the listener, then call the client handle's channel_open_direct_tcpip to callback to the server once the tunnel has been established. I think adding the ability for the client to have a callback for a forward-tcpip call from the server could be usesful.

Apologies if I am misinterpreting something. Appreciate any help and feedback!

[HealsCodes]

Correct me if I'm wrong but this would be a feature that'd never do anything unless you're also providing the server end of the code knowing about the ability of the client to accept new reverse forwards at runtime - wouldn't it?

With standard RFC conform client / server setups it's always the client knowing which ports should be forwarded from the client side to the server (local and dynamic listen [-L / -D for openssh]) or server to client (remote listen [-R for openssh]) with the server having no actual ability to signal a forward_tcpip to the client; and even if it had, having to expect that the client would simply reject it anyway because the RFC states that it should.

[judgeman5]

@HealsCodes

Fair point and it makes sense why this functionality is not in there. If you read description under the issue, I lay out some reasoning and mention that RFC does mention this is not possible/should be denied. I just think it would be a nice to have and the Russh library has the ability to do custom messaging not found on other SSH libs. I tried to look for RFC SSH docs related to the OpenDirectStreamLocal (this is implemented in Russh), but couldn't find anything so just thought this would be another cool feature RFC SSH doesn't support.

I just think it's a unique feature to add and has some use cases.