Home
|
FAQ
|
Feedback
|
Licence
|
Updates
|
Mirrors
|
Keys
|
Links
|
Team
Download:
Stable
·
Snapshot
|
Docs
|
Changes
|
Wishlist
From 0.64 (5ecb7d7f1dd6d66bab2814e9147f5a41896706e7), PuTTY started distinguishing remote port forwardings by the remote address they were bound to as well as the remote port, to better support requesting remote port forwardings on just one address of a multihomed server.
In order to do this, PuTTY assumes that the "address that was connected" it will receive from the server in "forwarded-tcpip" requests will be textually identical to the "address to bind" PuTTY originally sent in its "tcpip-forward" request.
That assumption doesn't appear to be true with Bitvise SSHD. The behaviour reported to us is that if PuTTY sends "localhost", it gets back "127.0.0.1"; if PuTTY sends the empty string (as it does if configured to allow remote ports to accept connections from other hosts), it gets back "0.0.0.0". The mismatch leads PuTTY to reject the tunnel with "Remote port is not recognised", since the remote address doesn't match exactly.
The relevant spec (RFC 4254) is somewhat vague on this. In general, the client can't be expected to be able to translate between names and addresses as seen by the server. However, it would be easy enough for us to give special treatment to obvious localhost addresses, and RFC 4254 ยง7.1 could easily be argued to justify doing that much.
A workaround is to specify the listen address numerically: specify something like "127.0.0.1:10080" as the remote port in the "Source port" box, or on the command-line, something like "-R 127.0.0.1:10080:foovax:80".
Example of what it looks like in PuTTY's Event Log when this goes wrong:
Requesting remote port 10080 forward to foovax:80 Remote port forwarding from 10080 enabled [...] Received remote port 127.0.0.1:10080 open request from 127.0.0.1:50224 Rejected channel open: Remote port is not recognised
Reported with these server versions: