putty/ssh1connection.h

115 строки
3.5 KiB
C
Исходник Обычный вид История

Move client-specific SSH code into new files. This is a major code reorganisation in preparation for making this code base into one that can build an SSH server as well as a client. (Mostly for purposes of using the server as a regression test suite for the client, though I have some other possible uses in mind too. However, it's currently no part of my plan to harden the server to the point where it can sensibly be deployed in a hostile environment.) In this preparatory commit, I've broken up the SSH-2 transport and connection layers, and the SSH-1 connection layer, into multiple source files, with each layer having its own header file containing the shared type definitions. In each case, the new source file contains code that's specific to the client side of the protocol, so that a new file can be swapped in in its place when building the server. Mostly this is just a straightforward moving of code without changing it very much, but there are a couple of actual changes in the process: The parsing of SSH-2 global-request and channel open-messages is now done by a new pair of functions in the client module. For channel opens, I've invented a new union data type to be the return value from that function, representing either failure (plus error message), success (plus Channel instance to manage the new channel), or an instruction to hand the channel over to a sharing downstream (plus a pointer to the downstream in question). Also, the tree234 of remote port forwardings in ssh2connection is now initialised on first use by the client-specific code, so that's where its compare function lives. The shared ssh2connection_free() still takes responsibility for freeing it, but now has to check if it's non-null first. The outer shell of the ssh2_lportfwd_open method, for making a local-to-remote port forwarding, is still centralised in ssh2connection.c, but the part of it that actually constructs the outgoing channel-open message has moved into the client code, because that will have to change depending on whether the channel-open has to have type direct-tcpip or forwarded-tcpip. In the SSH-1 connection layer, half the filter_queue method has moved out into the new client-specific code, but not all of it - bidirectional channel maintenance messages are still handled centrally. One exception is SSH_MSG_PORT_OPEN, which can be sent in both directions, but with subtly different semantics - from server to client, it's referring to a previously established remote forwarding (and must be rejected if there isn't one that matches it), but from client to server it's just a "direct-tcpip" request with no prior context. So that one is in the client-specific module, and when I add the server code it will have its own different handler.
2018-10-20 19:57:37 +03:00
struct ssh1_channel;
struct outstanding_succfail;
struct ssh1_connection_state {
int crState;
Ssh *ssh;
Conf *conf;
int local_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;
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);
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);