remember to put an empty string in it rather than sending a completely
empty packet. This should help with those servers (notably RomSShell)
that actually check the contents of SSH_MSG_IGNORE.
[originally from svn r7236]
will close the window even in `close window only on clean exit'
mode. Also, while I'm here, arrange a suitable exit code for
"exit-signal".
[originally from svn r7121]
ability to easily re-enable the r5122 behaviour, in case we need to
conditionally switch between the two at a later date.
[originally from svn r7073]
[r5122 == 8a20515844]
[this svn revision also touched putty-wishlist]
(Since we choose to compile with -Werror, this is particularly important.)
I haven't yet checked that the resulting source actually compiles cleanly with
GCC 4, hence not marking `gcc4-warnings' as fixed just yet.
[originally from svn r7041]
BUG_NEEDS_SSH1_PLAIN_PASSWORD do exactly what it says on the tin, independent
of whether BUG_CHOKES_ON_SSH1_IGNORE is set.
This is invisible in the default configuration, as all servers marked as having
the second bug have the first one too, but it would allow one to manually
configure PuTTY to cope with a SSH-1 server that got upset by ignore messages
during authentication, but was fine with their use as keepalives.
[originally from svn r6876]
in an SSH connection _in addition_ to the decrypted packets. This
will hopefully come in useful for debugging wire data corruption
issues: you can strace the server, enable this mode in the client,
and compare the sent and received data.
I'd _like_ to have this mode also log Diffie-Hellman private
exponents, session IDs, encryption and MAC keys, so that the
resulting log file could be used to independently verify the
correctness of all cryptographic operations performed by PuTTY.
However, I haven't been able to convince myself that the security
implications are acceptable. (It doesn't matter that this
information would permit an attacker to decrypt the session, because
the _already_ decrypted session is stored alongside it in the log
file. And I'm not planning, under any circumstances, to log users'
private keys. But gaining access to the log file while the session
was still running would permit an attacker to _hijack_ the session,
and that's the iffy bit.)
[originally from svn r6835]
there): `plink host -nc host2:port' causes the SSH connection's main
channel to be replaced with a direct-tcpip connection to the
specified destination. This feature is mainly designed for use as a
local proxy: setting your local proxy command to `plink %proxyhost
-nc %host:%port' lets you tunnel SSH over SSH with a minimum of
fuss. Works on all platforms.
[originally from svn r6823]
it's NULL. Since we already have one back end (uxpty) which doesn't
in fact talk to a network socket, and may well have more soon, I'm
replacing this TCP/IP-centric function with a nice neutral
`connected' function returning a boolean. Nothing else about its
semantics has currently changed.
[originally from svn r6810]
session termination. `Close window only on clean exit' was not
working properly on Unix in the absence of this:
notify_remote_exit() was being called and ssh_return_exitcode was
returning zero, causing gtk_main_quit() to be called, _before_
connection_fatal() happened.
[originally from svn r6801]
Pageant for local authentication. (This is a `don't use Pageant for
authentication at session startup' button rather than a `pretend
Pageant doesn't exist' button: that is, agent forwarding is
independent of this option.)
[originally from svn r6572]
to be from IP "client-side-connection". Claiming "0.0.0.0" instead seems to
work. Spotted by Brant Thomsen.
[originally from svn r6477]
[this svn revision also touched putty-wishlist]
that the SSH-2 server is happy with. Fixed, and since I'm here, fix
`pubkeyfile-and-pageant' as well (for SSH-1 and SSH-2).
Also, in SSH-2, we now reexamine "methods that can continue" for every
Pageant key offer, which is technically more correct although it seems
unlikely that it was causing any real problems.
(It's not entirely pretty, but neither was the old code. We could probably
do with some sort of abstraction for public/private keys to avoid carting
lots of fiddly bits of data around.)
[originally from svn r6459]
[r6437 == 8719f92c14]
[this svn revision also touched putty-wishlist]
(Much easier since r6437, and actually works to boot.)
[originally from svn r6445]
[r6437 == 8719f92c14]
[this svn revision also touched putty-wishlist]
abstracted out; replace loops structured around a single interaction
per loop with less tortuous code (fixes: `ki-multiprompt-crash',
`ssh1-bad-passphrase-crash'; makes `ssh2-password-expiry' and
`proxy-password-prompt' easier).
The new interaction abstraction has a lot of fields that are unused in
the current code (things like window captions); this is groundwork for
`gui-auth'. However, ssh.c still writes directly to stderr; that may
want to be fixed.
In the GUI apps, user interaction is moved to terminal.c. This should
make it easier to fix things like UTF-8 username entry, although I
haven't attempted to do so. Also, control character filtering can be
tailored to be appropriate for individual front-ends; so far I don't
promise anything other than not having made it any worse.
I've tried to test this fairly exhaustively (although Mac stuff is
untested, as usual). It all seems to basically work, but I bet there
are new bugs. (One I know about is that you can no longer make the
PuTTY window go away with a ^D at the password prompt; this should be
fixed.)
[originally from svn r6437]
[this svn revision also touched putty-wishlist]
packets over about 256 bytes would be logged with 12 bytes of preceding
garbage. (But the rest of the packet was logged in its entirety. This
holds for packets where (int(len/256)%2)==1, with an appropriate fudge
factor applied to `len'.) Ahem.
[originally from svn r6429]
[r5642 == c09d885b27]
patched OpenSSH server. This is controlled by the same user settings
as diffie-hellman-group-exchange-sha1, which may not be optimal, especially
given that they're both referred to as dh-gex-sha1 in saved sessions.
[originally from svn r6272]
storing a SHA-1 hash of the client and server version strings, store the
strings themselves so we can feed them through the appropriate hash when
we know what it is.
[originally from svn r6241]
processed and incoming data being processed out of order, which I suspect is
the cause of `ssh1-fwd-trouble' as noted by Gevan Dutton. I'm not able to
test the failure case, but it doesn't seem to have obviously broken anything
in the cases I have tested, anyway.
[originally from svn r6221]
marks a version string. It's a bit vague about the definition of a line,
but I think it's reasonable to assume that they'll end with LF. Change
do_ssh_init() to ignore "SSH-" anywhere else. This makes the existing state
machine overkill, so replace it with something a little more readable.
[originally from svn r6138]
do_ssh2_transport() was returning the wrong value for rekeys after the first.
This apparent error was introduced in r4901, but we can't see any reason for
the change to have been made. If it turns out to be a mistake to revert it,
I'm sure we'll find out.
Here for posterity is Simon's analysis:
| A lot of the return values from do_ssh2_transport appear to be vestigial: it
| used to be that a zero return from do_ssh2_transport meant it had handled the
| packet internally, and a 1 return meant the packet wasn't a transport-layer
| one and needed to pass on to do_ssh2_authconn. Since r4901, however, the
| layer discrimination is done based on the message type ranges, and the only
| remaining dependency on the return value from do_ssh2_transport is a special
| case in ssh2_protocol which detects the first 1 return and makes the
| initialisation call to do_ssh2_authconn.
|
| Therefore, the gratuitous 1 return on every key exchange as a result of the
| confusing if statement is simply ignored in ssh2_protocol (because
| ssh->protocol_initial_phase_done is already TRUE). So the remaining question
| was, why does the _lack_ of that 1 return not cause a problem, if the if's
| sense is indeed reversed?
|
| The answer is that 1 is still returned, just not by the crReturn inside the
| if statement. It's returned by the next crReturn, just after
| wait_for_rekey(). Which suggests that in fact, the if statement has the
| correct sense, but the crReturn inside it has the wrong value - it should be
| returning _zero_, to indicate that every NEWKEYS after the first one is
| uninteresting to the authconn code, and on the very first run through that
| doesn't happen and the NEWKEYS gets all the way to the crReturn(1) later on.
[originally from svn r5986]
[r4901 == a4ba026838]
enforce the following:
* Packet must have at least one byte of payload and four bytes of padding.
* Total packet length must not exceed 35000 bytes compressed.
* Total packet length including length field must be a multiple of cipher
block size (or eight bytes).
The feebleness of our old checks was noticed by Ben Rudiak-Gould.
[originally from svn r5981]
