mid-session in SSH2: this forces an immediate rekey to activate the
new settings. I'm not sure exactly what this will be useful for
(except possibly it might make comparative performance testing
easier?), but it has wonderful James Bond value for being able to
switch to a more secure cipher before doing anything sensitive :-)
If, that is, you weren't using the most secure one to begin with...
[originally from svn r5051]
to be destroying old ones _before_ creating new ones, so that we can
reuse a port for a new purpose without colliding with ourselves.
Also fixed port forwarding, which my IPv6 checkin had completely
funted :-)
[originally from svn r5049]
of polishing to bring them to what I think should in principle be
release quality. Unlike the unfix.org patches themselves, this
checkin enables IPv6 by default; if you want to leave it out, you
have to build with COMPAT=-DNO_IPV6.
I have tested that this compiles on Visual C 7 (so the nightlies
_should_ acquire IPv6 support without missing a beat), but since I
don't have IPv6 set up myself I haven't actually tested that it
_works_. It still seems to make correct IPv4 connections, but that's
all I've been able to verify for myself. Further testing is needed.
[originally from svn r5047]
[this svn revision also touched putty-wishlist]
mid-session if we are not using SSHv1. I've done this by introducing
a generic `cfg_info' function which every back end can use to
communicate an int's worth of data to setup_config_box; in SSH
that's the protocol version in use, and in everything else it's
currently zero.
[originally from svn r5040]
[r5031 == d77102a8d5]
IPv6-unrelated changes, which convert ints into unsigned in a few
key places in ssh.c. Looks harmless at worst, possibly terribly
useful, so I think we'll have these no matter what the real IPv6
stuff is up to!
[originally from svn r5038]
bit is working out when to reschedule the next rekey for when the
timeout or data limit changes; sometimes it will be _right now_
because we're already over the new limit.
Still to do: the Kex panel should not appear in mid-session if we
are using SSHv1.
[originally from svn r5031]
Change Settings, the port forwarding setup function is run again,
and tags all existing port forwardings as `do not keep'. Then it
iterates through the config in the normal way; when it encounters a
port forwarding which is already in the tree, it tags it `keep'
rather than setting it up from scratch. Finally, it goes through the
tree and removes any that haven't been labelled `keep'. Hence,
editing the list of forwardings in Change Settings has the effect of
cancelling any forwardings you remove, and adding any new ones.
The SSH panel now appears in the reconfig box, and is empty apart
from a message explaining that it has to be there for subpanels of
it to exist. Better wording for this message would be welcome.
[originally from svn r5030]
routine which is common between SSH1 and SSH2. Since this routine is
not part of the coroutine system, this means it can't sit and wait
to get its various success/failure responses back. Hence, I've
introduced a system of queued packet handlers, each of which waits
for exactly one of a pair of messages (SSH1_SMSG_{SUCCESS,FAILURE}
or SSH2_MSG_REQUEST_{SUCCESS,FAILURE}), handles it when it arrives,
and automatically de-registers itself. Hence the port-forwarding
setup code can be called once, and then subsequent packets related
to it will automatically be handled as they arrive.
The real purpose of all this is that the infrastructure is now there
for me to arrange mid-session configurability of port forwarding.
However, a side benefit is that fewer round trips are involved in
session startup. I'd quite like to move more of the connection setup
(X forwarding, agent forwarding, pty allocation etc) to using the
new queued handler mechanism for this reason.
[originally from svn r5029]
(which will gain more content anon).
Retire BUG_SSH2_DH_GEX and add a backwards-compatibility wart, since we never
did find a way of automatically detecting this alleged server bug, and in any
case there was only ever one report (<3D91F3B5.7030309@inwind.it>, FWIW).
Also generalise askcipher() to a new askalg() (thus touching all the
front-ends).
I've made some attempt to document what SSH key exchange is and why you care,
but it could use some review for clarity (and outright lies).
[originally from svn r5022]
should stop ssh_do_close() accessing freed ssh->channels when invoked later
from ssh_free(). Spotted by Fred Sauer.
(Perhaps this is the cause of the crashes people have been reporting on
abnormal closures such as `Software caused connection abort'? I've not been
able to test this.)
[originally from svn r4946]
timing.c, and hence takes its own responsibility for calling
noise_regular() at regular intervals. Again, this means it will be
called consistently in _all_ the SSH-speaking tools, not just those
in which I remembered to call it!
[originally from svn r4913]
SSH2, is now handled by the packet dispatch table. Dispatch table
entries are enabled as soon as possible, so that if anyone tries to
(for example) start using a forwarded port before the main shell
session setup has finished, things should work sensibly.
The SSH code is now a hybrid of coroutine-based sequential logic and
table-driven event dispatch, each where it makes the most sense. I'm
rather pleased with it.
Should fix: ext-data-at-start, portfwd-at-start.
[originally from svn r4909]
[this svn revision also touched putty-wishlist]
data transfer in either direction (whichever comes first), or at
explicit client request (nice idea Jacob). Have tested by lowering
the limits, and it all seems solid enough; in particular, this has
also allowed me to test the behaviour when connection-level data is
received during rekey, and that looks fine too (at least it does
_now_ :-).
[originally from svn r4908]
[this svn revision also touched putty-wishlist]
which pretty much any module can call to request a call-back in the
future. So terminal.c can do its own handling of blinking, visual
bells and deferred screen updates, without having to rely on
term_update() being called 50 times a second (fixes: pterm-timer);
and ssh.c and telnet.c both invoke a new module pinger.c which takes
care of sending keepalives, so they get sent uniformly in all front
ends (fixes: plink-keepalives, unix-keepalives).
[originally from svn r4906]
[this svn revision also touched putty-wishlist]
ssh1_protocol() and ssh2_protocol() are now high-level functions
which see _every_ SSH packet and decide which lower-level function
to pass it to. Also, they each support a dispatch table of simple
handler functions for message types which can arrive at any time.
Results are:
- ignore, debug and disconnect messages are now handled by the
dispatch table rather than being warts in the rdpkt functions
- SSH2_MSG_WINDOW_ADJUST is handled by the dispatch table, which
means that do_ssh2_authconn doesn't have to explicitly
special-case it absolutely every time it waits for a response to
its latest channel request
- the top-level SSH2 protocol function chooses whether messages get
funnelled to the transport layer or the auth/conn layer based on
the message number ranges defined in the SSH architecture draft -
so things that should go to auth/conn go there even in the middle
of a rekey (although a special case is that nothing goes to
auth/conn until initial kex has finished). This should fix the
other half of ssh2-kex-data.
[originally from svn r4901]
can keep several of them in parallel. In particular, this allows us
to queue outgoing packets during repeat key exchange, to be actually
sent after the rekey completes.
(This doesn't fully fix ssh2-kex-data; also required is the ability
to handle _incoming_ connection-layer packets during rekey without
exploding.)
[originally from svn r4899]
structure have been retired. Now all Packet structures are
dynamically allocated. Each rdpkt function allocates one, and it's
freed after being used; and the packet construction functions
allocate them too, and they're freed by the send functions.
`pktin' and `pktout' were ugly. They were _morally_ still global
variables; even though they were replicated per SSH session to
comply with the Mac no-globals requirement, they weren't really in
the _spirit_ of `dynamically allocate your data'.
As a side effect of this change, the `pktout_blanks' and
`pktout_nblanks' fields in the Ssh structure have been moved into
the Packet structure.
[originally from svn r4898]
prompt for keyboard-interactive. I suspect we should do the same with that
method (especially given the apparent number of systems that use it for
regular password auth), but in the absence of systems to test against I've
not actually made the change. (I'm worried that the `partial success' field
might not be set correctly in a multi-stage authentication, for instance.)
[originally from svn r4850]
authentication state, a failed `password' authentication in SSH-2 was
sending us back to trying `none' and `keyboard-interactive' each time
round, which uses up OpenSSH's quota of authentication attempts rather
quickly. Added a check for `cfg.change_username' to the logic which
sends us back to the start.
[originally from svn r4849]
pointed out that Plink would attempt to use a zero-length username iff
a remote command was specified (because the FLAG_INTERACTIVE test was
erroneously combined with the no-username test).
I don't think this will break non-interactive use; in the cases which
behave differently, Plink would be attempting to use the empty
username, which was almost certainly wrong, whereas now it will give a
prompt (which can be avoided with -batch as usual).
(Although perhaps we should attempt to use a local username as a guess for
the remote username, as PSCP does? I've not done this.)
[originally from svn r4831]
Also, I'm pretty sure that adding a source address to a remote SSH-2 forwarding
can never have worked, since we added an address string to the packet twice in
that case. OpenSSH 3.4p1 certainly doesn't like it (`Server has disabled port
forwarding' debug message). Fixed (and OpenSSH is happier now).
[originally from svn r4727]
mechanics means that each SSH-2 remote tunnel will sfree() something
random and thus have a chance of crashing or doing something else
bad, although it won't otherwise affect execution. Introduced in
1.319 [r4529] (some of my improved diagnostics). One day I'll make a
checkin to ssh.c without forgetting about the coroutines...
[originally from svn r4725]
[r4529 == 27193c4bf0]
fixing `vuln-ssh2-debug', by missing out a field. In most cases
(always_display = 0) we would log a zero-length or truncated message.
(Also add a prototype for ssh2_pkt_getbool().)
[originally from svn r4718]
This is disgustingly huge because old versions of OpenSSH got the message
format wrong, so we have to infer which format is in use. Tested with
Debian stable OpenSSH (3.4p1), with `uint32' packet, and lshd, which uses
the correct `string' packet, and also let me test "core dumped" and the
explanatory message.
[originally from svn r4653]
of the SSH servers I conveniently have access to (Debian stable OpenSSH --
3.4p1 -- and lshd) seem to take a blind bit of notice, but the channel
requests look fine to me in the packet log.
I've included all the signals explicitly defined by
draft-ietf-secsh-connect-19, but I've put the more obscure ones in a submenu
of the specials menu; there's therefore been some minor upheaval to support
such submenus.
[originally from svn r4652]
down. (A side effect of fixing this is that ssh->mainchain is set to NULL
when it closes, which might avoid other sorts of trouble.)
While we're here, don't bother offering SSH1_MSG_IGNORE if we believe the
remote will barf on it.
[originally from svn r4650]
into the Connection panel, and implemented support for the SSH2
"env" request. (I haven't yet found a server which accepts this
request, so although I've visually checked the packet log and it
looks OK, I haven't yet been able to do a full end-to-end test.)
Also, the `pty' backend reads this data and does a series of
`putenv' commands before launching the shell or application.
This is mostly because in last week's UTF-8 faffings I got
thoroughly sick of typing `export LANG=en_GB.UTF-8' every time I
started a new testing pterm, and it suddenly occurred to me that
this would be precisely the sort of thing you'd want to have pterm
set up for you, particularly since you can configure it alongside
the translation settings and so you can ensure they match up
properly.
[originally from svn r4645]
PuTTY / Plink not to run a remote shell/command at all. Supported in
the GUI configuration and via the (OpenSSH-like) -N command-line
option.
No effort is currently made to arrange `nice' UI properties. If you
do this in GUI PuTTY, a full-size terminal window will still be
created, and will sit there with almost nothing in it throughout
your session. If you do it in Plink, Plink will not accept any kind
of request to terminate gracefully; you'll have to ^C or kill it.
Nonetheless, even this little will be useful to some people...
[originally from svn r4614]
by default (although they can be included). There's also an option to remove
session data, which is good both for privacy and for reducing the size of
logfiles.
[originally from svn r4593]
enable login with this version. (I'd suspected as much -- see ssh.c CVS
log 1.299 [r3359] -- and Geoffrey Hughes has now confirmed this.)
[originally from svn r4566]
[r3359 == d534d4e104]
truncated - it was from OpenSSH on HP/UX and had all sorts of stuff in it
("last successful login" etc).
Bodged it by bumping up the space allocated in the fixed array for a password
prompt. Also added an indication that the prompt is being truncated, as
required by draft-ietf-secsh-auth-kbdinteract-06.
(NB that before this checkin, there was a more-or-less harmless buffer overread
where if we ever received a keyboard-interactive prompt with echo=1, we'd
probably spew goo on the terminal; fixed now.)
[originally from svn r4476]
forwarded X11 connection is now logged as well as the closing; but we also
log the peer IP/port in case it's interesting, and log the reason for
refusing to honour a channel open.
[originally from svn r4451]
handle source address spec ":10023"; ignoring' type errors in the
Event Log. The forwarding would go ahead as normal so this is
cosmetic. Fixed.
[originally from svn r4392]
No very good reason, but I've occasionally wanted to frob it to see if it
makes any difference to problems I'm having, and it was easy.
Tested that it does actually cause keepalives on Windows (with tcpdump);
should also work on Unix. Not implemented on Mac (does nothing), but then
neither is TCP_NODELAY.
Quite a big checkin, much of which is adding `keepalive' alongside `nodelay'
in network function calls.
[originally from svn r4309]
account of coroutines and used local variables over a crFoo. I believe the
impact was cosmetic, affecting the speeds reported in the Event Log only.
I've put the variables `ispeed' and `ospeed' in the main ssh_tag structure,
even though they're only live for a short duration; I did this rather than
create a new state struct for ssh1_protocol() (since ssh_tag already has
short-duration junk like portfwd_strptr).
[originally from svn r4272]
(we didn't before) - `ssh-termspeed'.
In the process, I've removed the individual controls on the Telnet and
Rlogin panels and replaced them with one on the Connection panel (since they
were backed by the same storage anyway).
The terminal speeds sent in SSH are logged in the Event Log.
[originally from svn r4133]
things; it called freebn on the DH gex values even if DH gex had not
taken place. Bug was trivially reproducible as a NULL-dereference
segfault by making any SSH2 connection with DH gex disabled. Should
now be fixed.
[originally from svn r3678]
functions have sprouted `**errorstr' arguments, which if non-NULL can
return a textual error message. The interface additions are patchy and
ad-hoc since this seemed to suit the style of the existing interfaces.
I've since realised that most of this is masked by sanity-checking that
gets done before these functions are called, but it will at least report
MAC failures and the like (tested on Unix), which was the original point
of the exercise.
Note that not everyone who could be using this information is at the
moment.
[originally from svn r3430]
sk_new() on invocation; these functions become responsible for (eventually)
freeing it. The caller must not do anything with 'addr' after it's been passed
in. (Ick.)
Why:
A SOCKS5 crash appears to have been caused by overzealous freeing of
a SockAddr (ssh.c:1.257 [r2492]), which for proxied connections is
squirreled away long-term (and this can't easily be avoided).
It would have been nice to make a copy of the SockAddr, in case the caller has
a use for it, but one of the implementations (uxnet.c) hides a "struct
addrinfo" in there, and we have no defined way to duplicate those. (None of the
current callers _do_ have a further use for the SockAddr.)
As far as I can tell, everything _except_ proxying only needs addr for the
duration of the call, so sk_addr_free()s immediately. If I'm mistaken, it
should at least be easier to find the offending free()...
[originally from svn r3383]
[r2492 == bdd6633970]
OSU VMS SSH server <http://kcgl1.eng.ohio-state.edu/~jonesd/ssh/>.
The changelog appears to indicate that the server was fixed for pwplain1 at
1.5alpha4, and for IGNORE and DEBUG messages at 1.5alpha6. However I'm going
to go on the reports we've had as I haven't tested this; and they indicate
only that 1.5alpha6 is known not to require any bug compatibility modes.
(I wasn't sure whether to add this at all, given that upgrading to version
OSU_1.5alpha6 is an easy way to fix the problem. However, there is precedent
for adding detection for old versions of servers which have since been fixed.)
[originally from svn r3359]
reading) in the zlib code when fed certain kinds of invalid data. As
a result, ssh.c now needs to be prepared for zlib_decompress_block
to return failure.
[originally from svn r3306]
with the crc32() function in the zlib interface. (Not that PuTTY
itself _uses_ zlib, but on Unix it's linked against libgtk which
uses libpng which uses zlib. And zlib has poor namespace management
so it defines this ridiculously intrusive function name. Arrrrgh.)
[originally from svn r3191]
callback function; it may return 0 to indicate that it doesn't have
an answer _yet_, in which case it will call the callback later on
when it does, or it may return 1 to indicate that it's got an answer
right now. The Windows agent_query() implementation is functionally
unchanged and still synchronous, but the Unix one is async (since
that one was really easy to do via uxsel). ssh.c copes cheerfully
with either return value, so other ports are at liberty to be sync
or async as they choose.
[originally from svn r3153]
credible effort to shut down open forwardings cleanly when the
owning SSH connection terminates abruptly (for whatever reason).
[originally from svn r3137]
time. This gives rise to a whole bunch of spare warnings, one or two
of which might have been actual bugs; now all resolved.
[originally from svn r3134]
broken! We were expecting the peer address/port in the incoming
packet _before_ the connected address/port, which is just wrong. I
wonder how I managed to mess that up.
[originally from svn r3083]
supports SOCKS 4, SOCKS 4A and SOCKS 5 (well, actually IPv6 in SOCKS
5 isn't supported, but it'll be no difficulty once I actually get
round to it). Thanks to Chas Honton for his `stone soup' patch: I
didn't end up actually using any of his code, but it galvanised me
into doing it properly myself :-)
[originally from svn r3055]
`Special Command' menu, in which any backend can place its own list
of magical things the user might want to ask the backend to do. In
particular I've implemented the recently proposed "break" extension
in SSH2 using this mechanism.
NB this checkin slightly breaks the Mac build, since it needs to
provide at least a stub form of update_specials_menu().
[originally from svn r3054]
malloc functions, which automatically cast to the same type they're
allocating the size of. Should prevent any future errors involving
mallocing the size of the wrong structure type, and will also make
life easier if we ever need to turn the PuTTY core code from real C
into C++-friendly C. I haven't touched the Mac frontend in this
checkin because I couldn't compile or test it.
[originally from svn r3014]
occurs to me that would also be a good place to put a copy of the
instructions for disabling Edit and Continue debugging. Nobody
_actually_ reads the README, after all...
[originally from svn r2935]
which have a strange idea of what data should be signed in a PK auth
request. This actually got in my way while doing serious things at
work! :-)
[originally from svn r2800]
self: if you change the type of a variable and everything compiles
without type-checking errors, that doesn't mean it's all fixed,
because variadic functions aren't type-checked! Oops.)
[originally from svn r2799]
opaque to all platform-independent modules and only handled within
per-platform code. `Filename' is there because the Mac has a magic
way to store filenames (though currently this checkin doesn't
support it!); `FontSpec' is there so that all the auxiliary stuff
such as font height and charset and so on which is needed under
Windows but not Unix can be kept where it belongs, and so that I can
have a hope in hell of dealing with a font chooser in the forthcoming
cross-platform config box code, and best of all it gets the horrid
font height wart out of settings.c and into the Windows code where
it should be.
The Mac part of this checkin is a bunch of random guesses which will
probably not quite compile, but which look roughly right to me.
Sorry if I screwed it up, Ben :-)
[originally from svn r2765]
Everything in there which is integral is now an actual int, which
means my forthcoming revamp of the config box will be able to work
with `int *' pointers without fear of doom.
[originally from svn r2733]
areas of the code. Not all back-ends have been tested, but Telnet and SSH
behave reasonably.
Incidentally, almost all of this patch was written through Mac PuTTY,
admittedly over a Telnet connection.
[originally from svn r2615]
