Matt Johnston wrote: > Neither client-ip nor the YY port are given to the remote > server in the SSH_MSG_GLOBAL_REQUEST packet. I don't quite > see how it would be useful though?
The need in my (special) case would be to be able to provide a web-application with a list of only those URLs which are really being forwarded to an HTTP server on the client side. In my use case many clients request two remote port forwardings each, one for telnet, the other for HTTP on the client. For the web application I only want to provide those links for the HTTP remote ports (filtering out the others). For the first step I can live without this, postponing the 'telnet' port forwarding until I find a solution. > Adding unspecified-port remote forwarding would probably be > fairly straightforward - I just didn't see a need for it > previously. If the client printed a message > Remote port <server-port> forwarded to <host:port> > on standard error would that be a useful interface? This would not be sufficient in my case, because I have to know this on the server side. I've already a hook in 'svr_remotetcpreq()' to build a status msg to be written into the server pipe. If I would know at this stage the client local port I could include this information into the status msg. Adding support for unspecified-port remote forwarding would also mean adding support for this in the client (we use a modified 'dbclient'). The actual implementation does not expect a repsonse of type SSH_MSG_REQUEST_SUCCESS with the port no. > Also, I've implemented printing an error message if the > remote forward fails, it'll be in the next release (or the > current development tree) Thanks for that. Michael
