sitting on a pile of buffered data waiting for WINDOW_ADJUSTs, we
should throw away that buffered data, because the CHANNEL_CLOSE tells
us that we won't be receiving those WINDOW_ADJUSTs, and if we hang on
to the data and keep trying then it'll prevent ssh_channel_try_eof
from sending the CHANNEL_EOF which is a prerequisite of sending our
own CHANNEL_CLOSE.
[originally from svn r9953]
crWaitUntilV(pktin) with plain crReturnV, because those coroutines can
be called back either with a response packet from the channel request
_or_ with NULL by ssh_free meaning 'please just clean yourself up'.
[originally from svn r9927]
warnings about insecure crypto components. The latter may crReturn
(though not in any current implementation, I believe), which
invalidates pktin, which is used by the former.
[originally from svn r9921]
of the GET_32BIT macros and then used as length fields. Missing bounds
checks against zero have been added, and also I've introduced a helper
function toint() which casts from unsigned to int in such a way as to
avoid C undefined behaviour, since I'm not sure I trust compilers any
more to do the obviously sensible thing.
[originally from svn r9918]
since there is a theoretical code path (via the crReturn loop after
asking an interactive question about a host key or crypto algorithm)
on which we can leave and return to do_ssh1_login between allocating
and freeing those keys.
(In practice it shouldn't come up anyway with any of the current
implementations of the interactive question functions, not to mention
the unlikelihood of anyone non-specialist still using SSH-1, but
better safe than sorry.)
[originally from svn r9895]
as specified in RFC 6668. This is not so much because I think it's
necessary, but because scrypt uses HMAC-SHA-256 and once we've got it we
may as well use it.
Code very closely derived from the HMAC-SHA-1 code.
Tested against OpenSSH 5.9p1 Debian-5ubuntu1.
[originally from svn r9759]
RFC 4245 section 7.1 specifies the meaning of the "address to bind"
parameter in a "tcpip-forward" request. "0.0.0.0" and "127.0.0.1" are
specified to be all interfaces and the loopback interface respectively
in IPv4, while "" and "localhost" are the address-family-agnostic
equivalents. Switch PuTTY to using the latter, since it doesn't seem
right to force IPv4.
There's an argument that PuTTY should provide a means of configuring the
address family used for remote forwardings like it does for local ones.
[originally from svn r9668]
First, make absolute times unsigned. This means that it's safe to
depend on their overflow behaviour (which is undefined for signed
integers). This requires a little extra care in handling comparisons,
but I think I've correctly adjusted them all.
Second, functions registered with schedule_timer() are guaranteed to be
called with precisely the time that was returned by schedule_timer().
Thus, it's only necessary to check these values for equality rather than
doing risky range checks, so do that.
The timing code still does lots that's undefined, unnecessary, or just
wrong, but this is a good start.
[originally from svn r9667]
confused if they receive a request followed by immediate EOF, since we
currently send outgoing EOF as soon as we see the incoming one - and
then, when the response comes back from the real SSH agent, we send it
along anyway as channel data in spite of having sent EOF.
To fix this, I introduce a new field for each agent channel which
counts the number of calls to ssh_agentf_callback that are currently
expected, and we don't send EOF on an agent channel until we've both
received EOF and that value drops to zero.
[originally from svn r9651]
move the primary conditions out of them into their callers. Fixes a
crash in 'plink -N', since those functions would be called with a NULL
channel parameter and immediately dereference it to try to get c->ssh.
[originally from svn r9644]
They're only likely to be useful for freeing a coroutine state
structure, in which case there's no need to reset the line number
(since all such coroutines keep their line number in the state
structure) and the state structure pointer is always called "s".
[originally from svn r9632]
In sshfwd_unclean_close(), get ssh2_check_close() to handle sending
SSH_MSG_CHANNEL_CLOSE. That way, it can hold off doing so until any
outstanding channel requests are processed.
Also add event log message for unclean channel closures.
[originally from svn r9631]
crFinish or crFinishV, since they will attempt to write to the
coroutine state variable contained in that structure. Introduced some
new all-in-one macros crFinishFree and crFinishFreeV, and used those
instead. Should fix today's report of a crash just after authentication.
[originally from svn r9630]
Part the first: make sure that all structures describing channel
requests are freed when the SSH connection is freed. This involves
adding a means to ask a response handler to free any memory it holds.
Part the second: in ssh_channel_try_eof(), call
ssh2_channel_check_close() rather than emitting an SSH_MSG_CHANNEL_EOF
directly. This avoids the possibility of closing the channel while a
CHANNEL_REQUEST is outstanding.
Also add some assertions that helped with tracking down the latter
problem.
[originally from svn r9623]
This reduces code size a little and also makes it harder to
accidentally request a reply without putting in place a handler for
it or vice versa.
[originally from svn r9620]
The various setup routines can only receive CHANNEL_SUCCESS or
CHANNEL_FAILURE, so there's no need for the to worry about receiving
anything else. Strange packets will end up in do_ssh2_authconn
instead.
[originally from svn r9619]
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]
under SSH-2, don't risk looking at the length field of an incoming packet
until we've successfully MAC'ed the packet.
This requires a change to the MAC mechanics so that we can calculate MACs
incrementally, and output a MAC for the packet so far while still being
able to add more data to the packet later.
[originally from svn r8334]
ourselves, but on Unix then assumed it was compatible with the system's
gss_buffer_desc, which wasn't the case on LP64 systems. Now, on Unix
we make Ssh_gss_buf into an alias for gss_buffer_desc, though we keep
something similar to the existing behaviour on Windows. This requires
renaming a couple of the fields in Ssh_gss_buf, and hence fixing all
the references.
Tested on Linux (MIT Kerberos) and Solaris. Compiled on NetBSD (Heimdal).
Not tested on Windows because neither mingw32 nor winegcc worked out of the
box for me. I think the Windows changes are all syntactic, though, so
if this compiles it should work no worse than before.
[originally from svn r8326]
if we have no better ideas, with UI shamelessly stolen from Quest PuTTY.
Off by default, which effectively reverts the change to using the local
username by default that came in with GSSAPI support in r8138. Anyone wanting
seamless single sign-on will need to set the new option. (The previous
default behaviour was getting in the way in ad-hoc scenarios.)
Note that the PSCP and Unix-Plink behaviour of using the local username by
default have remained unchanged throughout; they are not affected by the new
option. Not sure if that's the Right Thing.
[originally from svn r8324]
[r8138 == de5dd9d65c]
strings more rigorously, and then we look up the local X authority
data in .Xauthority _ourself_ rather than delegating to an external
xauth program. This is (negligibly) more efficient on Unix, assuming
I haven't got it wrong in some subtle way, but its major benefit is
that we can now support X authority lookups on Windows as well
provided the user points us at an appropriate X authority file in
the standard format. A new Windows-specific config option has been
added for this purpose.
[originally from svn r8305]
both directions. We had a bug report yesterday about a Cisco router
sending SSH2_MSG_UNIMPLEMENTED and it wasn't clear for which packet;
logging the sequence numbers should make such problems much easier
to diagnose.
(In fact this logging fix wouldn't have helped in yesterday's case,
because the router also didn't bother to fill in the sequence number
field in the SSH2_MSG_UNIMPLEMENTED packet! This is a precautionary
measure against the next one of these problems.)
[originally from svn r8295]
no actual prompts, we weren't displaying the former, which was wrong. We
should now (although I haven't found a server to test it against).
[originally from svn r8172]
to manually tweak the host name and port number under which the SSH
host key is read and written.
I've put it in the cross-platform Connection panel. Partly under the
flimsy pretext that other backends _can_ use it if they so wish (and
in fact it overrides the host name for title-bar purposes in all
network backends, though it has no other effect in anything but
SSH); but mostly because the SSH panel was too full already :-)
[originally from svn r8033]
We could explicitly re-enable %n, but we only use it in one place, so take
the path of least resistance and remove that single instance. This stops
dupvprintf() getting stuck in a loop (a behaviour that's caused by a workaround
for a broken libc).
<http://msdn.microsoft.com/en-us/library/ms175782(VS.80).aspx>
[originally from svn r8030]
advertise so that the server can't exceed our maximum packet size.
Enable it for "1.36_sshlib GlobalSCAPE" which apparently sends oversize
packets otherwise.
[originally from svn r7804]
as well. This won't be triggered in the usual case, but it's useful
if the remote end ignores our window, or if we're in "simple" mode and
setting the window far larger than is necessary.
[originally from svn r7756]
spurious SSH_MSG_CHANNEL_FAILUREs, treat them as the protocol errors
they are and forcibly disconnect. Inspired by recent traffic on
comp.security.ssh.
[originally from svn r7752]
a single function which also handles checking that channels exist and
are properly open. This should make PuTTY a little less tolerant of
servers that send bogus messages.
[originally from svn r7751]
performance. The theory behind this is fairly simple, though the
implementation turns out to be a little trickier than it looks.
The basic idea is that when the connection isn't being limited by our ability
to process data, we want to ensure that the window size _as seen by the server_
never drops to zero. Measuring the server's view of the window size is done
by arranging for it to acknowledge every SSH_MSG_CHANNEL_WINDOW_ADJUST, or
rather an SSH_MSG_CHANNEL_REQUEST sent just before it. That way we can tell
when it its outgoing data stream it received the window adjustment, and
thus how small the server's view of the window got.
At present, we only ever increase the window size. In theory, we could
arrange to reduce it again if the server's view of it seemed to be persistently
too large, but my experiments suggest that getting this right will be tricky.
[originally from svn r7735]
for it. It's possible that this obsoletes BUG_CHOKES_ON_RSA. Certainly
the one SSH-1.5-Cisco-1.25 server I found was correctly not advertising RSA
auth. For now, leave it in, because I'm not feeling entirely confident.
[originally from svn r7726]
because it can ever be negative, but because we'll be comparing it with
another int. This way, C's promotion rules don't bite us and we should
stand slightly more chance of coping with broken servers that overrun our
window.
[originally from svn r7683]
and tweak ssh2_set_window() so it can cope with that. Also arrange to send
a private channel message in simple mode to tell the server that it can safely
use a large window too.
[originally from svn r7679]
