mirror of
https://git.tartarus.org/simon/putty.git
synced 2025-01-09 17:38:00 +00:00
22b492c4f6
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.
33 lines
829 B
C
33 lines
829 B
C
/*
|
|
* Linking module for PuTTY proper: list the available backends
|
|
* including ssh.
|
|
*/
|
|
|
|
#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";
|
|
|
|
#ifdef TELNET_DEFAULT
|
|
const int be_default_protocol = PROT_TELNET;
|
|
#else
|
|
const int be_default_protocol = PROT_SSH;
|
|
#endif
|
|
|
|
const struct BackendVtable *const backends[] = {
|
|
&ssh_backend,
|
|
&telnet_backend,
|
|
&rlogin_backend,
|
|
&raw_backend,
|
|
&sshconn_backend,
|
|
NULL
|
|
};
|