CONNECT, but contains an extensible framework to allow other
proxies. Apparently SOCKS and ad-hoc-telnet-proxy are already
planned (the GUI mentions them already even though they don't work
yet). GUI includes full configurability and allows definition of
exclusion zones. Rock and roll.
[originally from svn r1598]
Specifically, we explicitly closesocket() all open sockets, which
appears to be necessary since otherwise Windows sends RST rather
than FIN. I'm _sure_ that's a Windows bug, but there we go.
[originally from svn r1574]
keys before _every_ other authentication; so if you tried a local
pubkey _and_ a password, for example, you'd also try Pageant twice.
Now fixed.
[originally from svn r1524]
the private key file given in the config; if it spots this then it
avoids trying it again (and in particular avoids needing to ask for
the passphrase when it knows perfectly well it won't work).
[originally from svn r1523]
process. This is functional in SSH, and vestigial (just returns 0)
in the other three protocols. Plink's Windows exit code is now
determined by the remote process exit code, which should make it
more usable in scripting applications. Tested in both SSH1 and SSH2.
[originally from svn r1518]
connections from outside localhost' switch. Interestingly OpenSSH
3.0 appears to ignore this (though I know it works because ssh.com
3.0 gets it right, and the SSH packet dump agrees that I'm doing the
right thing).
[originally from svn r1496]
sick of recompiling to enable packet dumps. SSH packet dumping is
now provided as a logging option, and dumps to putty.log like all
the other logging options. While I'm at it I cleaned up the format
so that packet types are translated into strings for easy browsing.
POSSIBLE SIDE EFFECT: in the course of this work I had to re-enable
the SSH1 packet length checks which it turns out hadn't actually
been active for some time, so it's possible things might break as a
result. If need be I can always disable those checks for the 0.52
release and think about it more carefully later.
[originally from svn r1493]
configurable option so users can re-enable the feature _if_ they
know they have an SSH2 server that isn't going to get shirty about
it. Inspired by a spectacular increase in OpenSSH's shirtiness.
[originally from svn r1474]
after. Shouldn't make a difference for any server that previously
worked, but we should now interoperate sensibly with servers that
wait to receive our NEWKEYS before sending their own. Apparently
Unisphere produce one such.
[originally from svn r1390]
causes password login to occur on a server that supports password-
through-k-i. Of course when we use the new preference list mechanism
for selecting the order of authentications this will all become much
more sane, but for the moment I've put publickey back up to the top
and things seem to be happier.
[originally from svn r1220]
CHANNEL_OPEN_FAILURE messages, which occur when the remote side is
unable to open a forwarded network connection we have requested. (It
seems they _don't_ show up if you get something mundane like
Connection Refused - the channel is cheerfully opened and
immediately slammed shut - but they do if you try to connect to a
host that doesn't even exist. Try forwarding a port to
frogwibbler:4800 and see what you get.)
[originally from svn r1213]
scp1 if it can't. Currently not very tested - I checked it in as
soon as it completed a successful recursive copy in both directions.
Also, one known bug: you can't specify a remote wildcard, because by
the nature of SFTP we'll need to implement the wildcard engine on
the client side. I do intend to do this (and use the same wildcard
engine in PSFTP as well) but I haven't got round to it yet.
[originally from svn r1208]
by me to make the drag list behaviour slightly more intuitive.
WARNING: DO NOT LOOK AT pl_itemfrompt() IF YOU ARE SQUEAMISH.
[originally from svn r1199]
by ceasing to listen on input channels if the corresponding output
channel isn't accepting data. Has had basic check-I-didn't-actually-
break-anything-too-badly testing, but hasn't been genuinely tested
in stress conditions (because concocting stress conditions is non-
trivial).
[originally from svn r1198]
keyboard-interactive authentication. UNTESTED except that I checked
it compiles. Will ask for testing from the user who complained.
[originally from svn r1195]
attempt keyboard-interactive authentication. We can yell about it if
we make a creditable attempt and are rejected, but if the server
just refuses to even consider it then the user won't really want to
know (and if they do there's the Event Log).
[originally from svn r1180]
