This replaces the pure radio-button setup that we've always had on the
Session config panel.
Since the last release, that set of radio buttons has been getting out
of hand. We've added two new protocols (SUPDUP, and the 'bare
ssh-connection' aka psusan protocol), neither of which is mainstream
enough to be a sensible thing to wave at all users on the front page
of the config GUI, so that they perhaps start wondering if that's the
protocol they want to use, or get sidetracked by going and looking it
up.
The replacement UI still has radio buttons, but only for the most
common protocols, which will typically be SSH and serial. Everything
else is relegated to a drop-down list sitting next to a third radio
button labelled "Other".
In every be_* module providing a backends[] list, there's also a
variable n_ui_backends which indicates how many of the backends ought
to appear as first-level radio buttons.
(Credit where due: this patch is a joint effort between Jacob and me,
and is one of those rare cases where it would be nice to be able to
put both our names into the Author field of the commit. Failing that,
I can at least mention it here.)
This is the same protocol that PuTTY's connection sharing has been
using for years, to communicate between the downstream and upstream
PuTTYs. I'm now promoting it to be a first-class member of the
protocols list: if you have a server for it, you can select it in the
GUI or on the command line, and write out a saved session that
specifies it.
This would be completely insecure if you used it as an ordinary
network protocol, of course. Not only is it non-cryptographic and wide
open to eavesdropping and hijacking, but it's not even _authenticated_
- it begins after the userauth phase of SSH. So there isn't even the
mild security theatre of entering an easy-to-eavesdrop password, as
there is with, say, Telnet.
However, that's not what I want to use it for. My aim is to use it for
various specialist and niche purposes, all of which involve speaking
it over an 8-bit-clean data channel that is already set up, secured
and authenticated by other methods. There are lots of examples of such
channels:
- a userv(1) invocation
- the console of a UML kernel
- the stdio channels into other kinds of container, such as Docker
- the 'adb shell' channel (although it seems quite hard to run a
custom binary at the far end of that)
- a pair of pipes between PuTTY and a Cygwin helper process
- and so on.
So this protocol is intended as a convenient way to get a client at
one end of any those to run a shell session at the other end. Unlike
other approaches, it will give you all the SSH-flavoured amenities
you're already used to, like forwarding your SSH agent into the
container, or forwarding selected network ports in or out of it, or
letting it open a window on your X server, or doing SCP/SFTP style
file transfer.
Of course another way to get all those amenities would be to run an
ordinary SSH server over the same channel - but this approach avoids
having to manage a phony password or authentication key, or taking up
your CPU time with pointless crypto.
Nearly every part of the code that ever handles a full backend
structure has historically done it using a pair of pointer variables,
one pointing at a constant struct full of function pointers, and the
other pointing to a 'void *' state object that's passed to each of
those.
While I'm modernising the rest of the code, this seems like a good
time to turn that into the same more or less type-safe and less
cumbersome system as I'm using for other parts of the code, such as
Socket, Plug, BinaryPacketProtocol and so forth: the Backend structure
contains a vtable pointer, and a system of macro wrappers handles
dispatching through that vtable.
Should be no significant change in behaviour.
(Well, entering usernames containing commas on Plink's command line will be
a little harder now.)
[originally from svn r7628]
particular, the config box uses it in place of the word `PuTTY',
which means mid-session reconfig in pterm will look less strange
once I implement it. Also, while I'm at it, I've personalised all
the dialog boxes and menu items and suchlike so that PuTTYtel
actually claims to be PuTTYtel rather than PuTTY.
[originally from svn r3074]
link-module const variable `be_default_protocol' which suggests a sensible
default to the front end (which can ignore it). (DEFAULT_PORT is replaced by a
lookup in the backend[] table.)
Still not pretty, but it does mean that the recent fix for `ssh-default'
doesn't break PuTTYtel.
[originally from svn r2613]
source files in which it's no longer required (it was previously
required in anything that included <putty.h>, but not any more).
Also moved a couple of stray bits of exposed WinSock back into
winnet.c (getservbyname from ssh.c and AF_INET from proxy.c).
[originally from svn r2160]
advantages:
- protocol modules can call sk_write() without having to worry
about writes blocking, because blocking writes are handled in the
abstraction layer and retried later.
- `Lost connection while sending' is a thing of the past.
- <winsock.h> is no longer needed in most modules, because
"putty.h" doesn't have to declare `SOCKET' variables any more,
only the abstracted `Socket' type.
- select()-equivalent between multiple sockets will now be handled
sensibly, which opens the way for things like SSH port
forwarding.
[originally from svn r744]
variant which is patent-safe in the US and legal in France and
Russia. This is a horrible hack in some ways: it's shown up serious
deficiencies in the module boundaries. Needs further work, probably
once the SSH implementations are recombined.
[originally from svn r410]
