I am trying to log into a remote machine, and use it as a tunnel for
my browser. I'm trying to use the SOCKS-based Dynamic local proxy
option. The problem I'm having is that it doesn't correctly setup the
SOCKS proxy, until I try and run it again with a different port. But
then, it forwards for both the original and the second port I chose.
Here's an example (with the output trimmed down):
First, I try and have localhost:12345 be my SOCKS proxy.
> plink.exe username@remotehost -v -N -D 12345 -i keyfile.ppk
We claim version: SSH-2.0-PuTTY_Release_0.60
Authenticating with public key "keyfile"
Access granted
After this, netstat -a shows that nothing is listening on localhost:
12345, which means something didn't work right. If I close/restart
the tunnel, it's the same result. No listening port.
If I change 12345 to something ELSE (54321 in this example), I get:
> plink.exe username@remotehost -v -N -D 54321 -i keyfile.ppk
We claim version: SSH-2.0-PuTTY_Release_0.60
Authenticating with public key "keyfile"
Access granted
Local port 12345 SOCKS dynamic forwarding
Local port 54321 SOCKS dynamic forwarding
So now I have TWO listening ports, even though I only asked for one!
They both show up in netstat -a, and both seem to work. From here on
out (until I reboot), no matter what other port I try, it will listen
on that new port AND on 12345.
Any idea what is going on here? Thanks.
Do you have a saved session called "remotehost"?
I can replicate this behaviour if I have such a session which is set
up to create a SOCKS listener on port 12345 (equivalent of "-D 12345");
Plink will implicitly look for a saved session called "remotehost",
and having the same port forwarding request in the session and on the
command line seems to "cancel out" somehow -- I haven't investigated
in detail yet, but this is clearly a bug. It would also explain your
second observation.
Ah! That seems to be it, thanks Jacob. I must have never noticed
this before because I was giving plink just the IP of remotehost, and
now I'm just giving it remotehost. I do indeed have a saved session
with the same name, it didn't even cross my mind that that could be a
problem. I went back to the direct IP, and it's working as expected
now. A silly bug, but I'm glad you figured that out for me.
Thanks again.
I have now. I think the fix has missed today's (Wednesday's) nightly
build, but it should be fixed in Thursday's development snapshot (as
of r8623). Let me know if the bug that's been fixed is the same as the
one you found ;)