1
0
mirror of https://git.tartarus.org/simon/putty.git synced 2025-01-09 17:38:00 +00:00
putty-source/ssh1connection.h
Simon Tatham 22b492c4f6 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-22 18:42:13 +00:00

126 lines
4.0 KiB
C

struct ssh1_channel;
struct outstanding_succfail;
struct ssh1_connection_state {
int crState;
Conf *conf;
int local_protoflags, remote_protoflags;
tree234 *channels; /* indexed by local id */
/* In SSH-1, the main session doesn't take the form of a 'channel'
* according to the wire protocol. But we want to use the same API
* for it, so we define an SshChannel here - but one that uses a
* separate vtable from the usual one, so it doesn't map to a
* struct ssh1_channel as all the others do. */
SshChannel mainchan_sc;
Channel *mainchan_chan; /* the other end of mainchan_sc */
mainchan *mainchan; /* and its subtype */
bool got_pty;
bool ldisc_opts[LD_N_OPTIONS];
bool stdout_throttling;
bool want_user_input;
bool session_terminated;
int term_width, term_height, term_width_orig, term_height_orig;
bool X11_fwd_enabled;
struct X11Display *x11disp;
struct X11FakeAuth *x11auth;
tree234 *x11authtree;
bool agent_fwd_enabled;
tree234 *rportfwds;
PortFwdManager *portfwdmgr;
bool portfwdmgr_configured;
bool finished_setup;
/*
* These store the list of requests that we're waiting for
* SSH_SMSG_{SUCCESS,FAILURE} replies to. (Those messages don't
* come with any indication of what they're in response to, so we
* have to keep track of the queue ourselves.)
*/
struct outstanding_succfail *succfail_head, *succfail_tail;
bool compressing; /* used in server mode only */
bool sent_exit_status; /* also for server mode */
prompts_t *antispoof_prompt;
int antispoof_ret;
const SshServerConfig *ssc;
ConnectionLayer cl;
PacketProtocolLayer ppl;
};
struct ssh1_channel {
struct ssh1_connection_state *connlayer;
unsigned remoteid, localid;
int type;
/* True if we opened this channel but server hasn't confirmed. */
bool halfopen;
/* Bitmap of whether we've sent/received CHANNEL_CLOSE and
* CHANNEL_CLOSE_CONFIRMATION. */
#define CLOSES_SENT_CLOSE 1
#define CLOSES_SENT_CLOSECONF 2
#define CLOSES_RCVD_CLOSE 4
#define CLOSES_RCVD_CLOSECONF 8
int closes;
/*
* This flag indicates that an EOF is pending on the outgoing side
* of the channel: that is, wherever we're getting the data for
* this channel has sent us some data followed by EOF. We can't
* actually send the EOF until we've finished sending the data, so
* we set this flag instead to remind us to do so once our buffer
* is clear.
*/
bool pending_eof;
/*
* True if this channel is causing the underlying connection to be
* throttled.
*/
bool throttling_conn;
/*
* True if we currently have backed-up data on the direction of
* this channel pointing out of the SSH connection, and therefore
* would prefer the 'Channel' implementation not to read further
* local input if possible.
*/
bool throttled_by_backlog;
Channel *chan; /* handle the client side of this channel, if not */
SshChannel sc; /* entry point for chan to talk back to */
};
SshChannel *ssh1_session_open(ConnectionLayer *cl, Channel *chan);
void ssh1_channel_init(struct ssh1_channel *c);
void ssh1_channel_free(struct ssh1_channel *c);
struct ssh_rportfwd *ssh1_rportfwd_alloc(
ConnectionLayer *cl,
const char *shost, int sport, const char *dhost, int dport,
int addressfamily, const char *log_description, PortFwdRecord *pfr,
ssh_sharing_connstate *share_ctx);
SshChannel *ssh1_serverside_x11_open(
ConnectionLayer *cl, Channel *chan, const SocketPeerInfo *pi);
SshChannel *ssh1_serverside_agent_open(ConnectionLayer *cl, Channel *chan);
void ssh1_connection_direction_specific_setup(
struct ssh1_connection_state *s);
bool ssh1_handle_direction_specific_packet(
struct ssh1_connection_state *s, PktIn *pktin);
bool ssh1_check_termination(struct ssh1_connection_state *s);
bool ssh1_connection_need_antispoof_prompt(struct ssh1_connection_state *s);