2006-08-28 10:35:12 +00:00
|
|
|
/*
|
|
|
|
|
* Linking module for PuTTY proper: list the available backends
|
|
|
|
|
* including ssh, plus the serial backend.
|
|
|
|
|
*/
|
|
|
|
|
|
|
|
|
|
#include <stdio.h>
|
|
|
|
|
#include "putty.h"
|
|
|
|
|
|
|
|
|
|
/*
|
|
|
|
|
* This appname is not strictly in the right place, since Plink
|
|
|
|
|
* also uses this module. However, Plink doesn't currently use any
|
|
|
|
|
* of the dialog-box sorts of things that make use of appname, so
|
|
|
|
|
* it shouldn't do any harm here. I'm trying to avoid having to
|
|
|
|
|
* have tiny little source modules containing nothing but
|
|
|
|
|
* declarations of appname, for as long as I can...
|
|
|
|
|
*/
|
|
|
|
|
const char *const appname = "PuTTY";
|
|
|
|
|
|
|
|
|
|
const int be_default_protocol = PROT_SSH;
|
|
|
|
|
|
2018-10-05 06:03:46 +00:00
|
|
|
const struct BackendVtable *const backends[] = {
|
2007-06-30 21:56:44 +00:00
|
|
|
&ssh_backend,
|
New GUI for protocol selection.
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.)
2021-04-10 08:51:29 +00:00
|
|
|
&serial_backend,
|
2007-06-30 21:56:44 +00:00
|
|
|
&telnet_backend,
|
|
|
|
|
&rlogin_backend,
|
2019-04-02 10:16:25 +00:00
|
|
|
&supdup_backend,
|
2007-06-30 21:56:44 +00:00
|
|
|
&raw_backend,
|
New protocol: PROT_SSHCONN, bare ssh-connection.
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.
2020-02-16 12:07:43 +00:00
|
|
|
&sshconn_backend,
|
2007-06-30 21:56:44 +00:00
|
|
|
NULL
|
2006-08-28 10:35:12 +00:00
|
|
|
};
|
New GUI for protocol selection.
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.)
2021-04-10 08:51:29 +00:00
|
|
|
|
|
|
|
|
const size_t n_ui_backends = 2;
|