Each of the minor start-of-session requests is now dealt with by its own
little co-routine, while the shell/command is done in do_ssh2_authconn()
itself. This eliminates one more round-trip in session setup: PuTTY gets
all the way up to sending a shell request before worrying about any
replies.
[originally from svn r9616]
Now each channel has a queue of arbitrary handlers for those messages,
with anything that sends a CHANNEL_REQUEST with want_reply true pushing
a new entry onto the queue, and a shared handler that dispatches
responses appropriately.
Currently, this is only used for winadj@putty.projects.tartarus.org, but
extending it to cover the initial requests as well shouldn't be too
painful.
[originally from svn r9615]
There's no need to have identical code generating server-to-client and
client-to-server versions of the cipher and MAC lists; a couple of
twice-around loops will do fine.
[originally from svn r9610]
Before, NULL in the dispatch table meant "send to the appropriate one of
do_ssh2_transport() and do_ssh2_authconn()". Now those (via small
shims) are specified directly in the dispatch table, so ssh2_protocol()
is much simpler.
In the process, this has somewhat centralised the handling of gross
server protocol violations. PuTTY will now disconnect with a rude
message when (e.g.) OpenSSH sends us an SSH_MSG_UNIMPLEMENTED when we
try to KEXINIT during authentication.
[originally from svn r9609]
by sending most of the initial SSH_MSG_CHANNEL_REQUEST messages before
waiting for any replies. The initial version of this code was a clever
thing with a two-pass loop, but that got hairy so I went for the simpler
approach of separating the request and reply code and having flags to
keep track of which requests have been sent.
[originally from svn r9599]
winadj@putty.projects.tartarus.org request. Not currently enabled
automatically, but should be usable as a manual workaround.
[originally from svn r9592]
zero but does it in such a way that over-clever compilers hopefully
won't helpfully optimise the call away if you do it just before
freeing something or letting it go out of scope. Use this for
(hopefully) every memset whose job is to destroy sensitive data that
might otherwise be left lying around in the process's memory.
[originally from svn r9586]
calling back->unthrottle), we should immediately call
ssh_process_queued_incoming_data to handle the SSH packets that have
been saved for later functioning while we were throttled. Otherwise,
they'll sit there unhandled until the next call to ssh_gotdata, which
might not be for ages if the server thinks it's waiting for us.
[originally from svn r9523]
already sent SSH2_MSG_CHANNEL_CLOSE, we should not skip the _whole_ of
sshfwd_unclean_close(), only the part about sending
SSH2_MSG_CHANNEL_CLOSE. It's still important to retag the SSH channel
as CHAN_ZOMBIE and clean up its previous data provider.
[originally from svn r9389]
subsidiary network modules like portfwd.c. To be called when the
subsidiary module experiences a socket error: it sends an emergency
CHANNEL_CLOSE (not just outgoing CHANNEL_EOF), and immediately deletes
the local side of the channel. (I've invented a new channel type in
ssh.c called CHAN_ZOMBIE, for channels whose original local side has
already been thrown away and they're just hanging around waiting to
receive the acknowledging CHANNEL_CLOSE.)
As a result of this and the last few commits, I can now run a port
forwarding session in which a local socket error occurs on a forwarded
port, and PuTTY now handles it apparently correctly, closing both the
SSH channel and the local socket and then actually recognising that
it's OK to terminate when all _other_ channels have been closed.
Previously the channel corresponding to the duff connection would
linger around (because of net_pending_errors never being called), and
keep being selected on (hence chewing CPU), and inhibit program
termination at the end of the session (because not all channels were
closed).
[originally from svn r9364]
for which we've already sent CHANNEL_CLOSE. It would be embarrassing
if the remote end had also sent CHANNEL_CLOSE in response and then
received our communication once it had forgotten about the channel.
[originally from svn r9360]
from forwarding data sources which will be good enough to last until
we close the socket, in the form of the override_throttle() functions.
So this finishes up the work in r9283, by manufacturing outgoing EOF
in response to incoming CLOSE on all channel types.
[originally from svn r9284]
[r9283 == c54e228d04]
incoming CHANNEL_CLOSE, if it's the main session channel. The idea is
that invocations such as 'plink -T hostname sh' (running a shell
without a remote pty) can be exited by typing 'exit' to the remote
shell, without plink blocking forever waiting for outgoing EOF.
I think it would be better to do the same for all other channel types
too, but that would need an extra API call which I haven't
implemented yet.
[originally from svn r9283]
backend should unilaterally assume outgoing EOF when it sees incoming
EOF, if and only if the main session channel is talking to a pty.
(Because ptys don't have a strong concept of EOF in the first place,
that seems like a sensible place to draw the line.) This fixes a bug
introduced by today's revamp in which if you used Unix Plink to run a
console session it would hang after you hit ^D - because the server
had sent EOF, but it was waiting for a client-side EOF too.
[originally from svn r9282]
data channels. Should comprehensively fix 'half-closed', in principle,
though it's a big and complicated change and so there's a good chance
I've made at least one mistake somewhere.
All connections should now be rigorous about propagating end-of-file
(or end-of-data-stream, or socket shutdown, or whatever) independently
in both directions, except in frontends with no mechanism for sending
explicit EOF (e.g. interactive terminal windows) or backends which are
basically always used for interactive sessions so it's unlikely that
an application would be depending on independent EOF (telnet, rlogin).
EOF should now never accidentally be sent while there's still buffered
data to go out before it. (May help fix 'portfwd-corrupt', and also I
noticed recently that the ssh main session channel can accidentally
have MSG_EOF sent before the output bufchain is clear, leading to
embarrassment when it subsequently does send the output).
[originally from svn r9279]
authentication. We should now produce an Event Log entry for every
authentication attempted and every authentication failure; meanwhile,
messages in the PuTTY window will not be generated for the failure of
auth types unless we also announced in the PuTTY window that we were
trying them. (GSSAPI was getting the latter wrong, leading to spurious
'Access denied' for many users of 0.61.)
[originally from svn r9226]
'Config' in putty.h, which stores all PuTTY's settings and includes an
arbitrary length limit on every single one of those settings which is
stored in string form. In place of it is 'Conf', an opaque data type
everywhere outside the new file conf.c, which stores a list of (key,
value) pairs in which every key contains an integer identifying a
configuration setting, and for some of those integers the key also
contains extra parts (so that, for instance, CONF_environmt is a
string-to-string mapping). Everywhere that a Config was previously
used, a Conf is now; everywhere there was a Config structure copy,
conf_copy() is called; every lookup, adjustment, load and save
operation on a Config has been rewritten; and there's a mechanism for
serialising a Conf into a binary blob and back for use with Duplicate
Session.
User-visible effects of this change _should_ be minimal, though I
don't doubt I've introduced one or two bugs here and there which will
eventually be found. The _intended_ visible effects of this change are
that all arbitrary limits on configuration strings and lists (e.g.
limit on number of port forwardings) should now disappear; that list
boxes in the configuration will now be displayed in a sorted order
rather than the arbitrary order in which they were added to the list
(since the underlying data structure is now a sorted tree234 rather
than an ad-hoc comma-separated string); and one more specific change,
which is that local and dynamic port forwardings on the same port
number are now mutually exclusive in the configuration (putting 'D' in
the key rather than the value was a mistake in the first place).
One other reorganisation as a result of this is that I've moved all
the dialog.c standard handlers (dlg_stdeditbox_handler and friends)
out into config.c, because I can't really justify calling them generic
any more. When they took a pointer to an arbitrary structure type and
the offset of a field within that structure, they were independent of
whether that structure was a Config or something completely different,
but now they really do expect to talk to a Conf, which can _only_ be
used for PuTTY configuration, so I've renamed them all things like
conf_editbox_handler and moved them out of the nominally independent
dialog-box management module into the PuTTY-specific config.c.
[originally from svn r9214]
to "winadj@putty.projects.tartarus.org" with SSH_MSG_CHANNEL_SUCCESS despite
probably having no idea what it means, treat this just the same as
SSH_MSG_CHANNEL_FAILURE instead of killing the connection.
Tested only as far as making sure that winadj/FAILURE with a normal server
isn't _completely_ broken.
[originally from svn r9185]
[this svn revision also touched putty-wishlist]
Currently, if the IPC exchange goes wrong, the Event Log just prints
"Pageant is running. Requesting keys." and then goes on to the next
step without ever saying what happened.
[originally from svn r9177]
those in the CHAN_SOCKDATA_DORMANT state (i.e., local-to-remote forwardings
which the SSH server had not yet acknowledged).
Marcel Kilgus has been running with the ssh_do_close() patch for nearly two
years (*cough*) and reports that it has eliminated frequent
'unclean-close-crash' symptoms for him (due to the unclosed socket generating
a pfd_closing() which accessed freed memory), although I've not reproduced
that. The patch to ssh_free() is mine and not known to fix any symptoms.
[originally from svn r9069]
[this svn revision also touched putty-wishlist]
are now loaded from standard locations (system32 for SSPI, the
registry-stored MIT KfW install location for KfW) rather than using
the risky default DLL search path; I've therefore also added an
option to manually specify a GSS DLL we haven't heard of (which
should in principle Just Work provided it supports proper GSS-API as
specified in the RFC). The same option exists on Unix too, because
it seemed like too useful an idea to reserve to Windows. In
addition, GSSAPI is now documented, and also (unfortunately) its GUI
configuration has been moved out into a sub-subpanel on the grounds
that it was too big to fit in Auth.
[originally from svn r9003]
testing against NULL has already been dereferenced by the time we
bother to test it, so it's a bit pointless - and in any case, no
null pointer can come to this function from any existing call site.
[originally from svn r8990]
methods left to try, it's nice to have the version of that message
going to the client contain the list of methods sent by the server.
Saves a user having to pull it out of an SSH packet log.
[originally from svn r8981]
called 'pending_close'. This deals with the situation in which we're
forwarding a port, have received and locally buffered some data from
the local endpoint but not yet been able to pass it down the SSH
connection due to window limitations, and then the local endpoint
closes its socket. In this situation what we've been doing until now
is to immediately send SSH2_MSG_CHANNEL_CLOSE, causing the data
still in our local buffer to be lost; now we instead set the new
flag, which will remind us to send SSH2_MSG_CHANNEL_CLOSE _after_ we
empty our bufchain.
Should fix at least one manifestation of 'portfwd-close', though I
don't know if it's the cause of all the reports we've ever seen.
[originally from svn r8971]
reorganises the GSSAPI support so that it handles alternative
implementations of the GSS-API. In particular, this means PuTTY can
now talk to MIT Kerberos for Windows instead of being limited to
SSPI. I don't know for sure whether further tweaking will be needed
(to the UI, most likely, or to automatic selection of credentials),
but testing reports suggest it's now at least worth committing to
trunk to get it more widely tested.
[originally from svn r8952]
today reported an SSH2_MSG_UNIMPLEMENTED from a Cisco router which
looks as if it was triggered by SSH2_MSG_IGNORE, so I'm
experimentally putting this flag in. Currently must be manually
enabled, though if it turns out to solve the user's problem then
I'll probably add at least one version string...
[Edited commit message: actually, I also committed in error a piece
of experimental code as part of this checkin. Serve me right for not
running 'svn diff' first.]
[originally from svn r8926]
which we close the socket without destroying the channel. John
Peterson reports periodic crashes under heavy load which appear to
be fixed by this, though I don't know the exact circumstances
induced by that load.
[originally from svn r8871]
out, but are now just ignored.
(We should make more effort to prevent duplicates before they get as far as
ssh_setup_portfwd() -- it's currently trivially easy to enter them in the
GUI and on the command line, let alone both -- but there's bound to be someone
with a saved session containing dupes out there by now, and anyway there are
duplicates we can't detect before getting this far, for instance
"1234:localhost:22" vs "1234:localhost:ssh".)
[originally from svn r8623]
some servers (Debian in particular seems prone to this) send a k-i packet with
no prompts and nothing to display. We were printing an extra "Using
keyboard-interactive authentication" message in this case. (Introduced by me
in r8172, I think.)
[originally from svn r8492]
[r8172 == 211fdb9f46]
s->gss_sndtok in r8326. I'm not sure it was strictly necessary, since
even if there's no send token, gss_init_sec_context() is meant to explicitly
make it empty, but it wasn't an intentional change.
[originally from svn r8337]
[r8326 == 81dafd906e]
