mirror of
https://git.tartarus.org/simon/putty.git
synced 2025-01-09 17:38:00 +00:00
1d323d5c80
This server is NOT SECURE! If anyone is reading this commit message, DO NOT DEPLOY IT IN A HOSTILE-FACING ENVIRONMENT! Its purpose is to speak the server end of everything PuTTY speaks on the client side, so that I can test that I haven't broken PuTTY when I reorganise its code, even things like RSA key exchange or chained auth methods which it's hard to find a server that speaks at all. (For this reason, it's declared with [UT] in the Recipe file, so that it falls into the same category as programs like testbn, which won't be installed by 'make install'.) Working title is 'Uppity', partly for 'Universal PuTTY Protocol Interaction Test Yoke', but mostly because it looks quite like the word 'PuTTY' with part of it reversed. (Apparently 'test yoke' is a very rarely used term meaning something not altogether unlike 'test harness', which is a bit of a stretch, but it'll do.) It doesn't actually _support_ everything I want yet. At the moment, it's a proof of concept only. But it has most of the machinery present, and the parts it's missing - such as chained auth methods - should be easy enough to add because I've built in the required flexibility, in the form of an AuthPolicy object which can request them if it wants to. However, the current AuthPolicy object is entirely trivial, and will let in any user with the password "weasel". (Another way in which this is not a production-ready server is that it also has no interaction with the OS's authentication system. In particular, it will not only let in any user with the same password, but it won't even change uid - it will open shells and forwardings under whatever user id you started it up as.) Currently, the program can only speak the SSH protocol on its standard I/O channels (using the new FdSocket facility), so if you want it to listen on a network port, you'll have to run it from some kind of separate listening program similar to inetd. For my own tests, I'm not even doing that: I'm just having PuTTY spawn it as a local proxy process, which also conveniently eliminates the risk of anyone hostile connecting to it. The bulk of the actual code reorganisation is already done by previous commits, so this change is _mostly_ just dropping in a new set of server-specific source files alongside the client-specific ones I created recently. The remaining changes in the shared SSH code are numerous, but all minor: - a few extra parameters to BPP and PPL constructors (e.g. 'are you in server mode?'), and pass both sets of SSH-1 protocol flags from the login to the connection layer - in server mode, unconditionally send our version string _before_ waiting for the remote one - a new hook in the SSH-1 BPP to handle enabling compression in server mode, where the message exchange works the other way round - new code in the SSH-2 BPP to do _deferred_ compression the other way round (the non-deferred version is still nicely symmetric) - in the SSH-2 transport layer, some adjustments to do key derivation either way round (swapping round the identifying letters in the various hash preimages, and making sure to list the KEXINITs in the right order) - also in the SSH-2 transport layer, an if statement that controls whether we send SERVICE_REQUEST and wait for SERVICE_ACCEPT, or vice versa - new ConnectionLayer methods for opening outgoing channels for X and agent forwardings - new functions in portfwd.c to establish listening sockets suitable for remote-to-local port forwarding (i.e. not under the direction of a Conf the way it's done on the client side).
120 lines
3.8 KiB
C
120 lines
3.8 KiB
C
struct ssh1_channel;
|
|
|
|
struct outstanding_succfail;
|
|
|
|
struct ssh1_connection_state {
|
|
int crState;
|
|
|
|
Ssh *ssh;
|
|
|
|
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 */
|
|
|
|
int got_pty;
|
|
int ldisc_opts[LD_N_OPTIONS];
|
|
int stdout_throttling;
|
|
int want_user_input;
|
|
int session_terminated;
|
|
int term_width, term_height, term_width_orig, term_height_orig;
|
|
|
|
int X11_fwd_enabled;
|
|
struct X11Display *x11disp;
|
|
struct X11FakeAuth *x11auth;
|
|
tree234 *x11authtree;
|
|
|
|
int agent_fwd_enabled;
|
|
|
|
tree234 *rportfwds;
|
|
PortFwdManager *portfwdmgr;
|
|
int portfwdmgr_configured;
|
|
|
|
int 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;
|
|
|
|
int compressing; /* used in server mode only */
|
|
|
|
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. */
|
|
int 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.
|
|
*/
|
|
int pending_eof;
|
|
|
|
/*
|
|
* True if this channel is causing the underlying connection to be
|
|
* throttled.
|
|
*/
|
|
int 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.
|
|
*/
|
|
int 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);
|
|
int ssh1_handle_direction_specific_packet(
|
|
struct ssh1_connection_state *s, PktIn *pktin);
|
|
|
|
int ssh1_check_termination(struct ssh1_connection_state *s);
|