nhyatt/putty-source
1
0
Fork 0
mirror of https://git.tartarus.org/simon/putty.git synced 2025-01-09 17:38:00 +00:00
Code Issues Projects Releases Wiki Activity
5691805cbd
putty-source/portfwd.c

1174 lines
35 KiB
C
Raw Normal View History

Sprinkle some header comments in various files in an attempt to explain what they're for. [originally from svn r6639]
2006-04-23 18:26:03 +00:00
/*
* SSH port forwarding.
*/
Rewrite SOCKS client code using BinarySource. I've also replaced the entire SOCKS state machine whose states were barely-documented literal integers with one that uses an actual enum. I think the result is a great deal clearer. In the course of this rewrite I noticed that PuTTY's dynamic port forwarding had never got round to supporting the SOCKS5 IPv6 address format - though there was a FIXME comment saying it ought to. So now it does: if a SOCKS5 client provides a binary IPv6 address (which PuTTY's _own_ SOCKS5 client, in proxy.c, is quite capable of doing!), then that will be translated into the usual IPv6 hex literal representation to put in the "direct-tcpip" channel open request.
2018-05-30 21:36:20 +00:00
#include <assert.h>
Oops - actually check in portfwd.c itself! (Makefile also modified because it's been renamed to fit in 8.3, just in case.) [originally from svn r1177]
2001-08-08 20:53:27 +00:00
#include <stdio.h>
#include <stdlib.h>
#include "putty.h"
#include "ssh.h"
Replace enum+union of local channel types with a vtable. There's now an interface called 'Channel', which handles the local side of an SSH connection-layer channel, in terms of knowing where to send incoming channel data to, whether to close the channel, etc. Channel and the previous 'struct ssh_channel' mutually refer. The latter contains all the SSH-specific parts, and as much of the common logic as possible: in particular, Channel doesn't have to know anything about SSH packet formats, or which SSH protocol version is in use, or deal with all the fiddly stuff about window sizes - with the exception that x11fwd.c's implementation of it does have to be able to ask for a small fixed initial window size for the bodgy system that distinguishes upstream from downstream X forwardings. I've taken the opportunity to move the code implementing the detailed behaviour of agent forwarding out of ssh.c, now that all of it is on the far side of a uniform interface. (This also means that if I later implement agent forwarding directly to a Unix socket as an alternative, it'll be a matter of changing just the one call to agentf_new() that makes the Channel to plug into a forwarding.)
2018-09-12 14:03:47 +00:00
#include "sshchan.h"
Oops - actually check in portfwd.c itself! (Makefile also modified because it's been renamed to fit in 8.3, just in case.) [originally from svn r1177]
2001-08-08 20:53:27 +00:00
Rewrite SOCKS client code using BinarySource. I've also replaced the entire SOCKS state machine whose states were barely-documented literal integers with one that uses an actual enum. I think the result is a great deal clearer. In the course of this rewrite I noticed that PuTTY's dynamic port forwarding had never got round to supporting the SOCKS5 IPv6 address format - though there was a FIXME comment saying it ought to. So now it does: if a SOCKS5 client provides a binary IPv6 address (which PuTTY's _own_ SOCKS5 client, in proxy.c, is quite capable of doing!), then that will be translated into the usual IPv6 hex literal representation to put in the "direct-tcpip" channel open request.
2018-05-30 21:36:20 +00:00
/*
* Enumeration of values that live in the 'socks_state' field of
* struct PortForwarding.
*/
typedef enum {
SOCKS_NONE, /* direct connection (no SOCKS, or SOCKS already done) */
SOCKS_INITIAL, /* don't know if we're SOCKS 4 or 5 yet */
SOCKS_4, /* expect a SOCKS 4 (or 4A) connection message */
SOCKS_5_INITIAL, /* expect a SOCKS 5 preliminary message */
SOCKS_5_CONNECT /* expect a SOCKS 5 connection message */
} SocksState;
Replace enum+union of local channel types with a vtable. There's now an interface called 'Channel', which handles the local side of an SSH connection-layer channel, in terms of knowing where to send incoming channel data to, whether to close the channel, etc. Channel and the previous 'struct ssh_channel' mutually refer. The latter contains all the SSH-specific parts, and as much of the common logic as possible: in particular, Channel doesn't have to know anything about SSH packet formats, or which SSH protocol version is in use, or deal with all the fiddly stuff about window sizes - with the exception that x11fwd.c's implementation of it does have to be able to ask for a small fixed initial window size for the bodgy system that distinguishes upstream from downstream X forwardings. I've taken the opportunity to move the code implementing the detailed behaviour of agent forwarding out of ssh.c, now that all of it is on the far side of a uniform interface. (This also means that if I later implement agent forwarding directly to a Unix socket as an alternative, it'll be a matter of changing just the one call to agentf_new() that makes the Channel to plug into a forwarding.)
2018-09-12 14:03:47 +00:00
typedef struct PortForwarding {
New abstraction 'ConnectionLayer'. This is a vtable that wraps up all the functionality required from the SSH connection layer by associated modules like port forwarding and connection sharing. This extra layer of indirection adds nothing useful right now, but when I later separate the SSH-1 and SSH-2 connection layer implementations, it will be convenient for each one to be able to implement this vtable in terms of its own internal data structures. To simplify this vtable, I've moved a lot of the logging duties relating to connection sharing out of ssh.c into sshshare.c: now it handles nearly all the logging itself relating to setting up connection sharing in the first place and downstreams connecting and disconnecting. The only exception is the 'Reusing a shared connection' announcement in the console window, which is now done in ssh.c by detecting downstream status immediately after setup.
2018-09-17 11:14:00 +00:00
SshChannel *c; /* channel structure held by SSH connection layer */
ConnectionLayer *cl; /* the connection layer itself */
Pass the Ssh structure to portfwd.c with a tag. Again, safer than using a 'void *'.
2018-09-11 14:33:10 +00:00
/* Note that ssh need not be filled in if c is non-NULL */
Get rid of lots of implicit pointer types. All the main backend structures - Ssh, Telnet, Pty, Serial etc - now describe structure types themselves rather than pointers to them. The same goes for the codebase-wide trait types Socket and Plug, and the supporting types SockAddr and Pinger. All those things that were typedefed as pointers are older types; the newer ones have the explicit * at the point of use, because that's what I now seem to be preferring. But whichever one of those is better, inconsistently using a mixture of the two styles is worse, so let's make everything consistent. A few types are still implicitly pointers, such as Bignum and some of the GSSAPI types; generally this is either because they have to be void *, or because they're typedefed differently on different platforms and aren't always pointers at all. Can't be helped. But I've got rid of the main ones, at least.
2018-10-04 18:10:23 +00:00
Socket *s;
Replace enum+union of local channel types with a vtable. There's now an interface called 'Channel', which handles the local side of an SSH connection-layer channel, in terms of knowing where to send incoming channel data to, whether to close the channel, etc. Channel and the previous 'struct ssh_channel' mutually refer. The latter contains all the SSH-specific parts, and as much of the common logic as possible: in particular, Channel doesn't have to know anything about SSH packet formats, or which SSH protocol version is in use, or deal with all the fiddly stuff about window sizes - with the exception that x11fwd.c's implementation of it does have to be able to ask for a small fixed initial window size for the bodgy system that distinguishes upstream from downstream X forwardings. I've taken the opportunity to move the code implementing the detailed behaviour of agent forwarding out of ssh.c, now that all of it is on the far side of a uniform interface. (This also means that if I later implement agent forwarding directly to a Unix socket as an alternative, it'll be a matter of changing just the one call to agentf_new() that makes the Channel to plug into a forwarding.)
2018-09-12 14:03:47 +00:00
int input_wanted;
Oops - actually check in portfwd.c itself! (Makefile also modified because it's been renamed to fit in 8.3, just in case.) [originally from svn r1177]
2001-08-08 20:53:27 +00:00
int ready;
Rewrite SOCKS client code using BinarySource. I've also replaced the entire SOCKS state machine whose states were barely-documented literal integers with one that uses an actual enum. I think the result is a great deal clearer. In the course of this rewrite I noticed that PuTTY's dynamic port forwarding had never got round to supporting the SOCKS5 IPv6 address format - though there was a FIXME comment saying it ought to. So now it does: if a SOCKS5 client provides a binary IPv6 address (which PuTTY's _own_ SOCKS5 client, in proxy.c, is quite capable of doing!), then that will be translated into the usual IPv6 hex literal representation to put in the "direct-tcpip" channel open request.
2018-05-30 21:36:20 +00:00
SocksState socks_state;
Dynamic port forwarding by means of a local SOCKS server. Fully supports SOCKS 4, SOCKS 4A and SOCKS 5 (well, actually IPv6 in SOCKS 5 isn't supported, but it'll be no difficulty once I actually get round to it). Thanks to Chas Honton for his `stone soup' patch: I didn't end up actually using any of his code, but it galvanised me into doing it properly myself :-) [originally from svn r3055]
2003-04-05 11:45:21 +00:00
/*
* `hostname' and `port' are the real hostname and port, once
Get rid of the fixed-size 'hostname' buffer in every port-forwarded connection, and replace it with sensible dynamically allocated storage. While I'm at it, get rid of the disgusting dual use between storing an actual hostname and storing an incoming SOCKS request; we now have a separate pointer variable for each. [originally from svn r9903]
2013-07-11 17:23:56 +00:00
* we know what we're connecting to.
Dynamic port forwarding by means of a local SOCKS server. Fully supports SOCKS 4, SOCKS 4A and SOCKS 5 (well, actually IPv6 in SOCKS 5 isn't supported, but it'll be no difficulty once I actually get round to it). Thanks to Chas Honton for his `stone soup' patch: I didn't end up actually using any of his code, but it galvanised me into doing it properly myself :-) [originally from svn r3055]
2003-04-05 11:45:21 +00:00
*/
Get rid of the fixed-size 'hostname' buffer in every port-forwarded connection, and replace it with sensible dynamically allocated storage. While I'm at it, get rid of the disgusting dual use between storing an actual hostname and storing an incoming SOCKS request; we now have a separate pointer variable for each. [originally from svn r9903]
2013-07-11 17:23:56 +00:00
char *hostname;
Dynamic port forwarding by means of a local SOCKS server. Fully supports SOCKS 4, SOCKS 4A and SOCKS 5 (well, actually IPv6 in SOCKS 5 isn't supported, but it'll be no difficulty once I actually get round to it). Thanks to Chas Honton for his `stone soup' patch: I didn't end up actually using any of his code, but it galvanised me into doing it properly myself :-) [originally from svn r3055]
2003-04-05 11:45:21 +00:00
int port;
Get rid of the fixed-size 'hostname' buffer in every port-forwarded connection, and replace it with sensible dynamically allocated storage. While I'm at it, get rid of the disgusting dual use between storing an actual hostname and storing an incoming SOCKS request; we now have a separate pointer variable for each. [originally from svn r9903]
2013-07-11 17:23:56 +00:00
/*
Rewrite SOCKS client code using BinarySource. I've also replaced the entire SOCKS state machine whose states were barely-documented literal integers with one that uses an actual enum. I think the result is a great deal clearer. In the course of this rewrite I noticed that PuTTY's dynamic port forwarding had never got round to supporting the SOCKS5 IPv6 address format - though there was a FIXME comment saying it ought to. So now it does: if a SOCKS5 client provides a binary IPv6 address (which PuTTY's _own_ SOCKS5 client, in proxy.c, is quite capable of doing!), then that will be translated into the usual IPv6 hex literal representation to put in the "direct-tcpip" channel open request.
2018-05-30 21:36:20 +00:00
* `socksbuf' is the buffer we use to accumulate the initial SOCKS
* segment of the incoming data, plus anything after that that we
* receive before we're ready to send data to the SSH server.
Get rid of the fixed-size 'hostname' buffer in every port-forwarded connection, and replace it with sensible dynamically allocated storage. While I'm at it, get rid of the disgusting dual use between storing an actual hostname and storing an incoming SOCKS request; we now have a separate pointer variable for each. [originally from svn r9903]
2013-07-11 17:23:56 +00:00
*/
Rewrite SOCKS client code using BinarySource. I've also replaced the entire SOCKS state machine whose states were barely-documented literal integers with one that uses an actual enum. I think the result is a great deal clearer. In the course of this rewrite I noticed that PuTTY's dynamic port forwarding had never got round to supporting the SOCKS5 IPv6 address format - though there was a FIXME comment saying it ought to. So now it does: if a SOCKS5 client provides a binary IPv6 address (which PuTTY's _own_ SOCKS5 client, in proxy.c, is quite capable of doing!), then that will be translated into the usual IPv6 hex literal representation to put in the "direct-tcpip" channel open request.
2018-05-30 21:36:20 +00:00
strbuf *socksbuf;
size_t socksbuf_consumed;
Modernise the Socket/Plug vtable system. Now I've got FROMFIELD, I can rework it so that structures providing an implementation of the Socket or Plug trait no longer have to have the vtable pointer as the very first thing in the structure. In particular, this means that the ProxySocket structure can now directly implement _both_ the Socket and Plug traits, which is always _logically_ how it's worked, but previously it had to be implemented via two separate structs linked to each other.
2018-05-27 08:29:33 +00:00
Make Socket and Plug into structs. I think that means that _every_ one of my traitoids is now a struct containing a vtable pointer as one of its fields (albeit sometimes the only field), and never just a bare pointer.
2018-10-05 06:24:16 +00:00
Plug plug;
Replace enum+union of local channel types with a vtable. There's now an interface called 'Channel', which handles the local side of an SSH connection-layer channel, in terms of knowing where to send incoming channel data to, whether to close the channel, etc. Channel and the previous 'struct ssh_channel' mutually refer. The latter contains all the SSH-specific parts, and as much of the common logic as possible: in particular, Channel doesn't have to know anything about SSH packet formats, or which SSH protocol version is in use, or deal with all the fiddly stuff about window sizes - with the exception that x11fwd.c's implementation of it does have to be able to ask for a small fixed initial window size for the bodgy system that distinguishes upstream from downstream X forwardings. I've taken the opportunity to move the code implementing the detailed behaviour of agent forwarding out of ssh.c, now that all of it is on the far side of a uniform interface. (This also means that if I later implement agent forwarding directly to a Unix socket as an alternative, it'll be a matter of changing just the one call to agentf_new() that makes the Channel to plug into a forwarding.)
2018-09-12 14:03:47 +00:00
Channel chan;
} PortForwarding;
Oops - actually check in portfwd.c itself! (Makefile also modified because it's been renamed to fit in 8.3, just in case.) [originally from svn r1177]
2001-08-08 20:53:27 +00:00
Refactor ssh.c's APIs to x11fwd.c and portfwd.c. The most important change is that, where previously ssh.c held the Socket pointer for each X11 and port forwarding, and the support modules would find their internal state structure by calling sk_get_private_ptr on that Socket, it's now the other way round. ssh.c now directly holds the internal state structure pointer for each forwarding, and when the support module needs the Socket it looks it up in a field of that. This will come in handy when I decouple socket creation from logical forwarding setup, so that X forwardings can delay actually opening a connection to an X server until they look at the authentication data and see which server it has to be. However, while I'm here, I've also taken the opportunity to clean up a few other points, notably error message handling, and also the fact that the same kind of state structure was used for both connection-type and listening-type port forwardings. Now there are separate PortForwarding and PortListener structure types, which seems far more sensible. [originally from svn r10074]
2013-11-17 14:04:41 +00:00
struct PortListener {
New abstraction 'ConnectionLayer'. This is a vtable that wraps up all the functionality required from the SSH connection layer by associated modules like port forwarding and connection sharing. This extra layer of indirection adds nothing useful right now, but when I later separate the SSH-1 and SSH-2 connection layer implementations, it will be convenient for each one to be able to implement this vtable in terms of its own internal data structures. To simplify this vtable, I've moved a lot of the logging duties relating to connection sharing out of ssh.c into sshshare.c: now it handles nearly all the logging itself relating to setting up connection sharing in the first place and downstreams connecting and disconnecting. The only exception is the 'Reusing a shared connection' announcement in the console window, which is now done in ssh.c by detecting downstream status immediately after setup.
2018-09-17 11:14:00 +00:00
ConnectionLayer *cl;
Get rid of lots of implicit pointer types. All the main backend structures - Ssh, Telnet, Pty, Serial etc - now describe structure types themselves rather than pointers to them. The same goes for the codebase-wide trait types Socket and Plug, and the supporting types SockAddr and Pinger. All those things that were typedefed as pointers are older types; the newer ones have the explicit * at the point of use, because that's what I now seem to be preferring. But whichever one of those is better, inconsistently using a mixture of the two styles is worse, so let's make everything consistent. A few types are still implicitly pointers, such as Bignum and some of the GSSAPI types; generally this is either because they have to be void *, or because they're typedefed differently on different platforms and aren't always pointers at all. Can't be helped. But I've got rid of the main ones, at least.
2018-10-04 18:10:23 +00:00
Socket *s;
Rewrite SOCKS client code using BinarySource. I've also replaced the entire SOCKS state machine whose states were barely-documented literal integers with one that uses an actual enum. I think the result is a great deal clearer. In the course of this rewrite I noticed that PuTTY's dynamic port forwarding had never got round to supporting the SOCKS5 IPv6 address format - though there was a FIXME comment saying it ought to. So now it does: if a SOCKS5 client provides a binary IPv6 address (which PuTTY's _own_ SOCKS5 client, in proxy.c, is quite capable of doing!), then that will be translated into the usual IPv6 hex literal representation to put in the "direct-tcpip" channel open request.
2018-05-30 21:36:20 +00:00
int is_dynamic;
Refactor ssh.c's APIs to x11fwd.c and portfwd.c. The most important change is that, where previously ssh.c held the Socket pointer for each X11 and port forwarding, and the support modules would find their internal state structure by calling sk_get_private_ptr on that Socket, it's now the other way round. ssh.c now directly holds the internal state structure pointer for each forwarding, and when the support module needs the Socket it looks it up in a field of that. This will come in handy when I decouple socket creation from logical forwarding setup, so that X forwardings can delay actually opening a connection to an X server until they look at the authentication data and see which server it has to be. However, while I'm here, I've also taken the opportunity to clean up a few other points, notably error message handling, and also the fact that the same kind of state structure was used for both connection-type and listening-type port forwardings. Now there are separate PortForwarding and PortListener structure types, which seems far more sensible. [originally from svn r10074]
2013-11-17 14:04:41 +00:00
/*
* `hostname' and `port' are the real hostname and port, for
* ordinary forwardings.
*/
char *hostname;
int port;
Modernise the Socket/Plug vtable system. Now I've got FROMFIELD, I can rework it so that structures providing an implementation of the Socket or Plug trait no longer have to have the vtable pointer as the very first thing in the structure. In particular, this means that the ProxySocket structure can now directly implement _both_ the Socket and Plug traits, which is always _logically_ how it's worked, but previously it had to be implemented via two separate structs linked to each other.
2018-05-27 08:29:33 +00:00
Make Socket and Plug into structs. I think that means that _every_ one of my traitoids is now a struct containing a vtable pointer as one of its fields (albeit sometimes the only field), and never just a bare pointer.
2018-10-05 06:24:16 +00:00
Plug plug;
Refactor ssh.c's APIs to x11fwd.c and portfwd.c. The most important change is that, where previously ssh.c held the Socket pointer for each X11 and port forwarding, and the support modules would find their internal state structure by calling sk_get_private_ptr on that Socket, it's now the other way round. ssh.c now directly holds the internal state structure pointer for each forwarding, and when the support module needs the Socket it looks it up in a field of that. This will come in handy when I decouple socket creation from logical forwarding setup, so that X forwardings can delay actually opening a connection to an X server until they look at the authentication data and see which server it has to be. However, while I'm here, I've also taken the opportunity to clean up a few other points, notably error message handling, and also the fact that the same kind of state structure was used for both connection-type and listening-type port forwardings. Now there are separate PortForwarding and PortListener structure types, which seems far more sensible. [originally from svn r10074]
2013-11-17 14:04:41 +00:00
};
static struct PortForwarding *new_portfwd_state(void)
Get rid of the fixed-size 'hostname' buffer in every port-forwarded connection, and replace it with sensible dynamically allocated storage. While I'm at it, get rid of the disgusting dual use between storing an actual hostname and storing an incoming SOCKS request; we now have a separate pointer variable for each. [originally from svn r9903]
2013-07-11 17:23:56 +00:00
{
Refactor ssh.c's APIs to x11fwd.c and portfwd.c. The most important change is that, where previously ssh.c held the Socket pointer for each X11 and port forwarding, and the support modules would find their internal state structure by calling sk_get_private_ptr on that Socket, it's now the other way round. ssh.c now directly holds the internal state structure pointer for each forwarding, and when the support module needs the Socket it looks it up in a field of that. This will come in handy when I decouple socket creation from logical forwarding setup, so that X forwardings can delay actually opening a connection to an X server until they look at the authentication data and see which server it has to be. However, while I'm here, I've also taken the opportunity to clean up a few other points, notably error message handling, and also the fact that the same kind of state structure was used for both connection-type and listening-type port forwardings. Now there are separate PortForwarding and PortListener structure types, which seems far more sensible. [originally from svn r10074]
2013-11-17 14:04:41 +00:00
struct PortForwarding *pf = snew(struct PortForwarding);
pf->hostname = NULL;
pf->socksbuf = NULL;
return pf;
Get rid of the fixed-size 'hostname' buffer in every port-forwarded connection, and replace it with sensible dynamically allocated storage. While I'm at it, get rid of the disgusting dual use between storing an actual hostname and storing an incoming SOCKS request; we now have a separate pointer variable for each. [originally from svn r9903]
2013-07-11 17:23:56 +00:00
}
Refactor ssh.c's APIs to x11fwd.c and portfwd.c. The most important change is that, where previously ssh.c held the Socket pointer for each X11 and port forwarding, and the support modules would find their internal state structure by calling sk_get_private_ptr on that Socket, it's now the other way round. ssh.c now directly holds the internal state structure pointer for each forwarding, and when the support module needs the Socket it looks it up in a field of that. This will come in handy when I decouple socket creation from logical forwarding setup, so that X forwardings can delay actually opening a connection to an X server until they look at the authentication data and see which server it has to be. However, while I'm here, I've also taken the opportunity to clean up a few other points, notably error message handling, and also the fact that the same kind of state structure was used for both connection-type and listening-type port forwardings. Now there are separate PortForwarding and PortListener structure types, which seems far more sensible. [originally from svn r10074]
2013-11-17 14:04:41 +00:00
static void free_portfwd_state(struct PortForwarding *pf)
Get rid of the fixed-size 'hostname' buffer in every port-forwarded connection, and replace it with sensible dynamically allocated storage. While I'm at it, get rid of the disgusting dual use between storing an actual hostname and storing an incoming SOCKS request; we now have a separate pointer variable for each. [originally from svn r9903]
2013-07-11 17:23:56 +00:00
{
Refactor ssh.c's APIs to x11fwd.c and portfwd.c. The most important change is that, where previously ssh.c held the Socket pointer for each X11 and port forwarding, and the support modules would find their internal state structure by calling sk_get_private_ptr on that Socket, it's now the other way round. ssh.c now directly holds the internal state structure pointer for each forwarding, and when the support module needs the Socket it looks it up in a field of that. This will come in handy when I decouple socket creation from logical forwarding setup, so that X forwardings can delay actually opening a connection to an X server until they look at the authentication data and see which server it has to be. However, while I'm here, I've also taken the opportunity to clean up a few other points, notably error message handling, and also the fact that the same kind of state structure was used for both connection-type and listening-type port forwardings. Now there are separate PortForwarding and PortListener structure types, which seems far more sensible. [originally from svn r10074]
2013-11-17 14:04:41 +00:00
if (!pf)
Get rid of the fixed-size 'hostname' buffer in every port-forwarded connection, and replace it with sensible dynamically allocated storage. While I'm at it, get rid of the disgusting dual use between storing an actual hostname and storing an incoming SOCKS request; we now have a separate pointer variable for each. [originally from svn r9903]
2013-07-11 17:23:56 +00:00
return;
Refactor ssh.c's APIs to x11fwd.c and portfwd.c. The most important change is that, where previously ssh.c held the Socket pointer for each X11 and port forwarding, and the support modules would find their internal state structure by calling sk_get_private_ptr on that Socket, it's now the other way round. ssh.c now directly holds the internal state structure pointer for each forwarding, and when the support module needs the Socket it looks it up in a field of that. This will come in handy when I decouple socket creation from logical forwarding setup, so that X forwardings can delay actually opening a connection to an X server until they look at the authentication data and see which server it has to be. However, while I'm here, I've also taken the opportunity to clean up a few other points, notably error message handling, and also the fact that the same kind of state structure was used for both connection-type and listening-type port forwardings. Now there are separate PortForwarding and PortListener structure types, which seems far more sensible. [originally from svn r10074]
2013-11-17 14:04:41 +00:00
sfree(pf->hostname);
Rewrite SOCKS client code using BinarySource. I've also replaced the entire SOCKS state machine whose states were barely-documented literal integers with one that uses an actual enum. I think the result is a great deal clearer. In the course of this rewrite I noticed that PuTTY's dynamic port forwarding had never got round to supporting the SOCKS5 IPv6 address format - though there was a FIXME comment saying it ought to. So now it does: if a SOCKS5 client provides a binary IPv6 address (which PuTTY's _own_ SOCKS5 client, in proxy.c, is quite capable of doing!), then that will be translated into the usual IPv6 hex literal representation to put in the "direct-tcpip" channel open request.
2018-05-30 21:36:20 +00:00
if (pf->socksbuf)
strbuf_free(pf->socksbuf);
Refactor ssh.c's APIs to x11fwd.c and portfwd.c. The most important change is that, where previously ssh.c held the Socket pointer for each X11 and port forwarding, and the support modules would find their internal state structure by calling sk_get_private_ptr on that Socket, it's now the other way round. ssh.c now directly holds the internal state structure pointer for each forwarding, and when the support module needs the Socket it looks it up in a field of that. This will come in handy when I decouple socket creation from logical forwarding setup, so that X forwardings can delay actually opening a connection to an X server until they look at the authentication data and see which server it has to be. However, while I'm here, I've also taken the opportunity to clean up a few other points, notably error message handling, and also the fact that the same kind of state structure was used for both connection-type and listening-type port forwardings. Now there are separate PortForwarding and PortListener structure types, which seems far more sensible. [originally from svn r10074]
2013-11-17 14:04:41 +00:00
sfree(pf);
}
static struct PortListener *new_portlistener_state(void)
{
struct PortListener *pl = snew(struct PortListener);
pl->hostname = NULL;
return pl;
}
static void free_portlistener_state(struct PortListener *pl)
{
if (!pl)
return;
sfree(pl->hostname);
sfree(pl);
Get rid of the fixed-size 'hostname' buffer in every port-forwarded connection, and replace it with sensible dynamically allocated storage. While I'm at it, get rid of the disgusting dual use between storing an actual hostname and storing an incoming SOCKS request; we now have a separate pointer variable for each. [originally from svn r9903]
2013-07-11 17:23:56 +00:00
}
Get rid of lots of implicit pointer types. All the main backend structures - Ssh, Telnet, Pty, Serial etc - now describe structure types themselves rather than pointers to them. The same goes for the codebase-wide trait types Socket and Plug, and the supporting types SockAddr and Pinger. All those things that were typedefed as pointers are older types; the newer ones have the explicit * at the point of use, because that's what I now seem to be preferring. But whichever one of those is better, inconsistently using a mixture of the two styles is worse, so let's make everything consistent. A few types are still implicitly pointers, such as Bignum and some of the GSSAPI types; generally this is either because they have to be void *, or because they're typedefed differently on different platforms and aren't always pointers at all. Can't be helped. But I've got rid of the main ones, at least.
2018-10-04 18:10:23 +00:00
static void pfd_log(Plug *plug, int type, SockAddr *addr, int port,
Support for falling back through the list of addresses returned from a DNS lookup, whether they're IPv4, v6 or a mixture of both. [originally from svn r5119] [this svn revision also touched putty-wishlist]
2005-01-16 14:29:34 +00:00
const char *error_msg, int error_code)
{
/* we have to dump these since we have no interface to logging.c */
}
Get rid of lots of implicit pointer types. All the main backend structures - Ssh, Telnet, Pty, Serial etc - now describe structure types themselves rather than pointers to them. The same goes for the codebase-wide trait types Socket and Plug, and the supporting types SockAddr and Pinger. All those things that were typedefed as pointers are older types; the newer ones have the explicit * at the point of use, because that's what I now seem to be preferring. But whichever one of those is better, inconsistently using a mixture of the two styles is worse, so let's make everything consistent. A few types are still implicitly pointers, such as Bignum and some of the GSSAPI types; generally this is either because they have to be void *, or because they're typedefed differently on different platforms and aren't always pointers at all. Can't be helped. But I've got rid of the main ones, at least.
2018-10-04 18:10:23 +00:00
static void pfl_log(Plug *plug, int type, SockAddr *addr, int port,
Refactor ssh.c's APIs to x11fwd.c and portfwd.c. The most important change is that, where previously ssh.c held the Socket pointer for each X11 and port forwarding, and the support modules would find their internal state structure by calling sk_get_private_ptr on that Socket, it's now the other way round. ssh.c now directly holds the internal state structure pointer for each forwarding, and when the support module needs the Socket it looks it up in a field of that. This will come in handy when I decouple socket creation from logical forwarding setup, so that X forwardings can delay actually opening a connection to an X server until they look at the authentication data and see which server it has to be. However, while I'm here, I've also taken the opportunity to clean up a few other points, notably error message handling, and also the fact that the same kind of state structure was used for both connection-type and listening-type port forwardings. Now there are separate PortForwarding and PortListener structure types, which seems far more sensible. [originally from svn r10074]
2013-11-17 14:04:41 +00:00
const char *error_msg, int error_code)
{
/* we have to dump these since we have no interface to logging.c */
}
Replace enum+union of local channel types with a vtable. There's now an interface called 'Channel', which handles the local side of an SSH connection-layer channel, in terms of knowing where to send incoming channel data to, whether to close the channel, etc. Channel and the previous 'struct ssh_channel' mutually refer. The latter contains all the SSH-specific parts, and as much of the common logic as possible: in particular, Channel doesn't have to know anything about SSH packet formats, or which SSH protocol version is in use, or deal with all the fiddly stuff about window sizes - with the exception that x11fwd.c's implementation of it does have to be able to ask for a small fixed initial window size for the bodgy system that distinguishes upstream from downstream X forwardings. I've taken the opportunity to move the code implementing the detailed behaviour of agent forwarding out of ssh.c, now that all of it is on the far side of a uniform interface. (This also means that if I later implement agent forwarding directly to a Unix socket as an alternative, it'll be a matter of changing just the one call to agentf_new() that makes the Channel to plug into a forwarding.)
2018-09-12 14:03:47 +00:00
static void pfd_close(struct PortForwarding *pf);
Get rid of lots of implicit pointer types. All the main backend structures - Ssh, Telnet, Pty, Serial etc - now describe structure types themselves rather than pointers to them. The same goes for the codebase-wide trait types Socket and Plug, and the supporting types SockAddr and Pinger. All those things that were typedefed as pointers are older types; the newer ones have the explicit * at the point of use, because that's what I now seem to be preferring. But whichever one of those is better, inconsistently using a mixture of the two styles is worse, so let's make everything consistent. A few types are still implicitly pointers, such as Bignum and some of the GSSAPI types; generally this is either because they have to be void *, or because they're typedefed differently on different platforms and aren't always pointers at all. Can't be helped. But I've got rid of the main ones, at least.
2018-10-04 18:10:23 +00:00
static void pfd_closing(Plug *plug, const char *error_msg, int error_code,
Make plug receive and closing functions return void instead of int. Nothing was paying attention to their return values any more anyway.
2016-06-02 22:03:24 +00:00
int calling_back)
Oops - actually check in portfwd.c itself! (Makefile also modified because it's been renamed to fit in 8.3, just in case.) [originally from svn r1177]
2001-08-08 20:53:27 +00:00
{
Rename FROMFIELD to 'container_of'. Ian Jackson points out that the Linux kernel has a macro of this name with the same purpose, and suggests that it's a good idea to use the same name as they do, so that at least some people reading one code base might recognise it from the other. I never really thought very hard about what order FROMFIELD's parameters should go in, and therefore I'm pleasantly surprised to find that my order agrees with the kernel's, so I don't have to permute every call site as part of making this change :-)
2018-10-05 22:49:08 +00:00
struct PortForwarding *pf =
container_of(plug, struct PortForwarding, plug);
Oops - actually check in portfwd.c itself! (Makefile also modified because it's been renamed to fit in 8.3, just in case.) [originally from svn r1177]
2001-08-08 20:53:27 +00:00
Introduce a function sshfwd_unclean_close(), supplied by ssh.c to subsidiary network modules like portfwd.c. To be called when the subsidiary module experiences a socket error: it sends an emergency CHANNEL_CLOSE (not just outgoing CHANNEL_EOF), and immediately deletes the local side of the channel. (I've invented a new channel type in ssh.c called CHAN_ZOMBIE, for channels whose original local side has already been thrown away and they're just hanging around waiting to receive the acknowledging CHANNEL_CLOSE.) As a result of this and the last few commits, I can now run a port forwarding session in which a local socket error occurs on a forwarded port, and PuTTY now handles it apparently correctly, closing both the SSH channel and the local socket and then actually recognising that it's OK to terminate when all _other_ channels have been closed. Previously the channel corresponding to the duff connection would linger around (because of net_pending_errors never being called), and keep being selected on (hence chewing CPU), and inhibit program termination at the end of the session (because not all channels were closed). [originally from svn r9364]
2011-12-08 19:15:58 +00:00
if (error_msg) {
/*
* Socket error. Slam the connection instantly shut.
*/
Refactor ssh.c's APIs to x11fwd.c and portfwd.c. The most important change is that, where previously ssh.c held the Socket pointer for each X11 and port forwarding, and the support modules would find their internal state structure by calling sk_get_private_ptr on that Socket, it's now the other way round. ssh.c now directly holds the internal state structure pointer for each forwarding, and when the support module needs the Socket it looks it up in a field of that. This will come in handy when I decouple socket creation from logical forwarding setup, so that X forwardings can delay actually opening a connection to an X server until they look at the authentication data and see which server it has to be. However, while I'm here, I've also taken the opportunity to clean up a few other points, notably error message handling, and also the fact that the same kind of state structure was used for both connection-type and listening-type port forwardings. Now there are separate PortForwarding and PortListener structure types, which seems far more sensible. [originally from svn r10074]
2013-11-17 14:04:41 +00:00
if (pf->c) {
Rename sshfwd_unclean_close to sshfwd_initiate_close. Turns out that initiation of a CHANNEL_CLOSE message before both sides have sent EOF is not only for _unclean_ closures or emergencies; it's actually a perfectly normal thing that some channel types want to do. (For example, a channel with a pty at the server end of it has no real concept of sending EOF independently in both directions: when the pty master sends EIO, the pty is no longer functioning, and you can no longer send to it any more than you can receive.)
2018-10-13 09:30:03 +00:00
sshfwd_initiate_close(pf->c, error_msg);
Sebastian Kuschel reports that pfd_closing can be called for a socket error with pr->c NULL, in which case calling sshfwd_unclean_close on it will dereference NULL and segfault. Write an alternative error handling path for that possibility. (I don't know if it's the only way, but one way this can happen is if you're doing dynamic forwarding and the socket error occurs during SOCKS negotiation, in which case no SSH channel has been set up yet because we haven't yet found out what we want to put in the direct-tcpip channel open message.) [originally from svn r10018]
2013-08-15 06:42:36 +00:00
} else {
/*
* We might not have an SSH channel, if a socket error
* occurred during SOCKS negotiation. If not, we must
Rename sshfwd_unclean_close to sshfwd_initiate_close. Turns out that initiation of a CHANNEL_CLOSE message before both sides have sent EOF is not only for _unclean_ closures or emergencies; it's actually a perfectly normal thing that some channel types want to do. (For example, a channel with a pty at the server end of it has no real concept of sending EOF independently in both directions: when the pty master sends EIO, the pty is no longer functioning, and you can no longer send to it any more than you can receive.)
2018-10-13 09:30:03 +00:00
* clean ourself up without sshfwd_initiate_close's call
Sebastian Kuschel reports that pfd_closing can be called for a socket error with pr->c NULL, in which case calling sshfwd_unclean_close on it will dereference NULL and segfault. Write an alternative error handling path for that possibility. (I don't know if it's the only way, but one way this can happen is if you're doing dynamic forwarding and the socket error occurs during SOCKS negotiation, in which case no SSH channel has been set up yet because we haven't yet found out what we want to put in the direct-tcpip channel open message.) [originally from svn r10018]
2013-08-15 06:42:36 +00:00
* back to pfd_close.
*/
Refactor ssh.c's APIs to x11fwd.c and portfwd.c. The most important change is that, where previously ssh.c held the Socket pointer for each X11 and port forwarding, and the support modules would find their internal state structure by calling sk_get_private_ptr on that Socket, it's now the other way round. ssh.c now directly holds the internal state structure pointer for each forwarding, and when the support module needs the Socket it looks it up in a field of that. This will come in handy when I decouple socket creation from logical forwarding setup, so that X forwardings can delay actually opening a connection to an X server until they look at the authentication data and see which server it has to be. However, while I'm here, I've also taken the opportunity to clean up a few other points, notably error message handling, and also the fact that the same kind of state structure was used for both connection-type and listening-type port forwardings. Now there are separate PortForwarding and PortListener structure types, which seems far more sensible. [originally from svn r10074]
2013-11-17 14:04:41 +00:00
pfd_close(pf);
Sebastian Kuschel reports that pfd_closing can be called for a socket error with pr->c NULL, in which case calling sshfwd_unclean_close on it will dereference NULL and segfault. Write an alternative error handling path for that possibility. (I don't know if it's the only way, but one way this can happen is if you're doing dynamic forwarding and the socket error occurs during SOCKS negotiation, in which case no SSH channel has been set up yet because we haven't yet found out what we want to put in the direct-tcpip channel open message.) [originally from svn r10018]
2013-08-15 06:42:36 +00:00
}
Introduce a function sshfwd_unclean_close(), supplied by ssh.c to subsidiary network modules like portfwd.c. To be called when the subsidiary module experiences a socket error: it sends an emergency CHANNEL_CLOSE (not just outgoing CHANNEL_EOF), and immediately deletes the local side of the channel. (I've invented a new channel type in ssh.c called CHAN_ZOMBIE, for channels whose original local side has already been thrown away and they're just hanging around waiting to receive the acknowledging CHANNEL_CLOSE.) As a result of this and the last few commits, I can now run a port forwarding session in which a local socket error occurs on a forwarded port, and PuTTY now handles it apparently correctly, closing both the SSH channel and the local socket and then actually recognising that it's OK to terminate when all _other_ channels have been closed. Previously the channel corresponding to the duff connection would linger around (because of net_pending_errors never being called), and keep being selected on (hence chewing CPU), and inhibit program termination at the end of the session (because not all channels were closed). [originally from svn r9364]
2011-12-08 19:15:58 +00:00
} else {
/*
* Ordinary EOF received on socket. Send an EOF on the SSH
* channel.
*/
Refactor ssh.c's APIs to x11fwd.c and portfwd.c. The most important change is that, where previously ssh.c held the Socket pointer for each X11 and port forwarding, and the support modules would find their internal state structure by calling sk_get_private_ptr on that Socket, it's now the other way round. ssh.c now directly holds the internal state structure pointer for each forwarding, and when the support module needs the Socket it looks it up in a field of that. This will come in handy when I decouple socket creation from logical forwarding setup, so that X forwardings can delay actually opening a connection to an X server until they look at the authentication data and see which server it has to be. However, while I'm here, I've also taken the opportunity to clean up a few other points, notably error message handling, and also the fact that the same kind of state structure was used for both connection-type and listening-type port forwardings. Now there are separate PortForwarding and PortListener structure types, which seems far more sensible. [originally from svn r10074]
2013-11-17 14:04:41 +00:00
if (pf->c)
sshfwd_write_eof(pf->c);
Introduce a function sshfwd_unclean_close(), supplied by ssh.c to subsidiary network modules like portfwd.c. To be called when the subsidiary module experiences a socket error: it sends an emergency CHANNEL_CLOSE (not just outgoing CHANNEL_EOF), and immediately deletes the local side of the channel. (I've invented a new channel type in ssh.c called CHAN_ZOMBIE, for channels whose original local side has already been thrown away and they're just hanging around waiting to receive the acknowledging CHANNEL_CLOSE.) As a result of this and the last few commits, I can now run a port forwarding session in which a local socket error occurs on a forwarded port, and PuTTY now handles it apparently correctly, closing both the SSH channel and the local socket and then actually recognising that it's OK to terminate when all _other_ channels have been closed. Previously the channel corresponding to the duff connection would linger around (because of net_pending_errors never being called), and keep being selected on (hence chewing CPU), and inhibit program termination at the end of the session (because not all channels were closed). [originally from svn r9364]
2011-12-08 19:15:58 +00:00
}
Oops - actually check in portfwd.c itself! (Makefile also modified because it's been renamed to fit in 8.3, just in case.) [originally from svn r1177]
2001-08-08 20:53:27 +00:00
}
Move port-forwarding setup out of ssh.c. The tree234 storing currently active port forwardings - both local and remote - now lives in portfwd.c, as does the complicated function that updates it based on a Conf listing the new set of desired forwardings. Local port forwardings are passed to ssh.c via the same route as before - once the listening port receives a connection and portfwd.c knows where it should be directed to (in particular, after the SOCKS exchange, if any), it calls ssh_send_port_open. Remote forwardings are now initiated by calling ssh_rportfwd_alloc, which adds an entry to the rportfwds tree (which _is_ still in ssh.c, and still confusingly sorted by a different criterion depending on SSH protocol version) and sends out the appropriate protocol request. ssh_rportfwd_remove cancels one again, sending a protocol request too. Those functions look enough like ssh_{alloc,remove}_sharing_rportfwd that I've merged those into the new pair as well - now allocating an rportfwd allows you to specify either a destination host/port or a sharing context, and returns a handy pointer you can use to cancel the forwarding later.
2018-09-14 16:04:39 +00:00
static void pfl_terminate(struct PortListener *pl);
Get rid of lots of implicit pointer types. All the main backend structures - Ssh, Telnet, Pty, Serial etc - now describe structure types themselves rather than pointers to them. The same goes for the codebase-wide trait types Socket and Plug, and the supporting types SockAddr and Pinger. All those things that were typedefed as pointers are older types; the newer ones have the explicit * at the point of use, because that's what I now seem to be preferring. But whichever one of those is better, inconsistently using a mixture of the two styles is worse, so let's make everything consistent. A few types are still implicitly pointers, such as Bignum and some of the GSSAPI types; generally this is either because they have to be void *, or because they're typedefed differently on different platforms and aren't always pointers at all. Can't be helped. But I've got rid of the main ones, at least.
2018-10-04 18:10:23 +00:00
static void pfl_closing(Plug *plug, const char *error_msg, int error_code,
Make plug receive and closing functions return void instead of int. Nothing was paying attention to their return values any more anyway.
2016-06-02 22:03:24 +00:00
int calling_back)
Refactor ssh.c's APIs to x11fwd.c and portfwd.c. The most important change is that, where previously ssh.c held the Socket pointer for each X11 and port forwarding, and the support modules would find their internal state structure by calling sk_get_private_ptr on that Socket, it's now the other way round. ssh.c now directly holds the internal state structure pointer for each forwarding, and when the support module needs the Socket it looks it up in a field of that. This will come in handy when I decouple socket creation from logical forwarding setup, so that X forwardings can delay actually opening a connection to an X server until they look at the authentication data and see which server it has to be. However, while I'm here, I've also taken the opportunity to clean up a few other points, notably error message handling, and also the fact that the same kind of state structure was used for both connection-type and listening-type port forwardings. Now there are separate PortForwarding and PortListener structure types, which seems far more sensible. [originally from svn r10074]
2013-11-17 14:04:41 +00:00
{
struct PortListener *pl = (struct PortListener *) plug;
pfl_terminate(pl);
}
New abstraction 'ConnectionLayer'. This is a vtable that wraps up all the functionality required from the SSH connection layer by associated modules like port forwarding and connection sharing. This extra layer of indirection adds nothing useful right now, but when I later separate the SSH-1 and SSH-2 connection layer implementations, it will be convenient for each one to be able to implement this vtable in terms of its own internal data structures. To simplify this vtable, I've moved a lot of the logging duties relating to connection sharing out of ssh.c into sshshare.c: now it handles nearly all the logging itself relating to setting up connection sharing in the first place and downstreams connecting and disconnecting. The only exception is the 'Reusing a shared connection' announcement in the console window, which is now done in ssh.c by detecting downstream status immediately after setup.
2018-09-17 11:14:00 +00:00
static SshChannel *wrap_lportfwd_open(
ConnectionLayer *cl, const char *hostname, int port,
Get rid of lots of implicit pointer types. All the main backend structures - Ssh, Telnet, Pty, Serial etc - now describe structure types themselves rather than pointers to them. The same goes for the codebase-wide trait types Socket and Plug, and the supporting types SockAddr and Pinger. All those things that were typedefed as pointers are older types; the newer ones have the explicit * at the point of use, because that's what I now seem to be preferring. But whichever one of those is better, inconsistently using a mixture of the two styles is worse, so let's make everything consistent. A few types are still implicitly pointers, such as Bignum and some of the GSSAPI types; generally this is either because they have to be void *, or because they're typedefed differently on different platforms and aren't always pointers at all. Can't be helped. But I've got rid of the main ones, at least.
2018-10-04 18:10:23 +00:00
Socket *s, Channel *chan)
Log identifying information for the other end of connections. When anyone connects to a PuTTY tool's listening socket - whether it's a user of a local->remote port forwarding, a connection-sharing downstream or a client of Pageant - we'd like to log as much information as we can find out about where the connection came from. To that end, I've implemented a function sk_peer_info() in the socket abstraction, which returns a freeform text string as best it can (or NULL, if it can't get anything at all) describing the thing at the other end of the connection. For TCP connections, this is done using getpeername() to get an IP address and port in the obvious way; for Unix-domain sockets, we attempt SO_PEERCRED (conditionalised on some moderately hairy autoconfery) to get the pid and owner of the peer. I haven't implemented anything for Windows named pipes, but I will if I hear of anything useful.
2015-05-18 12:57:45 +00:00
{
Improve sk_peer_info. Previously, it returned a human-readable string suitable for log files, which tried to say something useful about the remote end of a socket. Now it returns a whole SocketPeerInfo structure, of which that human-friendly log string is just one field, but also some of the same information - remote IP address and port, in particular - is provided in machine-readable form where it's available.
2018-10-18 19:06:42 +00:00
SocketPeerInfo *pi;
char *description;
Put a layer of abstraction in front of struct ssh_channel. Clients outside ssh.c - all implementations of Channel - will now not see the ssh_channel data type itself, but only a subobject of the interface type SshChannel. All the sshfwd_* functions have become methods in that interface type's vtable (though, wrapped in the usual kind of macros, the call sites look identical). This paves the way for me to split up the SSH-1 and SSH-2 connection layers and have each one lay out its channel bookkeeping structure as it sees fit; as long as they each provide an implementation of the sshfwd_ method family, the types behind that need not look different. A minor good effect of this is that the sshfwd_ methods are no longer global symbols, so they don't have to be stubbed in Unix Pageant to get it to compile.
2018-09-14 12:47:13 +00:00
SshChannel *toret;
Replace enum+union of local channel types with a vtable. There's now an interface called 'Channel', which handles the local side of an SSH connection-layer channel, in terms of knowing where to send incoming channel data to, whether to close the channel, etc. Channel and the previous 'struct ssh_channel' mutually refer. The latter contains all the SSH-specific parts, and as much of the common logic as possible: in particular, Channel doesn't have to know anything about SSH packet formats, or which SSH protocol version is in use, or deal with all the fiddly stuff about window sizes - with the exception that x11fwd.c's implementation of it does have to be able to ask for a small fixed initial window size for the bodgy system that distinguishes upstream from downstream X forwardings. I've taken the opportunity to move the code implementing the detailed behaviour of agent forwarding out of ssh.c, now that all of it is on the far side of a uniform interface. (This also means that if I later implement agent forwarding directly to a Unix socket as an alternative, it'll be a matter of changing just the one call to agentf_new() that makes the Channel to plug into a forwarding.)
2018-09-12 14:03:47 +00:00
Improve sk_peer_info. Previously, it returned a human-readable string suitable for log files, which tried to say something useful about the remote end of a socket. Now it returns a whole SocketPeerInfo structure, of which that human-friendly log string is just one field, but also some of the same information - remote IP address and port, in particular - is provided in machine-readable form where it's available.
2018-10-18 19:06:42 +00:00
pi = sk_peer_info(s);
if (pi && pi->log_text) {
description = dupprintf("forwarding from %s", pi->log_text);
Log identifying information for the other end of connections. When anyone connects to a PuTTY tool's listening socket - whether it's a user of a local->remote port forwarding, a connection-sharing downstream or a client of Pageant - we'd like to log as much information as we can find out about where the connection came from. To that end, I've implemented a function sk_peer_info() in the socket abstraction, which returns a freeform text string as best it can (or NULL, if it can't get anything at all) describing the thing at the other end of the connection. For TCP connections, this is done using getpeername() to get an IP address and port in the obvious way; for Unix-domain sockets, we attempt SO_PEERCRED (conditionalised on some moderately hairy autoconfery) to get the pid and owner of the peer. I haven't implemented anything for Windows named pipes, but I will if I hear of anything useful.
2015-05-18 12:57:45 +00:00
} else {
description = dupstr("forwarding");
}
Improve sk_peer_info. Previously, it returned a human-readable string suitable for log files, which tried to say something useful about the remote end of a socket. Now it returns a whole SocketPeerInfo structure, of which that human-friendly log string is just one field, but also some of the same information - remote IP address and port, in particular - is provided in machine-readable form where it's available.
2018-10-18 19:06:42 +00:00
toret = ssh_lportfwd_open(cl, hostname, port, description, pi, chan);
sk_free_peer_info(pi);
Replace enum+union of local channel types with a vtable. There's now an interface called 'Channel', which handles the local side of an SSH connection-layer channel, in terms of knowing where to send incoming channel data to, whether to close the channel, etc. Channel and the previous 'struct ssh_channel' mutually refer. The latter contains all the SSH-specific parts, and as much of the common logic as possible: in particular, Channel doesn't have to know anything about SSH packet formats, or which SSH protocol version is in use, or deal with all the fiddly stuff about window sizes - with the exception that x11fwd.c's implementation of it does have to be able to ask for a small fixed initial window size for the bodgy system that distinguishes upstream from downstream X forwardings. I've taken the opportunity to move the code implementing the detailed behaviour of agent forwarding out of ssh.c, now that all of it is on the far side of a uniform interface. (This also means that if I later implement agent forwarding directly to a Unix socket as an alternative, it'll be a matter of changing just the one call to agentf_new() that makes the Channel to plug into a forwarding.)
2018-09-12 14:03:47 +00:00
Log identifying information for the other end of connections. When anyone connects to a PuTTY tool's listening socket - whether it's a user of a local->remote port forwarding, a connection-sharing downstream or a client of Pageant - we'd like to log as much information as we can find out about where the connection came from. To that end, I've implemented a function sk_peer_info() in the socket abstraction, which returns a freeform text string as best it can (or NULL, if it can't get anything at all) describing the thing at the other end of the connection. For TCP connections, this is done using getpeername() to get an IP address and port in the obvious way; for Unix-domain sockets, we attempt SO_PEERCRED (conditionalised on some moderately hairy autoconfery) to get the pid and owner of the peer. I haven't implemented anything for Windows named pipes, but I will if I hear of anything useful.
2015-05-18 12:57:45 +00:00
sfree(description);
Replace enum+union of local channel types with a vtable. There's now an interface called 'Channel', which handles the local side of an SSH connection-layer channel, in terms of knowing where to send incoming channel data to, whether to close the channel, etc. Channel and the previous 'struct ssh_channel' mutually refer. The latter contains all the SSH-specific parts, and as much of the common logic as possible: in particular, Channel doesn't have to know anything about SSH packet formats, or which SSH protocol version is in use, or deal with all the fiddly stuff about window sizes - with the exception that x11fwd.c's implementation of it does have to be able to ask for a small fixed initial window size for the bodgy system that distinguishes upstream from downstream X forwardings. I've taken the opportunity to move the code implementing the detailed behaviour of agent forwarding out of ssh.c, now that all of it is on the far side of a uniform interface. (This also means that if I later implement agent forwarding directly to a Unix socket as an alternative, it'll be a matter of changing just the one call to agentf_new() that makes the Channel to plug into a forwarding.)
2018-09-12 14:03:47 +00:00
return toret;
Log identifying information for the other end of connections. When anyone connects to a PuTTY tool's listening socket - whether it's a user of a local->remote port forwarding, a connection-sharing downstream or a client of Pageant - we'd like to log as much information as we can find out about where the connection came from. To that end, I've implemented a function sk_peer_info() in the socket abstraction, which returns a freeform text string as best it can (or NULL, if it can't get anything at all) describing the thing at the other end of the connection. For TCP connections, this is done using getpeername() to get an IP address and port in the obvious way; for Unix-domain sockets, we attempt SO_PEERCRED (conditionalised on some moderately hairy autoconfery) to get the pid and owner of the peer. I haven't implemented anything for Windows named pipes, but I will if I hear of anything useful.
2015-05-18 12:57:45 +00:00
}
Rewrite SOCKS client code using BinarySource. I've also replaced the entire SOCKS state machine whose states were barely-documented literal integers with one that uses an actual enum. I think the result is a great deal clearer. In the course of this rewrite I noticed that PuTTY's dynamic port forwarding had never got round to supporting the SOCKS5 IPv6 address format - though there was a FIXME comment saying it ought to. So now it does: if a SOCKS5 client provides a binary IPv6 address (which PuTTY's _own_ SOCKS5 client, in proxy.c, is quite capable of doing!), then that will be translated into the usual IPv6 hex literal representation to put in the "direct-tcpip" channel open request.
2018-05-30 21:36:20 +00:00
static char *ipv4_to_string(unsigned ipv4)
{
return dupprintf("%u.%u.%u.%u",
(ipv4 >> 24) & 0xFF, (ipv4 >> 16) & 0xFF,
(ipv4 >> 8) & 0xFF, (ipv4 ) & 0xFF);
}
static char *ipv6_to_string(ptrlen ipv6)
{
const unsigned char *addr = ipv6.ptr;
assert(ipv6.len == 16);
return dupprintf("%04x:%04x:%04x:%04x:%04x:%04x:%04x:%04x",
(unsigned)GET_16BIT_MSB_FIRST(addr + 0),
(unsigned)GET_16BIT_MSB_FIRST(addr + 2),
(unsigned)GET_16BIT_MSB_FIRST(addr + 4),
(unsigned)GET_16BIT_MSB_FIRST(addr + 6),
(unsigned)GET_16BIT_MSB_FIRST(addr + 8),
(unsigned)GET_16BIT_MSB_FIRST(addr + 10),
(unsigned)GET_16BIT_MSB_FIRST(addr + 12),
(unsigned)GET_16BIT_MSB_FIRST(addr + 14));
}
Get rid of lots of implicit pointer types. All the main backend structures - Ssh, Telnet, Pty, Serial etc - now describe structure types themselves rather than pointers to them. The same goes for the codebase-wide trait types Socket and Plug, and the supporting types SockAddr and Pinger. All those things that were typedefed as pointers are older types; the newer ones have the explicit * at the point of use, because that's what I now seem to be preferring. But whichever one of those is better, inconsistently using a mixture of the two styles is worse, so let's make everything consistent. A few types are still implicitly pointers, such as Bignum and some of the GSSAPI types; generally this is either because they have to be void *, or because they're typedefed differently on different platforms and aren't always pointers at all. Can't be helped. But I've got rid of the main ones, at least.
2018-10-04 18:10:23 +00:00
static void pfd_receive(Plug *plug, int urgent, char *data, int len)
Oops - actually check in portfwd.c itself! (Makefile also modified because it's been renamed to fit in 8.3, just in case.) [originally from svn r1177]
2001-08-08 20:53:27 +00:00
{
Rename FROMFIELD to 'container_of'. Ian Jackson points out that the Linux kernel has a macro of this name with the same purpose, and suggests that it's a good idea to use the same name as they do, so that at least some people reading one code base might recognise it from the other. I never really thought very hard about what order FROMFIELD's parameters should go in, and therefore I'm pleasantly surprised to find that my order agrees with the kernel's, so I don't have to permute every call site as part of making this change :-)
2018-10-05 22:49:08 +00:00
struct PortForwarding *pf =
container_of(plug, struct PortForwarding, plug);
Rewrite SOCKS client code using BinarySource. I've also replaced the entire SOCKS state machine whose states were barely-documented literal integers with one that uses an actual enum. I think the result is a great deal clearer. In the course of this rewrite I noticed that PuTTY's dynamic port forwarding had never got round to supporting the SOCKS5 IPv6 address format - though there was a FIXME comment saying it ought to. So now it does: if a SOCKS5 client provides a binary IPv6 address (which PuTTY's _own_ SOCKS5 client, in proxy.c, is quite capable of doing!), then that will be translated into the usual IPv6 hex literal representation to put in the "direct-tcpip" channel open request.
2018-05-30 21:36:20 +00:00
if (len == 0)
return;
if (pf->socks_state != SOCKS_NONE) {
BinarySource src[1];
/*
* Store all the data we've got in socksbuf.
*/
put_data(pf->socksbuf, data, len);
/*
* Check the start of socksbuf to see if it's a valid and
* complete message in the SOCKS exchange.
*/
if (pf->socks_state == SOCKS_INITIAL) {
/* Preliminary: check the first byte of the data (which we
* _must_ have by now) to find out which SOCKS major
* version we're speaking. */
switch (pf->socksbuf->u[0]) {
case 4:
pf->socks_state = SOCKS_4;
break;
case 5:
pf->socks_state = SOCKS_5_INITIAL;
break;
default:
pfd_close(pf); /* unrecognised version */
return;
}
}
BinarySource_BARE_INIT(src, pf->socksbuf->u, pf->socksbuf->len);
get_data(src, pf->socksbuf_consumed);
while (pf->socks_state != SOCKS_NONE) {
unsigned socks_version, message_type, reserved_byte;
unsigned reply_code, port, ipv4, method;
ptrlen methods;
const char *socks4_hostname;
strbuf *output;
switch (pf->socks_state) {
case SOCKS_INITIAL:
case SOCKS_NONE:
assert(0 && "These case values cannot appear");
case SOCKS_4:
/* SOCKS 4/4A connect message */
socks_version = get_byte(src);
message_type = get_byte(src);
if (get_err(src) == BSE_OUT_OF_DATA)
return;
if (socks_version == 4 && message_type == 1) {
/* CONNECT message */
Adopt C99 <stdbool.h>'s true/false. This commit includes <stdbool.h> from defs.h and deletes my traditional definitions of TRUE and FALSE, but other than that, it's a 100% mechanical search-and-replace transforming all uses of TRUE and FALSE into the C99-standardised lowercase spellings. No actual types are changed in this commit; that will come next. This is just getting the noise out of the way, so that subsequent commits can have a higher proportion of signal.
2018-10-29 19:50:29 +00:00
int name_based = false;
Rewrite SOCKS client code using BinarySource. I've also replaced the entire SOCKS state machine whose states were barely-documented literal integers with one that uses an actual enum. I think the result is a great deal clearer. In the course of this rewrite I noticed that PuTTY's dynamic port forwarding had never got round to supporting the SOCKS5 IPv6 address format - though there was a FIXME comment saying it ought to. So now it does: if a SOCKS5 client provides a binary IPv6 address (which PuTTY's _own_ SOCKS5 client, in proxy.c, is quite capable of doing!), then that will be translated into the usual IPv6 hex literal representation to put in the "direct-tcpip" channel open request.
2018-05-30 21:36:20 +00:00
port = get_uint16(src);
ipv4 = get_uint32(src);
if (ipv4 > 0x00000000 && ipv4 < 0x00000100) {
/*
* Addresses in this range indicate the SOCKS 4A
* extension to specify a hostname, which comes
* after the username.
*/
Adopt C99 <stdbool.h>'s true/false. This commit includes <stdbool.h> from defs.h and deletes my traditional definitions of TRUE and FALSE, but other than that, it's a 100% mechanical search-and-replace transforming all uses of TRUE and FALSE into the C99-standardised lowercase spellings. No actual types are changed in this commit; that will come next. This is just getting the noise out of the way, so that subsequent commits can have a higher proportion of signal.
2018-10-29 19:50:29 +00:00
name_based = true;
Rewrite SOCKS client code using BinarySource. I've also replaced the entire SOCKS state machine whose states were barely-documented literal integers with one that uses an actual enum. I think the result is a great deal clearer. In the course of this rewrite I noticed that PuTTY's dynamic port forwarding had never got round to supporting the SOCKS5 IPv6 address format - though there was a FIXME comment saying it ought to. So now it does: if a SOCKS5 client provides a binary IPv6 address (which PuTTY's _own_ SOCKS5 client, in proxy.c, is quite capable of doing!), then that will be translated into the usual IPv6 hex literal representation to put in the "direct-tcpip" channel open request.
2018-05-30 21:36:20 +00:00
}
get_asciz(src); /* skip username */
socks4_hostname = name_based ? get_asciz(src) : NULL;
if (get_err(src) == BSE_OUT_OF_DATA)
return;
if (get_err(src))
goto socks4_reject;
pf->port = port;
if (name_based) {
pf->hostname = dupstr(socks4_hostname);
} else {
pf->hostname = ipv4_to_string(ipv4);
}
output = strbuf_new();
put_byte(output, 0); /* reply version */
put_byte(output, 90); /* SOCKS 4 'request granted' */
put_uint16(output, 0); /* null port field */
put_uint32(output, 0); /* null address field */
sk_write(pf->s, output->u, output->len);
strbuf_free(output);
pf->socks_state = SOCKS_NONE;
pf->socksbuf_consumed = src->pos;
break;
}
socks4_reject:
output = strbuf_new();
put_byte(output, 0); /* reply version */
put_byte(output, 91); /* SOCKS 4 'request rejected' */
put_uint16(output, 0); /* null port field */
put_uint32(output, 0); /* null address field */
sk_write(pf->s, output->u, output->len);
strbuf_free(output);
pfd_close(pf);
return;
case SOCKS_5_INITIAL:
/* SOCKS 5 initial method list */
socks_version = get_byte(src);
methods = get_pstring(src);
method = 0xFF; /* means 'no usable method found' */
{
int i;
for (i = 0; i < methods.len; i++) {
if (((const unsigned char *)methods.ptr)[i] == 0 ) {
method = 0; /* no auth */
break;
}
}
}
if (get_err(src) == BSE_OUT_OF_DATA)
return;
if (get_err(src))
method = 0xFF;
output = strbuf_new();
put_byte(output, 5); /* SOCKS version */
put_byte(output, method); /* selected auth method */
sk_write(pf->s, output->u, output->len);
strbuf_free(output);
if (method == 0xFF) {
pfd_close(pf);
return;
}
pf->socks_state = SOCKS_5_CONNECT;
pf->socksbuf_consumed = src->pos;
break;
case SOCKS_5_CONNECT:
/* SOCKS 5 connect message */
socks_version = get_byte(src);
message_type = get_byte(src);
reserved_byte = get_byte(src);
if (socks_version == 5 && message_type == 1 &&
reserved_byte == 0) {
reply_code = 0; /* success */
switch (get_byte(src)) {
case 1: /* IPv4 */
pf->hostname = ipv4_to_string(get_uint32(src));
break;
case 4: /* IPv6 */
pf->hostname = ipv6_to_string(get_data(src, 16));
break;
case 3: /* unresolved domain name */
pf->hostname = mkstr(get_pstring(src));
break;
default:
pf->hostname = NULL;
reply_code = 8; /* address type not supported */
break;
}
pf->port = get_uint16(src);
} else {
reply_code = 7; /* command not supported */
}
if (get_err(src) == BSE_OUT_OF_DATA)
return;
if (get_err(src))
reply_code = 1; /* general server failure */
output = strbuf_new();
put_byte(output, 5); /* SOCKS version */
put_byte(output, reply_code);
put_byte(output, 0); /* reserved */
put_byte(output, 1); /* IPv4 address follows */
put_uint32(output, 0); /* bound IPv4 address (unused) */
put_uint16(output, 0); /* bound port number (unused) */
sk_write(pf->s, output->u, output->len);
strbuf_free(output);
if (reply_code != 0) {
pfd_close(pf);
return;
}
pf->socks_state = SOCKS_NONE;
pf->socksbuf_consumed = src->pos;
break;
}
}
Dynamic port forwarding by means of a local SOCKS server. Fully supports SOCKS 4, SOCKS 4A and SOCKS 5 (well, actually IPv6 in SOCKS 5 isn't supported, but it'll be no difficulty once I actually get round to it). Thanks to Chas Honton for his `stone soup' patch: I didn't end up actually using any of his code, but it galvanised me into doing it properly myself :-) [originally from svn r3055]
2003-04-05 11:45:21 +00:00
/*
* We come here when we're ready to make an actual
* connection.
*/
When starting a SOCKS connection in dynamic forwarding, freeze the local socket _before_ calling the SSH setup functions. This makes no difference to ssh.c itself, but it makes portfwd.c easier to reuse for other purposes (e.g. as a component of a standalone SOCKS server), because now ssh_send_port_open() can itself call pfd_confirm() without the freeze and unfreeze happening in the wrong order. [originally from svn r8500]
2009-04-23 17:33:42 +00:00
/*
* Freeze the socket until the SSH server confirms the
* connection.
*/
Refactor ssh.c's APIs to x11fwd.c and portfwd.c. The most important change is that, where previously ssh.c held the Socket pointer for each X11 and port forwarding, and the support modules would find their internal state structure by calling sk_get_private_ptr on that Socket, it's now the other way round. ssh.c now directly holds the internal state structure pointer for each forwarding, and when the support module needs the Socket it looks it up in a field of that. This will come in handy when I decouple socket creation from logical forwarding setup, so that X forwardings can delay actually opening a connection to an X server until they look at the authentication data and see which server it has to be. However, while I'm here, I've also taken the opportunity to clean up a few other points, notably error message handling, and also the fact that the same kind of state structure was used for both connection-type and listening-type port forwardings. Now there are separate PortForwarding and PortListener structure types, which seems far more sensible. [originally from svn r10074]
2013-11-17 14:04:41 +00:00
sk_set_frozen(pf->s, 1);
When starting a SOCKS connection in dynamic forwarding, freeze the local socket _before_ calling the SSH setup functions. This makes no difference to ssh.c itself, but it makes portfwd.c easier to reuse for other purposes (e.g. as a component of a standalone SOCKS server), because now ssh_send_port_open() can itself call pfd_confirm() without the freeze and unfreeze happening in the wrong order. [originally from svn r8500]
2009-04-23 17:33:42 +00:00
New abstraction 'ConnectionLayer'. This is a vtable that wraps up all the functionality required from the SSH connection layer by associated modules like port forwarding and connection sharing. This extra layer of indirection adds nothing useful right now, but when I later separate the SSH-1 and SSH-2 connection layer implementations, it will be convenient for each one to be able to implement this vtable in terms of its own internal data structures. To simplify this vtable, I've moved a lot of the logging duties relating to connection sharing out of ssh.c into sshshare.c: now it handles nearly all the logging itself relating to setting up connection sharing in the first place and downstreams connecting and disconnecting. The only exception is the 'Reusing a shared connection' announcement in the console window, which is now done in ssh.c by detecting downstream status immediately after setup.
2018-09-17 11:14:00 +00:00
pf->c = wrap_lportfwd_open(pf->cl, pf->hostname, pf->port, pf->s,
&pf->chan);
Extensive changes that _should_ fix the socket buffering problems, by ceasing to listen on input channels if the corresponding output channel isn't accepting data. Has had basic check-I-didn't-actually- break-anything-too-badly testing, but hasn't been genuinely tested in stress conditions (because concocting stress conditions is non- trivial). [originally from svn r1198]
2001-08-25 17:09:23 +00:00
}
Replace enum+union of local channel types with a vtable. There's now an interface called 'Channel', which handles the local side of an SSH connection-layer channel, in terms of knowing where to send incoming channel data to, whether to close the channel, etc. Channel and the previous 'struct ssh_channel' mutually refer. The latter contains all the SSH-specific parts, and as much of the common logic as possible: in particular, Channel doesn't have to know anything about SSH packet formats, or which SSH protocol version is in use, or deal with all the fiddly stuff about window sizes - with the exception that x11fwd.c's implementation of it does have to be able to ask for a small fixed initial window size for the bodgy system that distinguishes upstream from downstream X forwardings. I've taken the opportunity to move the code implementing the detailed behaviour of agent forwarding out of ssh.c, now that all of it is on the far side of a uniform interface. (This also means that if I later implement agent forwarding directly to a Unix socket as an alternative, it'll be a matter of changing just the one call to agentf_new() that makes the Channel to plug into a forwarding.)
2018-09-12 14:03:47 +00:00
if (pf->ready)
sshfwd_write(pf->c, data, len);
Oops - actually check in portfwd.c itself! (Makefile also modified because it's been renamed to fit in 8.3, just in case.) [originally from svn r1177]
2001-08-08 20:53:27 +00:00
}
Get rid of lots of implicit pointer types. All the main backend structures - Ssh, Telnet, Pty, Serial etc - now describe structure types themselves rather than pointers to them. The same goes for the codebase-wide trait types Socket and Plug, and the supporting types SockAddr and Pinger. All those things that were typedefed as pointers are older types; the newer ones have the explicit * at the point of use, because that's what I now seem to be preferring. But whichever one of those is better, inconsistently using a mixture of the two styles is worse, so let's make everything consistent. A few types are still implicitly pointers, such as Bignum and some of the GSSAPI types; generally this is either because they have to be void *, or because they're typedefed differently on different platforms and aren't always pointers at all. Can't be helped. But I've got rid of the main ones, at least.
2018-10-04 18:10:23 +00:00
static void pfd_sent(Plug *plug, int bufsize)
Extensive changes that _should_ fix the socket buffering problems, by ceasing to listen on input channels if the corresponding output channel isn't accepting data. Has had basic check-I-didn't-actually- break-anything-too-badly testing, but hasn't been genuinely tested in stress conditions (because concocting stress conditions is non- trivial). [originally from svn r1198]
2001-08-25 17:09:23 +00:00
{
Rename FROMFIELD to 'container_of'. Ian Jackson points out that the Linux kernel has a macro of this name with the same purpose, and suggests that it's a good idea to use the same name as they do, so that at least some people reading one code base might recognise it from the other. I never really thought very hard about what order FROMFIELD's parameters should go in, and therefore I'm pleasantly surprised to find that my order agrees with the kernel's, so I don't have to permute every call site as part of making this change :-)
2018-10-05 22:49:08 +00:00
struct PortForwarding *pf =
container_of(plug, struct PortForwarding, plug);
Extensive changes that _should_ fix the socket buffering problems, by ceasing to listen on input channels if the corresponding output channel isn't accepting data. Has had basic check-I-didn't-actually- break-anything-too-badly testing, but hasn't been genuinely tested in stress conditions (because concocting stress conditions is non- trivial). [originally from svn r1198]
2001-08-25 17:09:23 +00:00
Refactor ssh.c's APIs to x11fwd.c and portfwd.c. The most important change is that, where previously ssh.c held the Socket pointer for each X11 and port forwarding, and the support modules would find their internal state structure by calling sk_get_private_ptr on that Socket, it's now the other way round. ssh.c now directly holds the internal state structure pointer for each forwarding, and when the support module needs the Socket it looks it up in a field of that. This will come in handy when I decouple socket creation from logical forwarding setup, so that X forwardings can delay actually opening a connection to an X server until they look at the authentication data and see which server it has to be. However, while I'm here, I've also taken the opportunity to clean up a few other points, notably error message handling, and also the fact that the same kind of state structure was used for both connection-type and listening-type port forwardings. Now there are separate PortForwarding and PortListener structure types, which seems far more sensible. [originally from svn r10074]
2013-11-17 14:04:41 +00:00
if (pf->c)
sshfwd_unthrottle(pf->c, bufsize);
Extensive changes that _should_ fix the socket buffering problems, by ceasing to listen on input channels if the corresponding output channel isn't accepting data. Has had basic check-I-didn't-actually- break-anything-too-badly testing, but hasn't been genuinely tested in stress conditions (because concocting stress conditions is non- trivial). [originally from svn r1198]
2001-08-25 17:09:23 +00:00
}
Name vtable structure types more consistently. Now they're all called FooVtable, instead of a mixture of that and Foo_vtable.
2018-10-05 06:03:46 +00:00
static const PlugVtable PortForwarding_plugvt = {
Modernise the Socket/Plug vtable system. Now I've got FROMFIELD, I can rework it so that structures providing an implementation of the Socket or Plug trait no longer have to have the vtable pointer as the very first thing in the structure. In particular, this means that the ProxySocket structure can now directly implement _both_ the Socket and Plug traits, which is always _logically_ how it's worked, but previously it had to be implemented via two separate structs linked to each other.
2018-05-27 08:29:33 +00:00
pfd_log,
pfd_closing,
pfd_receive,
pfd_sent,
NULL
};
Replace enum+union of local channel types with a vtable. There's now an interface called 'Channel', which handles the local side of an SSH connection-layer channel, in terms of knowing where to send incoming channel data to, whether to close the channel, etc. Channel and the previous 'struct ssh_channel' mutually refer. The latter contains all the SSH-specific parts, and as much of the common logic as possible: in particular, Channel doesn't have to know anything about SSH packet formats, or which SSH protocol version is in use, or deal with all the fiddly stuff about window sizes - with the exception that x11fwd.c's implementation of it does have to be able to ask for a small fixed initial window size for the bodgy system that distinguishes upstream from downstream X forwardings. I've taken the opportunity to move the code implementing the detailed behaviour of agent forwarding out of ssh.c, now that all of it is on the far side of a uniform interface. (This also means that if I later implement agent forwarding directly to a Unix socket as an alternative, it'll be a matter of changing just the one call to agentf_new() that makes the Channel to plug into a forwarding.)
2018-09-12 14:03:47 +00:00
static void pfd_chan_free(Channel *chan);
static void pfd_open_confirmation(Channel *chan);
static void pfd_open_failure(Channel *chan, const char *errtext);
static int pfd_send(Channel *chan, int is_stderr, const void *data, int len);
static void pfd_send_eof(Channel *chan);
static void pfd_set_input_wanted(Channel *chan, int wanted);
static char *pfd_log_close_msg(Channel *chan);
static const struct ChannelVtable PortForwarding_channelvt = {
pfd_chan_free,
pfd_open_confirmation,
pfd_open_failure,
pfd_send,
pfd_send_eof,
pfd_set_input_wanted,
pfd_log_close_msg,
Allow channels not to close immediately after two EOFs. Some kinds of channel, even after they've sent EOF in both directions, still have something to do before they initiate the CLOSE mechanism and wind up the channel completely. For example, a session channel with a subprocess running inside it will want to be sure to send the "exit-status" or "exit-signal" notification, even if that happens after bidirectional EOF of the data channels. Previously, the SSH-2 connection layer had the standard policy that once EOF had been both sent and received, it would start the final close procedure. There's a method chan_want_close() by which a Channel could vary this policy in one direction, by indicating that it wanted the close procedure to commence after EOF was sent in only one direction. Its parameters are a pair of booleans saying whether EOF has been sent, and whether it's been received. Now chan_want_close can vary the policy in the other direction as well: if it returns FALSE even when _both_ parameters are true, the connection layer will honour that, and not send CHANNEL_CLOSE. If it does that, the Channel is responsible for indicating when it _does_ want close later, by calling sshfwd_initiate_close.
2018-10-18 17:02:59 +00:00
chan_default_want_close,
Devolve channel-request handling to Channel vtable. Instead of the central code in ssh2_connection_filter_queue doing both the job of parsing the channel request and deciding whether it's acceptable, each Channel vtable now has a method for every channel request type we recognise.
2018-09-26 16:34:20 +00:00
chan_no_exit_status,
chan_no_exit_signal,
chan_no_exit_signal_numeric,
Server prep: parse a lot of new channel requests. ssh2connection.c now knows how to unmarshal the message formats for all the channel requests we'll need to handle when we're the server and a client sends them. Each one is translated into a call to a new method in the Channel vtable, which is implemented by a trivial 'always fail' routine in every channel type we know about so far.
2018-10-20 20:48:49 +00:00
chan_no_run_shell,
chan_no_run_command,
chan_no_run_subsystem,
chan_no_enable_x11_forwarding,
chan_no_enable_agent_forwarding,
chan_no_allocate_pty,
chan_no_set_env,
chan_no_send_break,
chan_no_send_signal,
chan_no_change_window_size,
Move channel-opening logic out into subroutines. Each of the new subroutines corresponds to one of the channel types for which we know how to parse a CHANNEL_OPEN, and has a collection of parameters corresponding to the fields of that message structure. ssh2_connection_filter_queue now confines itself to parsing the message, calling one of those functions, and constructing an appropriate reply message if any.
2018-09-26 17:02:33 +00:00
chan_no_request_response,
Replace enum+union of local channel types with a vtable. There's now an interface called 'Channel', which handles the local side of an SSH connection-layer channel, in terms of knowing where to send incoming channel data to, whether to close the channel, etc. Channel and the previous 'struct ssh_channel' mutually refer. The latter contains all the SSH-specific parts, and as much of the common logic as possible: in particular, Channel doesn't have to know anything about SSH packet formats, or which SSH protocol version is in use, or deal with all the fiddly stuff about window sizes - with the exception that x11fwd.c's implementation of it does have to be able to ask for a small fixed initial window size for the bodgy system that distinguishes upstream from downstream X forwardings. I've taken the opportunity to move the code implementing the detailed behaviour of agent forwarding out of ssh.c, now that all of it is on the far side of a uniform interface. (This also means that if I later implement agent forwarding directly to a Unix socket as an alternative, it'll be a matter of changing just the one call to agentf_new() that makes the Channel to plug into a forwarding.)
2018-09-12 14:03:47 +00:00
};
Server prep: factor out portfwd_raw_new(). This new function contains the core setup for a PortForwarding structure, and should be reusable for any kind of forwarding that will simply be passing data between a local socket and an SSH channel without any tricky modifications. On the server side, X11 and agent forwarding both work exactly like this, so they will find this refactored function useful during setup. The contents of the function was originally part of pfl_accepting, which now does all that by calling the new function. pfl_accepting is not _quite_ doing a simple unmodified forwarding, because it might have to prefix it with a SOCKS exchange; in that situation it rewrites a few fields of the PortForwarding to some less generic values once portfwd_raw_new() has returned.
2018-10-20 21:47:49 +00:00
Channel *portfwd_raw_new(ConnectionLayer *cl, Plug **plug)
Oops - actually check in portfwd.c itself! (Makefile also modified because it's been renamed to fit in 8.3, just in case.) [originally from svn r1177]
2001-08-08 20:53:27 +00:00
{
Refactor ssh.c's APIs to x11fwd.c and portfwd.c. The most important change is that, where previously ssh.c held the Socket pointer for each X11 and port forwarding, and the support modules would find their internal state structure by calling sk_get_private_ptr on that Socket, it's now the other way round. ssh.c now directly holds the internal state structure pointer for each forwarding, and when the support module needs the Socket it looks it up in a field of that. This will come in handy when I decouple socket creation from logical forwarding setup, so that X forwardings can delay actually opening a connection to an X server until they look at the authentication data and see which server it has to be. However, while I'm here, I've also taken the opportunity to clean up a few other points, notably error message handling, and also the fact that the same kind of state structure was used for both connection-type and listening-type port forwardings. Now there are separate PortForwarding and PortListener structure types, which seems far more sensible. [originally from svn r10074]
2013-11-17 14:04:41 +00:00
struct PortForwarding *pf;
Oops - actually check in portfwd.c itself! (Makefile also modified because it's been renamed to fit in 8.3, just in case.) [originally from svn r1177]
2001-08-08 20:53:27 +00:00
Refactor ssh.c's APIs to x11fwd.c and portfwd.c. The most important change is that, where previously ssh.c held the Socket pointer for each X11 and port forwarding, and the support modules would find their internal state structure by calling sk_get_private_ptr on that Socket, it's now the other way round. ssh.c now directly holds the internal state structure pointer for each forwarding, and when the support module needs the Socket it looks it up in a field of that. This will come in handy when I decouple socket creation from logical forwarding setup, so that X forwardings can delay actually opening a connection to an X server until they look at the authentication data and see which server it has to be. However, while I'm here, I've also taken the opportunity to clean up a few other points, notably error message handling, and also the fact that the same kind of state structure was used for both connection-type and listening-type port forwardings. Now there are separate PortForwarding and PortListener structure types, which seems far more sensible. [originally from svn r10074]
2013-11-17 14:04:41 +00:00
pf = new_portfwd_state();
Make Socket and Plug into structs. I think that means that _every_ one of my traitoids is now a struct containing a vtable pointer as one of its fields (albeit sometimes the only field), and never just a bare pointer.
2018-10-05 06:24:16 +00:00
pf->plug.vt = &PortForwarding_plugvt;
Replace enum+union of local channel types with a vtable. There's now an interface called 'Channel', which handles the local side of an SSH connection-layer channel, in terms of knowing where to send incoming channel data to, whether to close the channel, etc. Channel and the previous 'struct ssh_channel' mutually refer. The latter contains all the SSH-specific parts, and as much of the common logic as possible: in particular, Channel doesn't have to know anything about SSH packet formats, or which SSH protocol version is in use, or deal with all the fiddly stuff about window sizes - with the exception that x11fwd.c's implementation of it does have to be able to ask for a small fixed initial window size for the bodgy system that distinguishes upstream from downstream X forwardings. I've taken the opportunity to move the code implementing the detailed behaviour of agent forwarding out of ssh.c, now that all of it is on the far side of a uniform interface. (This also means that if I later implement agent forwarding directly to a Unix socket as an alternative, it'll be a matter of changing just the one call to agentf_new() that makes the Channel to plug into a forwarding.)
2018-09-12 14:03:47 +00:00
pf->chan.initial_fixed_window_size = 0;
pf->chan.vt = &PortForwarding_channelvt;
Adopt C99 <stdbool.h>'s true/false. This commit includes <stdbool.h> from defs.h and deletes my traditional definitions of TRUE and FALSE, but other than that, it's a 100% mechanical search-and-replace transforming all uses of TRUE and FALSE into the C99-standardised lowercase spellings. No actual types are changed in this commit; that will come next. This is just getting the noise out of the way, so that subsequent commits can have a higher proportion of signal.
2018-10-29 19:50:29 +00:00
pf->input_wanted = true;
Oops - actually check in portfwd.c itself! (Makefile also modified because it's been renamed to fit in 8.3, just in case.) [originally from svn r1177]
2001-08-08 20:53:27 +00:00
Refactor ssh.c's APIs to x11fwd.c and portfwd.c. The most important change is that, where previously ssh.c held the Socket pointer for each X11 and port forwarding, and the support modules would find their internal state structure by calling sk_get_private_ptr on that Socket, it's now the other way round. ssh.c now directly holds the internal state structure pointer for each forwarding, and when the support module needs the Socket it looks it up in a field of that. This will come in handy when I decouple socket creation from logical forwarding setup, so that X forwardings can delay actually opening a connection to an X server until they look at the authentication data and see which server it has to be. However, while I'm here, I've also taken the opportunity to clean up a few other points, notably error message handling, and also the fact that the same kind of state structure was used for both connection-type and listening-type port forwardings. Now there are separate PortForwarding and PortListener structure types, which seems far more sensible. [originally from svn r10074]
2013-11-17 14:04:41 +00:00
pf->c = NULL;
Oops - actually check in portfwd.c itself! (Makefile also modified because it's been renamed to fit in 8.3, just in case.) [originally from svn r1177]
2001-08-08 20:53:27 +00:00
Server prep: factor out portfwd_raw_new(). This new function contains the core setup for a PortForwarding structure, and should be reusable for any kind of forwarding that will simply be passing data between a local socket and an SSH channel without any tricky modifications. On the server side, X11 and agent forwarding both work exactly like this, so they will find this refactored function useful during setup. The contents of the function was originally part of pfl_accepting, which now does all that by calling the new function. pfl_accepting is not _quite_ doing a simple unmodified forwarding, because it might have to prefix it with a SOCKS exchange; in that situation it rewrites a few fields of the PortForwarding to some less generic values once portfwd_raw_new() has returned.
2018-10-20 21:47:49 +00:00
pf->cl = cl;
Adopt C99 <stdbool.h>'s true/false. This commit includes <stdbool.h> from defs.h and deletes my traditional definitions of TRUE and FALSE, but other than that, it's a 100% mechanical search-and-replace transforming all uses of TRUE and FALSE into the C99-standardised lowercase spellings. No actual types are changed in this commit; that will come next. This is just getting the noise out of the way, so that subsequent commits can have a higher proportion of signal.
2018-10-29 19:50:29 +00:00
pf->input_wanted = true;
Server prep: factor out portfwd_raw_new(). This new function contains the core setup for a PortForwarding structure, and should be reusable for any kind of forwarding that will simply be passing data between a local socket and an SSH channel without any tricky modifications. On the server side, X11 and agent forwarding both work exactly like this, so they will find this refactored function useful during setup. The contents of the function was originally part of pfl_accepting, which now does all that by calling the new function. pfl_accepting is not _quite_ doing a simple unmodified forwarding, because it might have to prefix it with a SOCKS exchange; in that situation it rewrites a few fields of the PortForwarding to some less generic values once portfwd_raw_new() has returned.
2018-10-20 21:47:49 +00:00
pf->ready = 0;
pf->socks_state = SOCKS_NONE;
pf->hostname = NULL;
pf->port = 0;
*plug = &pf->plug;
return &pf->chan;
}
void portfwd_raw_free(Channel *pfchan)
{
struct PortForwarding *pf;
assert(pfchan->vt == &PortForwarding_channelvt);
pf = container_of(pfchan, struct PortForwarding, chan);
free_portfwd_state(pf);
}
void portfwd_raw_setup(Channel *pfchan, Socket *s, SshChannel *sc)
{
struct PortForwarding *pf;
assert(pfchan->vt == &PortForwarding_channelvt);
pf = container_of(pfchan, struct PortForwarding, chan);
pf->s = s;
pf->c = sc;
}
/*
called when someone connects to the local port
*/
static int pfl_accepting(Plug *p, accept_fn_t constructor, accept_ctx_t ctx)
{
struct PortListener *pl = container_of(p, struct PortListener, plug);
struct PortForwarding *pf;
Channel *chan;
Plug *plug;
Socket *s;
const char *err;
chan = portfwd_raw_new(pl->cl, &plug);
s = constructor(ctx, plug);
Fix more "possible unintended assignment" warnings. [originally from svn r2459]
2003-01-05 13:04:04 +00:00
if ((err = sk_socket_error(s)) != NULL) {
Server prep: factor out portfwd_raw_new(). This new function contains the core setup for a PortForwarding structure, and should be reusable for any kind of forwarding that will simply be passing data between a local socket and an SSH channel without any tricky modifications. On the server side, X11 and agent forwarding both work exactly like this, so they will find this refactored function useful during setup. The contents of the function was originally part of pfl_accepting, which now does all that by calling the new function. pfl_accepting is not _quite_ doing a simple unmodified forwarding, because it might have to prefix it with a SOCKS exchange; in that situation it rewrites a few fields of the PortForwarding to some less generic values once portfwd_raw_new() has returned.
2018-10-20 21:47:49 +00:00
portfwd_raw_free(chan);
Adopt C99 <stdbool.h>'s true/false. This commit includes <stdbool.h> from defs.h and deletes my traditional definitions of TRUE and FALSE, but other than that, it's a 100% mechanical search-and-replace transforming all uses of TRUE and FALSE into the C99-standardised lowercase spellings. No actual types are changed in this commit; that will come next. This is just getting the noise out of the way, so that subsequent commits can have a higher proportion of signal.
2018-10-29 19:50:29 +00:00
return true;
Oops - actually check in portfwd.c itself! (Makefile also modified because it's been renamed to fit in 8.3, just in case.) [originally from svn r1177]
2001-08-08 20:53:27 +00:00
}
Server prep: factor out portfwd_raw_new(). This new function contains the core setup for a PortForwarding structure, and should be reusable for any kind of forwarding that will simply be passing data between a local socket and an SSH channel without any tricky modifications. On the server side, X11 and agent forwarding both work exactly like this, so they will find this refactored function useful during setup. The contents of the function was originally part of pfl_accepting, which now does all that by calling the new function. pfl_accepting is not _quite_ doing a simple unmodified forwarding, because it might have to prefix it with a SOCKS exchange; in that situation it rewrites a few fields of the PortForwarding to some less generic values once portfwd_raw_new() has returned.
2018-10-20 21:47:49 +00:00
pf = container_of(chan, struct PortForwarding, chan);
Oops - actually check in portfwd.c itself! (Makefile also modified because it's been renamed to fit in 8.3, just in case.) [originally from svn r1177]
2001-08-08 20:53:27 +00:00
Rewrite SOCKS client code using BinarySource. I've also replaced the entire SOCKS state machine whose states were barely-documented literal integers with one that uses an actual enum. I think the result is a great deal clearer. In the course of this rewrite I noticed that PuTTY's dynamic port forwarding had never got round to supporting the SOCKS5 IPv6 address format - though there was a FIXME comment saying it ought to. So now it does: if a SOCKS5 client provides a binary IPv6 address (which PuTTY's _own_ SOCKS5 client, in proxy.c, is quite capable of doing!), then that will be translated into the usual IPv6 hex literal representation to put in the "direct-tcpip" channel open request.
2018-05-30 21:36:20 +00:00
if (pl->is_dynamic) {
Server prep: factor out portfwd_raw_new(). This new function contains the core setup for a PortForwarding structure, and should be reusable for any kind of forwarding that will simply be passing data between a local socket and an SSH channel without any tricky modifications. On the server side, X11 and agent forwarding both work exactly like this, so they will find this refactored function useful during setup. The contents of the function was originally part of pfl_accepting, which now does all that by calling the new function. pfl_accepting is not _quite_ doing a simple unmodified forwarding, because it might have to prefix it with a SOCKS exchange; in that situation it rewrites a few fields of the PortForwarding to some less generic values once portfwd_raw_new() has returned.
2018-10-20 21:47:49 +00:00
pf->s = s;
Rewrite SOCKS client code using BinarySource. I've also replaced the entire SOCKS state machine whose states were barely-documented literal integers with one that uses an actual enum. I think the result is a great deal clearer. In the course of this rewrite I noticed that PuTTY's dynamic port forwarding had never got round to supporting the SOCKS5 IPv6 address format - though there was a FIXME comment saying it ought to. So now it does: if a SOCKS5 client provides a binary IPv6 address (which PuTTY's _own_ SOCKS5 client, in proxy.c, is quite capable of doing!), then that will be translated into the usual IPv6 hex literal representation to put in the "direct-tcpip" channel open request.
2018-05-30 21:36:20 +00:00
pf->socks_state = SOCKS_INITIAL;
pf->socksbuf = strbuf_new();
pf->socksbuf_consumed = 0;
Refactor ssh.c's APIs to x11fwd.c and portfwd.c. The most important change is that, where previously ssh.c held the Socket pointer for each X11 and port forwarding, and the support modules would find their internal state structure by calling sk_get_private_ptr on that Socket, it's now the other way round. ssh.c now directly holds the internal state structure pointer for each forwarding, and when the support module needs the Socket it looks it up in a field of that. This will come in handy when I decouple socket creation from logical forwarding setup, so that X forwardings can delay actually opening a connection to an X server until they look at the authentication data and see which server it has to be. However, while I'm here, I've also taken the opportunity to clean up a few other points, notably error message handling, and also the fact that the same kind of state structure was used for both connection-type and listening-type port forwardings. Now there are separate PortForwarding and PortListener structure types, which seems far more sensible. [originally from svn r10074]
2013-11-17 14:04:41 +00:00
pf->port = 0; /* "hostname" buffer is so far empty */
Dynamic port forwarding by means of a local SOCKS server. Fully supports SOCKS 4, SOCKS 4A and SOCKS 5 (well, actually IPv6 in SOCKS 5 isn't supported, but it'll be no difficulty once I actually get round to it). Thanks to Chas Honton for his `stone soup' patch: I didn't end up actually using any of his code, but it galvanised me into doing it properly myself :-) [originally from svn r3055]
2003-04-05 11:45:21 +00:00
sk_set_frozen(s, 0); /* we want to receive SOCKS _now_! */
Oops - actually check in portfwd.c itself! (Makefile also modified because it's been renamed to fit in 8.3, just in case.) [originally from svn r1177]
2001-08-08 20:53:27 +00:00
} else {
Refactor ssh.c's APIs to x11fwd.c and portfwd.c. The most important change is that, where previously ssh.c held the Socket pointer for each X11 and port forwarding, and the support modules would find their internal state structure by calling sk_get_private_ptr on that Socket, it's now the other way round. ssh.c now directly holds the internal state structure pointer for each forwarding, and when the support module needs the Socket it looks it up in a field of that. This will come in handy when I decouple socket creation from logical forwarding setup, so that X forwardings can delay actually opening a connection to an X server until they look at the authentication data and see which server it has to be. However, while I'm here, I've also taken the opportunity to clean up a few other points, notably error message handling, and also the fact that the same kind of state structure was used for both connection-type and listening-type port forwardings. Now there are separate PortForwarding and PortListener structure types, which seems far more sensible. [originally from svn r10074]
2013-11-17 14:04:41 +00:00
pf->hostname = dupstr(pl->hostname);
pf->port = pl->port;
Server prep: factor out portfwd_raw_new(). This new function contains the core setup for a PortForwarding structure, and should be reusable for any kind of forwarding that will simply be passing data between a local socket and an SSH channel without any tricky modifications. On the server side, X11 and agent forwarding both work exactly like this, so they will find this refactored function useful during setup. The contents of the function was originally part of pfl_accepting, which now does all that by calling the new function. pfl_accepting is not _quite_ doing a simple unmodified forwarding, because it might have to prefix it with a SOCKS exchange; in that situation it rewrites a few fields of the PortForwarding to some less generic values once portfwd_raw_new() has returned.
2018-10-20 21:47:49 +00:00
portfwd_raw_setup(
chan, s,
wrap_lportfwd_open(pl->cl, pf->hostname, pf->port, s, &pf->chan));
Oops - actually check in portfwd.c itself! (Makefile also modified because it's been renamed to fit in 8.3, just in case.) [originally from svn r1177]
2001-08-08 20:53:27 +00:00
}
return 0;
}
Name vtable structure types more consistently. Now they're all called FooVtable, instead of a mixture of that and Foo_vtable.
2018-10-05 06:03:46 +00:00
static const PlugVtable PortListener_plugvt = {
Modernise the Socket/Plug vtable system. Now I've got FROMFIELD, I can rework it so that structures providing an implementation of the Socket or Plug trait no longer have to have the vtable pointer as the very first thing in the structure. In particular, this means that the ProxySocket structure can now directly implement _both_ the Socket and Plug traits, which is always _logically_ how it's worked, but previously it had to be implemented via two separate structs linked to each other.
2018-05-27 08:29:33 +00:00
pfl_log,
pfl_closing,
NULL, /* recv */
NULL, /* send */
pfl_accepting
};
Oops - actually check in portfwd.c itself! (Makefile also modified because it's been renamed to fit in 8.3, just in case.) [originally from svn r1177]
2001-08-08 20:53:27 +00:00
Refactor ssh.c's APIs to x11fwd.c and portfwd.c. The most important change is that, where previously ssh.c held the Socket pointer for each X11 and port forwarding, and the support modules would find their internal state structure by calling sk_get_private_ptr on that Socket, it's now the other way round. ssh.c now directly holds the internal state structure pointer for each forwarding, and when the support module needs the Socket it looks it up in a field of that. This will come in handy when I decouple socket creation from logical forwarding setup, so that X forwardings can delay actually opening a connection to an X server until they look at the authentication data and see which server it has to be. However, while I'm here, I've also taken the opportunity to clean up a few other points, notably error message handling, and also the fact that the same kind of state structure was used for both connection-type and listening-type port forwardings. Now there are separate PortForwarding and PortListener structure types, which seems far more sensible. [originally from svn r10074]
2013-11-17 14:04:41 +00:00
/*
* Add a new port-forwarding listener from srcaddr:port -> desthost:destport.
*
Move port-forwarding setup out of ssh.c. The tree234 storing currently active port forwardings - both local and remote - now lives in portfwd.c, as does the complicated function that updates it based on a Conf listing the new set of desired forwardings. Local port forwardings are passed to ssh.c via the same route as before - once the listening port receives a connection and portfwd.c knows where it should be directed to (in particular, after the SOCKS exchange, if any), it calls ssh_send_port_open. Remote forwardings are now initiated by calling ssh_rportfwd_alloc, which adds an entry to the rportfwds tree (which _is_ still in ssh.c, and still confusingly sorted by a different criterion depending on SSH protocol version) and sends out the appropriate protocol request. ssh_rportfwd_remove cancels one again, sending a protocol request too. Those functions look enough like ssh_{alloc,remove}_sharing_rportfwd that I've merged those into the new pair as well - now allocating an rportfwd allows you to specify either a destination host/port or a sharing context, and returns a handy pointer you can use to cancel the forwarding later.
2018-09-14 16:04:39 +00:00
* desthost == NULL indicates dynamic SOCKS port forwarding.
*
Refactor ssh.c's APIs to x11fwd.c and portfwd.c. The most important change is that, where previously ssh.c held the Socket pointer for each X11 and port forwarding, and the support modules would find their internal state structure by calling sk_get_private_ptr on that Socket, it's now the other way round. ssh.c now directly holds the internal state structure pointer for each forwarding, and when the support module needs the Socket it looks it up in a field of that. This will come in handy when I decouple socket creation from logical forwarding setup, so that X forwardings can delay actually opening a connection to an X server until they look at the authentication data and see which server it has to be. However, while I'm here, I've also taken the opportunity to clean up a few other points, notably error message handling, and also the fact that the same kind of state structure was used for both connection-type and listening-type port forwardings. Now there are separate PortForwarding and PortListener structure types, which seems far more sensible. [originally from svn r10074]
2013-11-17 14:04:41 +00:00
* On success, returns NULL and fills in *pl_ret. On error, returns a
* dynamically allocated error message string.
Oops - actually check in portfwd.c itself! (Makefile also modified because it's been renamed to fit in 8.3, just in case.) [originally from svn r1177]
2001-08-08 20:53:27 +00:00
*/
Add some missing 'const' in pfl_listen.
2018-10-20 21:46:24 +00:00
static char *pfl_listen(const char *desthost, int destport,
const char *srcaddr, int port,
ConnectionLayer *cl, Conf *conf,
Move port-forwarding setup out of ssh.c. The tree234 storing currently active port forwardings - both local and remote - now lives in portfwd.c, as does the complicated function that updates it based on a Conf listing the new set of desired forwardings. Local port forwardings are passed to ssh.c via the same route as before - once the listening port receives a connection and portfwd.c knows where it should be directed to (in particular, after the SOCKS exchange, if any), it calls ssh_send_port_open. Remote forwardings are now initiated by calling ssh_rportfwd_alloc, which adds an entry to the rportfwds tree (which _is_ still in ssh.c, and still confusingly sorted by a different criterion depending on SSH protocol version) and sends out the appropriate protocol request. ssh_rportfwd_remove cancels one again, sending a protocol request too. Those functions look enough like ssh_{alloc,remove}_sharing_rportfwd that I've merged those into the new pair as well - now allocating an rportfwd allows you to specify either a destination host/port or a sharing context, and returns a handy pointer you can use to cancel the forwarding later.
2018-09-14 16:04:39 +00:00
struct PortListener **pl_ret, int address_family)
Oops - actually check in portfwd.c itself! (Makefile also modified because it's been renamed to fit in 8.3, just in case.) [originally from svn r1177]
2001-08-08 20:53:27 +00:00
{
Colin's const-fixing Patch Of Death. Seems to build fine on Windows as well as Unix, so it can go in. [originally from svn r3162]
2003-05-04 14:18:18 +00:00
const char *err;
Refactor ssh.c's APIs to x11fwd.c and portfwd.c. The most important change is that, where previously ssh.c held the Socket pointer for each X11 and port forwarding, and the support modules would find their internal state structure by calling sk_get_private_ptr on that Socket, it's now the other way round. ssh.c now directly holds the internal state structure pointer for each forwarding, and when the support module needs the Socket it looks it up in a field of that. This will come in handy when I decouple socket creation from logical forwarding setup, so that X forwardings can delay actually opening a connection to an X server until they look at the authentication data and see which server it has to be. However, while I'm here, I've also taken the opportunity to clean up a few other points, notably error message handling, and also the fact that the same kind of state structure was used for both connection-type and listening-type port forwardings. Now there are separate PortForwarding and PortListener structure types, which seems far more sensible. [originally from svn r10074]
2013-11-17 14:04:41 +00:00
struct PortListener *pl;
Oops - actually check in portfwd.c itself! (Makefile also modified because it's been renamed to fit in 8.3, just in case.) [originally from svn r1177]
2001-08-08 20:53:27 +00:00
/*
* Open socket.
*/
Refactor ssh.c's APIs to x11fwd.c and portfwd.c. The most important change is that, where previously ssh.c held the Socket pointer for each X11 and port forwarding, and the support modules would find their internal state structure by calling sk_get_private_ptr on that Socket, it's now the other way round. ssh.c now directly holds the internal state structure pointer for each forwarding, and when the support module needs the Socket it looks it up in a field of that. This will come in handy when I decouple socket creation from logical forwarding setup, so that X forwardings can delay actually opening a connection to an X server until they look at the authentication data and see which server it has to be. However, while I'm here, I've also taken the opportunity to clean up a few other points, notably error message handling, and also the fact that the same kind of state structure was used for both connection-type and listening-type port forwardings. Now there are separate PortForwarding and PortListener structure types, which seems far more sensible. [originally from svn r10074]
2013-11-17 14:04:41 +00:00
pl = *pl_ret = new_portlistener_state();
Make Socket and Plug into structs. I think that means that _every_ one of my traitoids is now a struct containing a vtable pointer as one of its fields (albeit sometimes the only field), and never just a bare pointer.
2018-10-05 06:24:16 +00:00
pl->plug.vt = &PortListener_plugvt;
Dynamic port forwarding by means of a local SOCKS server. Fully supports SOCKS 4, SOCKS 4A and SOCKS 5 (well, actually IPv6 in SOCKS 5 isn't supported, but it'll be no difficulty once I actually get round to it). Thanks to Chas Honton for his `stone soup' patch: I didn't end up actually using any of his code, but it galvanised me into doing it properly myself :-) [originally from svn r3055]
2003-04-05 11:45:21 +00:00
if (desthost) {
Refactor ssh.c's APIs to x11fwd.c and portfwd.c. The most important change is that, where previously ssh.c held the Socket pointer for each X11 and port forwarding, and the support modules would find their internal state structure by calling sk_get_private_ptr on that Socket, it's now the other way round. ssh.c now directly holds the internal state structure pointer for each forwarding, and when the support module needs the Socket it looks it up in a field of that. This will come in handy when I decouple socket creation from logical forwarding setup, so that X forwardings can delay actually opening a connection to an X server until they look at the authentication data and see which server it has to be. However, while I'm here, I've also taken the opportunity to clean up a few other points, notably error message handling, and also the fact that the same kind of state structure was used for both connection-type and listening-type port forwardings. Now there are separate PortForwarding and PortListener structure types, which seems far more sensible. [originally from svn r10074]
2013-11-17 14:04:41 +00:00
pl->hostname = dupstr(desthost);
pl->port = destport;
Adopt C99 <stdbool.h>'s true/false. This commit includes <stdbool.h> from defs.h and deletes my traditional definitions of TRUE and FALSE, but other than that, it's a 100% mechanical search-and-replace transforming all uses of TRUE and FALSE into the C99-standardised lowercase spellings. No actual types are changed in this commit; that will come next. This is just getting the noise out of the way, so that subsequent commits can have a higher proportion of signal.
2018-10-29 19:50:29 +00:00
pl->is_dynamic = false;
Dynamic port forwarding by means of a local SOCKS server. Fully supports SOCKS 4, SOCKS 4A and SOCKS 5 (well, actually IPv6 in SOCKS 5 isn't supported, but it'll be no difficulty once I actually get round to it). Thanks to Chas Honton for his `stone soup' patch: I didn't end up actually using any of his code, but it galvanised me into doing it properly myself :-) [originally from svn r3055]
2003-04-05 11:45:21 +00:00
} else
Adopt C99 <stdbool.h>'s true/false. This commit includes <stdbool.h> from defs.h and deletes my traditional definitions of TRUE and FALSE, but other than that, it's a 100% mechanical search-and-replace transforming all uses of TRUE and FALSE into the C99-standardised lowercase spellings. No actual types are changed in this commit; that will come next. This is just getting the noise out of the way, so that subsequent commits can have a higher proportion of signal.
2018-10-29 19:50:29 +00:00
pl->is_dynamic = true;
New abstraction 'ConnectionLayer'. This is a vtable that wraps up all the functionality required from the SSH connection layer by associated modules like port forwarding and connection sharing. This extra layer of indirection adds nothing useful right now, but when I later separate the SSH-1 and SSH-2 connection layer implementations, it will be convenient for each one to be able to implement this vtable in terms of its own internal data structures. To simplify this vtable, I've moved a lot of the logging duties relating to connection sharing out of ssh.c into sshshare.c: now it handles nearly all the logging itself relating to setting up connection sharing in the first place and downstreams connecting and disconnecting. The only exception is the 'Reusing a shared connection' announcement in the console window, which is now done in ssh.c by detecting downstream status immediately after setup.
2018-09-17 11:14:00 +00:00
pl->cl = cl;
Refactor ssh.c's APIs to x11fwd.c and portfwd.c. The most important change is that, where previously ssh.c held the Socket pointer for each X11 and port forwarding, and the support modules would find their internal state structure by calling sk_get_private_ptr on that Socket, it's now the other way round. ssh.c now directly holds the internal state structure pointer for each forwarding, and when the support module needs the Socket it looks it up in a field of that. This will come in handy when I decouple socket creation from logical forwarding setup, so that X forwardings can delay actually opening a connection to an X server until they look at the authentication data and see which server it has to be. However, while I'm here, I've also taken the opportunity to clean up a few other points, notably error message handling, and also the fact that the same kind of state structure was used for both connection-type and listening-type port forwardings. Now there are separate PortForwarding and PortListener structure types, which seems far more sensible. [originally from svn r10074]
2013-11-17 14:04:41 +00:00
Make Socket and Plug into structs. I think that means that _every_ one of my traitoids is now a struct containing a vtable pointer as one of its fields (albeit sometimes the only field), and never just a bare pointer.
2018-10-05 06:24:16 +00:00
pl->s = new_listener(srcaddr, port, &pl->plug,
Refactor ssh.c's APIs to x11fwd.c and portfwd.c. The most important change is that, where previously ssh.c held the Socket pointer for each X11 and port forwarding, and the support modules would find their internal state structure by calling sk_get_private_ptr on that Socket, it's now the other way round. ssh.c now directly holds the internal state structure pointer for each forwarding, and when the support module needs the Socket it looks it up in a field of that. This will come in handy when I decouple socket creation from logical forwarding setup, so that X forwardings can delay actually opening a connection to an X server until they look at the authentication data and see which server it has to be. However, while I'm here, I've also taken the opportunity to clean up a few other points, notably error message handling, and also the fact that the same kind of state structure was used for both connection-type and listening-type port forwardings. Now there are separate PortForwarding and PortListener structure types, which seems far more sensible. [originally from svn r10074]
2013-11-17 14:04:41 +00:00
!conf_get_int(conf, CONF_lport_acceptall),
conf, address_family);
if ((err = sk_socket_error(pl->s)) != NULL) {
char *err_ret = dupstr(err);
sk_close(pl->s);
free_portlistener_state(pl);
*pl_ret = NULL;
return err_ret;
Oops - actually check in portfwd.c itself! (Makefile also modified because it's been renamed to fit in 8.3, just in case.) [originally from svn r1177]
2001-08-08 20:53:27 +00:00
}
return NULL;
}
Replace enum+union of local channel types with a vtable. There's now an interface called 'Channel', which handles the local side of an SSH connection-layer channel, in terms of knowing where to send incoming channel data to, whether to close the channel, etc. Channel and the previous 'struct ssh_channel' mutually refer. The latter contains all the SSH-specific parts, and as much of the common logic as possible: in particular, Channel doesn't have to know anything about SSH packet formats, or which SSH protocol version is in use, or deal with all the fiddly stuff about window sizes - with the exception that x11fwd.c's implementation of it does have to be able to ask for a small fixed initial window size for the bodgy system that distinguishes upstream from downstream X forwardings. I've taken the opportunity to move the code implementing the detailed behaviour of agent forwarding out of ssh.c, now that all of it is on the far side of a uniform interface. (This also means that if I later implement agent forwarding directly to a Unix socket as an alternative, it'll be a matter of changing just the one call to agentf_new() that makes the Channel to plug into a forwarding.)
2018-09-12 14:03:47 +00:00
static char *pfd_log_close_msg(Channel *chan)
{
return dupstr("Forwarded port closed");
}
static void pfd_close(struct PortForwarding *pf)
Oops - actually check in portfwd.c itself! (Makefile also modified because it's been renamed to fit in 8.3, just in case.) [originally from svn r1177]
2001-08-08 20:53:27 +00:00
{
Refactor ssh.c's APIs to x11fwd.c and portfwd.c. The most important change is that, where previously ssh.c held the Socket pointer for each X11 and port forwarding, and the support modules would find their internal state structure by calling sk_get_private_ptr on that Socket, it's now the other way round. ssh.c now directly holds the internal state structure pointer for each forwarding, and when the support module needs the Socket it looks it up in a field of that. This will come in handy when I decouple socket creation from logical forwarding setup, so that X forwardings can delay actually opening a connection to an X server until they look at the authentication data and see which server it has to be. However, while I'm here, I've also taken the opportunity to clean up a few other points, notably error message handling, and also the fact that the same kind of state structure was used for both connection-type and listening-type port forwardings. Now there are separate PortForwarding and PortListener structure types, which seems far more sensible. [originally from svn r10074]
2013-11-17 14:04:41 +00:00
if (!pf)
Oops - actually check in portfwd.c itself! (Makefile also modified because it's been renamed to fit in 8.3, just in case.) [originally from svn r1177]
2001-08-08 20:53:27 +00:00
return;
Refactor ssh.c's APIs to x11fwd.c and portfwd.c. The most important change is that, where previously ssh.c held the Socket pointer for each X11 and port forwarding, and the support modules would find their internal state structure by calling sk_get_private_ptr on that Socket, it's now the other way round. ssh.c now directly holds the internal state structure pointer for each forwarding, and when the support module needs the Socket it looks it up in a field of that. This will come in handy when I decouple socket creation from logical forwarding setup, so that X forwardings can delay actually opening a connection to an X server until they look at the authentication data and see which server it has to be. However, while I'm here, I've also taken the opportunity to clean up a few other points, notably error message handling, and also the fact that the same kind of state structure was used for both connection-type and listening-type port forwardings. Now there are separate PortForwarding and PortListener structure types, which seems far more sensible. [originally from svn r10074]
2013-11-17 14:04:41 +00:00
sk_close(pf->s);
free_portfwd_state(pf);
Oops - actually check in portfwd.c itself! (Makefile also modified because it's been renamed to fit in 8.3, just in case.) [originally from svn r1177]
2001-08-08 20:53:27 +00:00
}
SSH port forwarding is now configurable in mid-session. After doing Change Settings, the port forwarding setup function is run again, and tags all existing port forwardings as `do not keep'. Then it iterates through the config in the normal way; when it encounters a port forwarding which is already in the tree, it tags it `keep' rather than setting it up from scratch. Finally, it goes through the tree and removes any that haven't been labelled `keep'. Hence, editing the list of forwardings in Change Settings has the effect of cancelling any forwardings you remove, and adding any new ones. The SSH panel now appears in the reconfig box, and is empty apart from a message explaining that it has to be there for subpanels of it to exist. Better wording for this message would be welcome. [originally from svn r5030]
2004-12-28 14:07:05 +00:00
/*
* Terminate a listener.
*/
Move port-forwarding setup out of ssh.c. The tree234 storing currently active port forwardings - both local and remote - now lives in portfwd.c, as does the complicated function that updates it based on a Conf listing the new set of desired forwardings. Local port forwardings are passed to ssh.c via the same route as before - once the listening port receives a connection and portfwd.c knows where it should be directed to (in particular, after the SOCKS exchange, if any), it calls ssh_send_port_open. Remote forwardings are now initiated by calling ssh_rportfwd_alloc, which adds an entry to the rportfwds tree (which _is_ still in ssh.c, and still confusingly sorted by a different criterion depending on SSH protocol version) and sends out the appropriate protocol request. ssh_rportfwd_remove cancels one again, sending a protocol request too. Those functions look enough like ssh_{alloc,remove}_sharing_rportfwd that I've merged those into the new pair as well - now allocating an rportfwd allows you to specify either a destination host/port or a sharing context, and returns a handy pointer you can use to cancel the forwarding later.
2018-09-14 16:04:39 +00:00
static void pfl_terminate(struct PortListener *pl)
SSH port forwarding is now configurable in mid-session. After doing Change Settings, the port forwarding setup function is run again, and tags all existing port forwardings as `do not keep'. Then it iterates through the config in the normal way; when it encounters a port forwarding which is already in the tree, it tags it `keep' rather than setting it up from scratch. Finally, it goes through the tree and removes any that haven't been labelled `keep'. Hence, editing the list of forwardings in Change Settings has the effect of cancelling any forwardings you remove, and adding any new ones. The SSH panel now appears in the reconfig box, and is empty apart from a message explaining that it has to be there for subpanels of it to exist. Better wording for this message would be welcome. [originally from svn r5030]
2004-12-28 14:07:05 +00:00
{
Refactor ssh.c's APIs to x11fwd.c and portfwd.c. The most important change is that, where previously ssh.c held the Socket pointer for each X11 and port forwarding, and the support modules would find their internal state structure by calling sk_get_private_ptr on that Socket, it's now the other way round. ssh.c now directly holds the internal state structure pointer for each forwarding, and when the support module needs the Socket it looks it up in a field of that. This will come in handy when I decouple socket creation from logical forwarding setup, so that X forwardings can delay actually opening a connection to an X server until they look at the authentication data and see which server it has to be. However, while I'm here, I've also taken the opportunity to clean up a few other points, notably error message handling, and also the fact that the same kind of state structure was used for both connection-type and listening-type port forwardings. Now there are separate PortForwarding and PortListener structure types, which seems far more sensible. [originally from svn r10074]
2013-11-17 14:04:41 +00:00
if (!pl)
return;
sk_close(pl->s);
free_portlistener_state(pl);
SSH port forwarding is now configurable in mid-session. After doing Change Settings, the port forwarding setup function is run again, and tags all existing port forwardings as `do not keep'. Then it iterates through the config in the normal way; when it encounters a port forwarding which is already in the tree, it tags it `keep' rather than setting it up from scratch. Finally, it goes through the tree and removes any that haven't been labelled `keep'. Hence, editing the list of forwardings in Change Settings has the effect of cancelling any forwardings you remove, and adding any new ones. The SSH panel now appears in the reconfig box, and is empty apart from a message explaining that it has to be there for subpanels of it to exist. Better wording for this message would be welcome. [originally from svn r5030]
2004-12-28 14:07:05 +00:00
}
Replace enum+union of local channel types with a vtable. There's now an interface called 'Channel', which handles the local side of an SSH connection-layer channel, in terms of knowing where to send incoming channel data to, whether to close the channel, etc. Channel and the previous 'struct ssh_channel' mutually refer. The latter contains all the SSH-specific parts, and as much of the common logic as possible: in particular, Channel doesn't have to know anything about SSH packet formats, or which SSH protocol version is in use, or deal with all the fiddly stuff about window sizes - with the exception that x11fwd.c's implementation of it does have to be able to ask for a small fixed initial window size for the bodgy system that distinguishes upstream from downstream X forwardings. I've taken the opportunity to move the code implementing the detailed behaviour of agent forwarding out of ssh.c, now that all of it is on the far side of a uniform interface. (This also means that if I later implement agent forwarding directly to a Unix socket as an alternative, it'll be a matter of changing just the one call to agentf_new() that makes the Channel to plug into a forwarding.)
2018-09-12 14:03:47 +00:00
static void pfd_set_input_wanted(Channel *chan, int wanted)
Extensive changes that _should_ fix the socket buffering problems, by ceasing to listen on input channels if the corresponding output channel isn't accepting data. Has had basic check-I-didn't-actually- break-anything-too-badly testing, but hasn't been genuinely tested in stress conditions (because concocting stress conditions is non- trivial). [originally from svn r1198]
2001-08-25 17:09:23 +00:00
{
Replace enum+union of local channel types with a vtable. There's now an interface called 'Channel', which handles the local side of an SSH connection-layer channel, in terms of knowing where to send incoming channel data to, whether to close the channel, etc. Channel and the previous 'struct ssh_channel' mutually refer. The latter contains all the SSH-specific parts, and as much of the common logic as possible: in particular, Channel doesn't have to know anything about SSH packet formats, or which SSH protocol version is in use, or deal with all the fiddly stuff about window sizes - with the exception that x11fwd.c's implementation of it does have to be able to ask for a small fixed initial window size for the bodgy system that distinguishes upstream from downstream X forwardings. I've taken the opportunity to move the code implementing the detailed behaviour of agent forwarding out of ssh.c, now that all of it is on the far side of a uniform interface. (This also means that if I later implement agent forwarding directly to a Unix socket as an alternative, it'll be a matter of changing just the one call to agentf_new() that makes the Channel to plug into a forwarding.)
2018-09-12 14:03:47 +00:00
assert(chan->vt == &PortForwarding_channelvt);
Rename FROMFIELD to 'container_of'. Ian Jackson points out that the Linux kernel has a macro of this name with the same purpose, and suggests that it's a good idea to use the same name as they do, so that at least some people reading one code base might recognise it from the other. I never really thought very hard about what order FROMFIELD's parameters should go in, and therefore I'm pleasantly surprised to find that my order agrees with the kernel's, so I don't have to permute every call site as part of making this change :-)
2018-10-05 22:49:08 +00:00
PortForwarding *pf = container_of(chan, PortForwarding, chan);
Replace enum+union of local channel types with a vtable. There's now an interface called 'Channel', which handles the local side of an SSH connection-layer channel, in terms of knowing where to send incoming channel data to, whether to close the channel, etc. Channel and the previous 'struct ssh_channel' mutually refer. The latter contains all the SSH-specific parts, and as much of the common logic as possible: in particular, Channel doesn't have to know anything about SSH packet formats, or which SSH protocol version is in use, or deal with all the fiddly stuff about window sizes - with the exception that x11fwd.c's implementation of it does have to be able to ask for a small fixed initial window size for the bodgy system that distinguishes upstream from downstream X forwardings. I've taken the opportunity to move the code implementing the detailed behaviour of agent forwarding out of ssh.c, now that all of it is on the far side of a uniform interface. (This also means that if I later implement agent forwarding directly to a Unix socket as an alternative, it'll be a matter of changing just the one call to agentf_new() that makes the Channel to plug into a forwarding.)
2018-09-12 14:03:47 +00:00
pf->input_wanted = wanted;
sk_set_frozen(pf->s, !pf->input_wanted);
Extensive changes that _should_ fix the socket buffering problems, by ceasing to listen on input channels if the corresponding output channel isn't accepting data. Has had basic check-I-didn't-actually- break-anything-too-badly testing, but hasn't been genuinely tested in stress conditions (because concocting stress conditions is non- trivial). [originally from svn r1198]
2001-08-25 17:09:23 +00:00
}
Replace enum+union of local channel types with a vtable. There's now an interface called 'Channel', which handles the local side of an SSH connection-layer channel, in terms of knowing where to send incoming channel data to, whether to close the channel, etc. Channel and the previous 'struct ssh_channel' mutually refer. The latter contains all the SSH-specific parts, and as much of the common logic as possible: in particular, Channel doesn't have to know anything about SSH packet formats, or which SSH protocol version is in use, or deal with all the fiddly stuff about window sizes - with the exception that x11fwd.c's implementation of it does have to be able to ask for a small fixed initial window size for the bodgy system that distinguishes upstream from downstream X forwardings. I've taken the opportunity to move the code implementing the detailed behaviour of agent forwarding out of ssh.c, now that all of it is on the far side of a uniform interface. (This also means that if I later implement agent forwarding directly to a Unix socket as an alternative, it'll be a matter of changing just the one call to agentf_new() that makes the Channel to plug into a forwarding.)
2018-09-12 14:03:47 +00:00
static void pfd_chan_free(Channel *chan)
Extensive changes that _should_ fix the socket buffering problems, by ceasing to listen on input channels if the corresponding output channel isn't accepting data. Has had basic check-I-didn't-actually- break-anything-too-badly testing, but hasn't been genuinely tested in stress conditions (because concocting stress conditions is non- trivial). [originally from svn r1198]
2001-08-25 17:09:23 +00:00
{
Replace enum+union of local channel types with a vtable. There's now an interface called 'Channel', which handles the local side of an SSH connection-layer channel, in terms of knowing where to send incoming channel data to, whether to close the channel, etc. Channel and the previous 'struct ssh_channel' mutually refer. The latter contains all the SSH-specific parts, and as much of the common logic as possible: in particular, Channel doesn't have to know anything about SSH packet formats, or which SSH protocol version is in use, or deal with all the fiddly stuff about window sizes - with the exception that x11fwd.c's implementation of it does have to be able to ask for a small fixed initial window size for the bodgy system that distinguishes upstream from downstream X forwardings. I've taken the opportunity to move the code implementing the detailed behaviour of agent forwarding out of ssh.c, now that all of it is on the far side of a uniform interface. (This also means that if I later implement agent forwarding directly to a Unix socket as an alternative, it'll be a matter of changing just the one call to agentf_new() that makes the Channel to plug into a forwarding.)
2018-09-12 14:03:47 +00:00
assert(chan->vt == &PortForwarding_channelvt);
Rename FROMFIELD to 'container_of'. Ian Jackson points out that the Linux kernel has a macro of this name with the same purpose, and suggests that it's a good idea to use the same name as they do, so that at least some people reading one code base might recognise it from the other. I never really thought very hard about what order FROMFIELD's parameters should go in, and therefore I'm pleasantly surprised to find that my order agrees with the kernel's, so I don't have to permute every call site as part of making this change :-)
2018-10-05 22:49:08 +00:00
PortForwarding *pf = container_of(chan, PortForwarding, chan);
Replace enum+union of local channel types with a vtable. There's now an interface called 'Channel', which handles the local side of an SSH connection-layer channel, in terms of knowing where to send incoming channel data to, whether to close the channel, etc. Channel and the previous 'struct ssh_channel' mutually refer. The latter contains all the SSH-specific parts, and as much of the common logic as possible: in particular, Channel doesn't have to know anything about SSH packet formats, or which SSH protocol version is in use, or deal with all the fiddly stuff about window sizes - with the exception that x11fwd.c's implementation of it does have to be able to ask for a small fixed initial window size for the bodgy system that distinguishes upstream from downstream X forwardings. I've taken the opportunity to move the code implementing the detailed behaviour of agent forwarding out of ssh.c, now that all of it is on the far side of a uniform interface. (This also means that if I later implement agent forwarding directly to a Unix socket as an alternative, it'll be a matter of changing just the one call to agentf_new() that makes the Channel to plug into a forwarding.)
2018-09-12 14:03:47 +00:00
pfd_close(pf);
Extensive changes that _should_ fix the socket buffering problems, by ceasing to listen on input channels if the corresponding output channel isn't accepting data. Has had basic check-I-didn't-actually- break-anything-too-badly testing, but hasn't been genuinely tested in stress conditions (because concocting stress conditions is non- trivial). [originally from svn r1198]
2001-08-25 17:09:23 +00:00
}
Oops - actually check in portfwd.c itself! (Makefile also modified because it's been renamed to fit in 8.3, just in case.) [originally from svn r1177]
2001-08-08 20:53:27 +00:00
/*
* Called to send data down the raw connection.
*/
Replace enum+union of local channel types with a vtable. There's now an interface called 'Channel', which handles the local side of an SSH connection-layer channel, in terms of knowing where to send incoming channel data to, whether to close the channel, etc. Channel and the previous 'struct ssh_channel' mutually refer. The latter contains all the SSH-specific parts, and as much of the common logic as possible: in particular, Channel doesn't have to know anything about SSH packet formats, or which SSH protocol version is in use, or deal with all the fiddly stuff about window sizes - with the exception that x11fwd.c's implementation of it does have to be able to ask for a small fixed initial window size for the bodgy system that distinguishes upstream from downstream X forwardings. I've taken the opportunity to move the code implementing the detailed behaviour of agent forwarding out of ssh.c, now that all of it is on the far side of a uniform interface. (This also means that if I later implement agent forwarding directly to a Unix socket as an alternative, it'll be a matter of changing just the one call to agentf_new() that makes the Channel to plug into a forwarding.)
2018-09-12 14:03:47 +00:00
static int pfd_send(Channel *chan, int is_stderr, const void *data, int len)
Oops - actually check in portfwd.c itself! (Makefile also modified because it's been renamed to fit in 8.3, just in case.) [originally from svn r1177]
2001-08-08 20:53:27 +00:00
{
Replace enum+union of local channel types with a vtable. There's now an interface called 'Channel', which handles the local side of an SSH connection-layer channel, in terms of knowing where to send incoming channel data to, whether to close the channel, etc. Channel and the previous 'struct ssh_channel' mutually refer. The latter contains all the SSH-specific parts, and as much of the common logic as possible: in particular, Channel doesn't have to know anything about SSH packet formats, or which SSH protocol version is in use, or deal with all the fiddly stuff about window sizes - with the exception that x11fwd.c's implementation of it does have to be able to ask for a small fixed initial window size for the bodgy system that distinguishes upstream from downstream X forwardings. I've taken the opportunity to move the code implementing the detailed behaviour of agent forwarding out of ssh.c, now that all of it is on the far side of a uniform interface. (This also means that if I later implement agent forwarding directly to a Unix socket as an alternative, it'll be a matter of changing just the one call to agentf_new() that makes the Channel to plug into a forwarding.)
2018-09-12 14:03:47 +00:00
assert(chan->vt == &PortForwarding_channelvt);
Rename FROMFIELD to 'container_of'. Ian Jackson points out that the Linux kernel has a macro of this name with the same purpose, and suggests that it's a good idea to use the same name as they do, so that at least some people reading one code base might recognise it from the other. I never really thought very hard about what order FROMFIELD's parameters should go in, and therefore I'm pleasantly surprised to find that my order agrees with the kernel's, so I don't have to permute every call site as part of making this change :-)
2018-10-05 22:49:08 +00:00
PortForwarding *pf = container_of(chan, PortForwarding, chan);
Refactor ssh.c's APIs to x11fwd.c and portfwd.c. The most important change is that, where previously ssh.c held the Socket pointer for each X11 and port forwarding, and the support modules would find their internal state structure by calling sk_get_private_ptr on that Socket, it's now the other way round. ssh.c now directly holds the internal state structure pointer for each forwarding, and when the support module needs the Socket it looks it up in a field of that. This will come in handy when I decouple socket creation from logical forwarding setup, so that X forwardings can delay actually opening a connection to an X server until they look at the authentication data and see which server it has to be. However, while I'm here, I've also taken the opportunity to clean up a few other points, notably error message handling, and also the fact that the same kind of state structure was used for both connection-type and listening-type port forwardings. Now there are separate PortForwarding and PortListener structure types, which seems far more sensible. [originally from svn r10074]
2013-11-17 14:04:41 +00:00
return sk_write(pf->s, data, len);
Oops - actually check in portfwd.c itself! (Makefile also modified because it's been renamed to fit in 8.3, just in case.) [originally from svn r1177]
2001-08-08 20:53:27 +00:00
}
Replace enum+union of local channel types with a vtable. There's now an interface called 'Channel', which handles the local side of an SSH connection-layer channel, in terms of knowing where to send incoming channel data to, whether to close the channel, etc. Channel and the previous 'struct ssh_channel' mutually refer. The latter contains all the SSH-specific parts, and as much of the common logic as possible: in particular, Channel doesn't have to know anything about SSH packet formats, or which SSH protocol version is in use, or deal with all the fiddly stuff about window sizes - with the exception that x11fwd.c's implementation of it does have to be able to ask for a small fixed initial window size for the bodgy system that distinguishes upstream from downstream X forwardings. I've taken the opportunity to move the code implementing the detailed behaviour of agent forwarding out of ssh.c, now that all of it is on the far side of a uniform interface. (This also means that if I later implement agent forwarding directly to a Unix socket as an alternative, it'll be a matter of changing just the one call to agentf_new() that makes the Channel to plug into a forwarding.)
2018-09-12 14:03:47 +00:00
static void pfd_send_eof(Channel *chan)
Revamp of EOF handling in all network connections, pipes and other data channels. Should comprehensively fix 'half-closed', in principle, though it's a big and complicated change and so there's a good chance I've made at least one mistake somewhere. All connections should now be rigorous about propagating end-of-file (or end-of-data-stream, or socket shutdown, or whatever) independently in both directions, except in frontends with no mechanism for sending explicit EOF (e.g. interactive terminal windows) or backends which are basically always used for interactive sessions so it's unlikely that an application would be depending on independent EOF (telnet, rlogin). EOF should now never accidentally be sent while there's still buffered data to go out before it. (May help fix 'portfwd-corrupt', and also I noticed recently that the ssh main session channel can accidentally have MSG_EOF sent before the output bufchain is clear, leading to embarrassment when it subsequently does send the output). [originally from svn r9279]
2011-09-13 11:44:03 +00:00
{
Replace enum+union of local channel types with a vtable. There's now an interface called 'Channel', which handles the local side of an SSH connection-layer channel, in terms of knowing where to send incoming channel data to, whether to close the channel, etc. Channel and the previous 'struct ssh_channel' mutually refer. The latter contains all the SSH-specific parts, and as much of the common logic as possible: in particular, Channel doesn't have to know anything about SSH packet formats, or which SSH protocol version is in use, or deal with all the fiddly stuff about window sizes - with the exception that x11fwd.c's implementation of it does have to be able to ask for a small fixed initial window size for the bodgy system that distinguishes upstream from downstream X forwardings. I've taken the opportunity to move the code implementing the detailed behaviour of agent forwarding out of ssh.c, now that all of it is on the far side of a uniform interface. (This also means that if I later implement agent forwarding directly to a Unix socket as an alternative, it'll be a matter of changing just the one call to agentf_new() that makes the Channel to plug into a forwarding.)
2018-09-12 14:03:47 +00:00
assert(chan->vt == &PortForwarding_channelvt);
Rename FROMFIELD to 'container_of'. Ian Jackson points out that the Linux kernel has a macro of this name with the same purpose, and suggests that it's a good idea to use the same name as they do, so that at least some people reading one code base might recognise it from the other. I never really thought very hard about what order FROMFIELD's parameters should go in, and therefore I'm pleasantly surprised to find that my order agrees with the kernel's, so I don't have to permute every call site as part of making this change :-)
2018-10-05 22:49:08 +00:00
PortForwarding *pf = container_of(chan, PortForwarding, chan);
Refactor ssh.c's APIs to x11fwd.c and portfwd.c. The most important change is that, where previously ssh.c held the Socket pointer for each X11 and port forwarding, and the support modules would find their internal state structure by calling sk_get_private_ptr on that Socket, it's now the other way round. ssh.c now directly holds the internal state structure pointer for each forwarding, and when the support module needs the Socket it looks it up in a field of that. This will come in handy when I decouple socket creation from logical forwarding setup, so that X forwardings can delay actually opening a connection to an X server until they look at the authentication data and see which server it has to be. However, while I'm here, I've also taken the opportunity to clean up a few other points, notably error message handling, and also the fact that the same kind of state structure was used for both connection-type and listening-type port forwardings. Now there are separate PortForwarding and PortListener structure types, which seems far more sensible. [originally from svn r10074]
2013-11-17 14:04:41 +00:00
sk_write_eof(pf->s);
Revamp of EOF handling in all network connections, pipes and other data channels. Should comprehensively fix 'half-closed', in principle, though it's a big and complicated change and so there's a good chance I've made at least one mistake somewhere. All connections should now be rigorous about propagating end-of-file (or end-of-data-stream, or socket shutdown, or whatever) independently in both directions, except in frontends with no mechanism for sending explicit EOF (e.g. interactive terminal windows) or backends which are basically always used for interactive sessions so it's unlikely that an application would be depending on independent EOF (telnet, rlogin). EOF should now never accidentally be sent while there's still buffered data to go out before it. (May help fix 'portfwd-corrupt', and also I noticed recently that the ssh main session channel can accidentally have MSG_EOF sent before the output bufchain is clear, leading to embarrassment when it subsequently does send the output). [originally from svn r9279]
2011-09-13 11:44:03 +00:00
}
Oops - actually check in portfwd.c itself! (Makefile also modified because it's been renamed to fit in 8.3, just in case.) [originally from svn r1177]
2001-08-08 20:53:27 +00:00
Replace enum+union of local channel types with a vtable. There's now an interface called 'Channel', which handles the local side of an SSH connection-layer channel, in terms of knowing where to send incoming channel data to, whether to close the channel, etc. Channel and the previous 'struct ssh_channel' mutually refer. The latter contains all the SSH-specific parts, and as much of the common logic as possible: in particular, Channel doesn't have to know anything about SSH packet formats, or which SSH protocol version is in use, or deal with all the fiddly stuff about window sizes - with the exception that x11fwd.c's implementation of it does have to be able to ask for a small fixed initial window size for the bodgy system that distinguishes upstream from downstream X forwardings. I've taken the opportunity to move the code implementing the detailed behaviour of agent forwarding out of ssh.c, now that all of it is on the far side of a uniform interface. (This also means that if I later implement agent forwarding directly to a Unix socket as an alternative, it'll be a matter of changing just the one call to agentf_new() that makes the Channel to plug into a forwarding.)
2018-09-12 14:03:47 +00:00
static void pfd_open_confirmation(Channel *chan)
Oops - actually check in portfwd.c itself! (Makefile also modified because it's been renamed to fit in 8.3, just in case.) [originally from svn r1177]
2001-08-08 20:53:27 +00:00
{
Replace enum+union of local channel types with a vtable. There's now an interface called 'Channel', which handles the local side of an SSH connection-layer channel, in terms of knowing where to send incoming channel data to, whether to close the channel, etc. Channel and the previous 'struct ssh_channel' mutually refer. The latter contains all the SSH-specific parts, and as much of the common logic as possible: in particular, Channel doesn't have to know anything about SSH packet formats, or which SSH protocol version is in use, or deal with all the fiddly stuff about window sizes - with the exception that x11fwd.c's implementation of it does have to be able to ask for a small fixed initial window size for the bodgy system that distinguishes upstream from downstream X forwardings. I've taken the opportunity to move the code implementing the detailed behaviour of agent forwarding out of ssh.c, now that all of it is on the far side of a uniform interface. (This also means that if I later implement agent forwarding directly to a Unix socket as an alternative, it'll be a matter of changing just the one call to agentf_new() that makes the Channel to plug into a forwarding.)
2018-09-12 14:03:47 +00:00
assert(chan->vt == &PortForwarding_channelvt);
Rename FROMFIELD to 'container_of'. Ian Jackson points out that the Linux kernel has a macro of this name with the same purpose, and suggests that it's a good idea to use the same name as they do, so that at least some people reading one code base might recognise it from the other. I never really thought very hard about what order FROMFIELD's parameters should go in, and therefore I'm pleasantly surprised to find that my order agrees with the kernel's, so I don't have to permute every call site as part of making this change :-)
2018-10-05 22:49:08 +00:00
PortForwarding *pf = container_of(chan, PortForwarding, chan);
Oops - actually check in portfwd.c itself! (Makefile also modified because it's been renamed to fit in 8.3, just in case.) [originally from svn r1177]
2001-08-08 20:53:27 +00:00
Refactor ssh.c's APIs to x11fwd.c and portfwd.c. The most important change is that, where previously ssh.c held the Socket pointer for each X11 and port forwarding, and the support modules would find their internal state structure by calling sk_get_private_ptr on that Socket, it's now the other way round. ssh.c now directly holds the internal state structure pointer for each forwarding, and when the support module needs the Socket it looks it up in a field of that. This will come in handy when I decouple socket creation from logical forwarding setup, so that X forwardings can delay actually opening a connection to an X server until they look at the authentication data and see which server it has to be. However, while I'm here, I've also taken the opportunity to clean up a few other points, notably error message handling, and also the fact that the same kind of state structure was used for both connection-type and listening-type port forwardings. Now there are separate PortForwarding and PortListener structure types, which seems far more sensible. [originally from svn r10074]
2013-11-17 14:04:41 +00:00
pf->ready = 1;
sk_set_frozen(pf->s, 0);
sk_write(pf->s, NULL, 0);
Rewrite SOCKS client code using BinarySource. I've also replaced the entire SOCKS state machine whose states were barely-documented literal integers with one that uses an actual enum. I think the result is a great deal clearer. In the course of this rewrite I noticed that PuTTY's dynamic port forwarding had never got round to supporting the SOCKS5 IPv6 address format - though there was a FIXME comment saying it ought to. So now it does: if a SOCKS5 client provides a binary IPv6 address (which PuTTY's _own_ SOCKS5 client, in proxy.c, is quite capable of doing!), then that will be translated into the usual IPv6 hex literal representation to put in the "direct-tcpip" channel open request.
2018-05-30 21:36:20 +00:00
if (pf->socksbuf) {
sshfwd_write(pf->c, pf->socksbuf->u + pf->socksbuf_consumed,
pf->socksbuf->len - pf->socksbuf_consumed);
strbuf_free(pf->socksbuf);
pf->socksbuf = NULL;
Dynamic port forwarding by means of a local SOCKS server. Fully supports SOCKS 4, SOCKS 4A and SOCKS 5 (well, actually IPv6 in SOCKS 5 isn't supported, but it'll be no difficulty once I actually get round to it). Thanks to Chas Honton for his `stone soup' patch: I didn't end up actually using any of his code, but it galvanised me into doing it properly myself :-) [originally from svn r3055]
2003-04-05 11:45:21 +00:00
}
Oops - actually check in portfwd.c itself! (Makefile also modified because it's been renamed to fit in 8.3, just in case.) [originally from svn r1177]
2001-08-08 20:53:27 +00:00
}
Replace enum+union of local channel types with a vtable. There's now an interface called 'Channel', which handles the local side of an SSH connection-layer channel, in terms of knowing where to send incoming channel data to, whether to close the channel, etc. Channel and the previous 'struct ssh_channel' mutually refer. The latter contains all the SSH-specific parts, and as much of the common logic as possible: in particular, Channel doesn't have to know anything about SSH packet formats, or which SSH protocol version is in use, or deal with all the fiddly stuff about window sizes - with the exception that x11fwd.c's implementation of it does have to be able to ask for a small fixed initial window size for the bodgy system that distinguishes upstream from downstream X forwardings. I've taken the opportunity to move the code implementing the detailed behaviour of agent forwarding out of ssh.c, now that all of it is on the far side of a uniform interface. (This also means that if I later implement agent forwarding directly to a Unix socket as an alternative, it'll be a matter of changing just the one call to agentf_new() that makes the Channel to plug into a forwarding.)
2018-09-12 14:03:47 +00:00
static void pfd_open_failure(Channel *chan, const char *errtext)
{
assert(chan->vt == &PortForwarding_channelvt);
Rename FROMFIELD to 'container_of'. Ian Jackson points out that the Linux kernel has a macro of this name with the same purpose, and suggests that it's a good idea to use the same name as they do, so that at least some people reading one code base might recognise it from the other. I never really thought very hard about what order FROMFIELD's parameters should go in, and therefore I'm pleasantly surprised to find that my order agrees with the kernel's, so I don't have to permute every call site as part of making this change :-)
2018-10-05 22:49:08 +00:00
PortForwarding *pf = container_of(chan, PortForwarding, chan);
Replace enum+union of local channel types with a vtable. There's now an interface called 'Channel', which handles the local side of an SSH connection-layer channel, in terms of knowing where to send incoming channel data to, whether to close the channel, etc. Channel and the previous 'struct ssh_channel' mutually refer. The latter contains all the SSH-specific parts, and as much of the common logic as possible: in particular, Channel doesn't have to know anything about SSH packet formats, or which SSH protocol version is in use, or deal with all the fiddly stuff about window sizes - with the exception that x11fwd.c's implementation of it does have to be able to ask for a small fixed initial window size for the bodgy system that distinguishes upstream from downstream X forwardings. I've taken the opportunity to move the code implementing the detailed behaviour of agent forwarding out of ssh.c, now that all of it is on the far side of a uniform interface. (This also means that if I later implement agent forwarding directly to a Unix socket as an alternative, it'll be a matter of changing just the one call to agentf_new() that makes the Channel to plug into a forwarding.)
2018-09-12 14:03:47 +00:00
Refactor the LogContext type. LogContext is now the owner of the logevent() function that back ends and so forth are constantly calling. Previously, logevent was owned by the Frontend, which would store the message into its list for the GUI Event Log dialog (or print it to standard error, or whatever) and then pass it _back_ to LogContext to write to the currently open log file. Now it's the other way round: LogContext gets the message from the back end first, writes it to its log file if it feels so inclined, and communicates it back to the front end. This means that lots of parts of the back end system no longer need to have a pointer to a full-on Frontend; the only thing they needed it for was logging, so now they just have a LogContext (which many of them had to have anyway, e.g. for logging SSH packets or session traffic). LogContext itself also doesn't get a full Frontend pointer any more: it now talks back to the front end via a little vtable of its own called LogPolicy, which contains the method that passes Event Log entries through, the old askappend() function that decides whether to truncate a pre-existing log file, and an emergency function for printing an especially prominent message if the log file can't be created. One minor nice effect of this is that console and GUI apps can implement that last function subtly differently, so that Unix console apps can write it with a plain \n instead of the \r\n (harmless but inelegant) that the old centralised implementation generated. One other consequence of this is that the LogContext has to be provided to backend_init() so that it's available to backends from the instant of creation, rather than being provided via a separate API call a couple of function calls later, because backends have typically started doing things that need logging (like making network connections) before the call to backend_provide_logctx. Fortunately, there's no case in the whole code base where we don't already have logctx by the time we make a backend (so I don't actually remember why I ever delayed providing one). So that shortens the backend API by one function, which is always nice. While I'm tidying up, I've also moved the printf-style logeventf() and the handy logevent_and_free() into logging.c, instead of having copies of them scattered around other places. This has also let me remove some stub functions from a couple of outlying applications like Pageant. Finally, I've removed the pointless "_tag" at the end of LogContext's official struct name.
2018-10-10 18:26:18 +00:00
logeventf(pf->cl->logctx,
Server prep: reword messages to be client/server agnostic. Lots of user-facing messages that claim that the 'server' just did something or other unexpected will now need to be issued _by_ the server, when the client does the same unexpected thing. So I've reworded them all to talk about the 'remote side' instead of the 'server', and the SSH-2 key setup messages talk about initialising inbound and outbound crypto primitives rather than client->server and server->client.
2018-10-20 20:52:45 +00:00
"Forwarded connection refused by remote%s%s",
Move port-forwarding setup out of ssh.c. The tree234 storing currently active port forwardings - both local and remote - now lives in portfwd.c, as does the complicated function that updates it based on a Conf listing the new set of desired forwardings. Local port forwardings are passed to ssh.c via the same route as before - once the listening port receives a connection and portfwd.c knows where it should be directed to (in particular, after the SOCKS exchange, if any), it calls ssh_send_port_open. Remote forwardings are now initiated by calling ssh_rportfwd_alloc, which adds an entry to the rportfwds tree (which _is_ still in ssh.c, and still confusingly sorted by a different criterion depending on SSH protocol version) and sends out the appropriate protocol request. ssh_rportfwd_remove cancels one again, sending a protocol request too. Those functions look enough like ssh_{alloc,remove}_sharing_rportfwd that I've merged those into the new pair as well - now allocating an rportfwd allows you to specify either a destination host/port or a sharing context, and returns a handy pointer you can use to cancel the forwarding later.
2018-09-14 16:04:39 +00:00
errtext ? ": " : "", errtext ? errtext : "");
}
/* ----------------------------------------------------------------------
* Code to manage the complete set of currently active port
* forwardings, and update it from Conf.
*/
struct PortFwdRecord {
enum { DESTROY, KEEP, CREATE } status;
int type;
unsigned sport, dport;
char *saddr, *daddr;
char *sserv, *dserv;
struct ssh_rportfwd *remote;
int addressfamily;
struct PortListener *local;
};
static int pfr_cmp(void *av, void *bv)
{
PortFwdRecord *a = (PortFwdRecord *) av;
PortFwdRecord *b = (PortFwdRecord *) bv;
int i;
if (a->type > b->type)
return +1;
if (a->type < b->type)
return -1;
if (a->addressfamily > b->addressfamily)
return +1;
if (a->addressfamily < b->addressfamily)
return -1;
if ( (i = nullstrcmp(a->saddr, b->saddr)) != 0)
return i < 0 ? -1 : +1;
if (a->sport > b->sport)
return +1;
if (a->sport < b->sport)
return -1;
if (a->type != 'D') {
if ( (i = nullstrcmp(a->daddr, b->daddr)) != 0)
return i < 0 ? -1 : +1;
if (a->dport > b->dport)
return +1;
if (a->dport < b->dport)
return -1;
}
return 0;
}
void pfr_free(PortFwdRecord *pfr)
{
/* Dispose of any listening socket. */
if (pfr->local)
pfl_terminate(pfr->local);
sfree(pfr->saddr);
sfree(pfr->daddr);
sfree(pfr->sserv);
sfree(pfr->dserv);
sfree(pfr);
}
struct PortFwdManager {
New abstraction 'ConnectionLayer'. This is a vtable that wraps up all the functionality required from the SSH connection layer by associated modules like port forwarding and connection sharing. This extra layer of indirection adds nothing useful right now, but when I later separate the SSH-1 and SSH-2 connection layer implementations, it will be convenient for each one to be able to implement this vtable in terms of its own internal data structures. To simplify this vtable, I've moved a lot of the logging duties relating to connection sharing out of ssh.c into sshshare.c: now it handles nearly all the logging itself relating to setting up connection sharing in the first place and downstreams connecting and disconnecting. The only exception is the 'Reusing a shared connection' announcement in the console window, which is now done in ssh.c by detecting downstream status immediately after setup.
2018-09-17 11:14:00 +00:00
ConnectionLayer *cl;
Move port-forwarding setup out of ssh.c. The tree234 storing currently active port forwardings - both local and remote - now lives in portfwd.c, as does the complicated function that updates it based on a Conf listing the new set of desired forwardings. Local port forwardings are passed to ssh.c via the same route as before - once the listening port receives a connection and portfwd.c knows where it should be directed to (in particular, after the SOCKS exchange, if any), it calls ssh_send_port_open. Remote forwardings are now initiated by calling ssh_rportfwd_alloc, which adds an entry to the rportfwds tree (which _is_ still in ssh.c, and still confusingly sorted by a different criterion depending on SSH protocol version) and sends out the appropriate protocol request. ssh_rportfwd_remove cancels one again, sending a protocol request too. Those functions look enough like ssh_{alloc,remove}_sharing_rportfwd that I've merged those into the new pair as well - now allocating an rportfwd allows you to specify either a destination host/port or a sharing context, and returns a handy pointer you can use to cancel the forwarding later.
2018-09-14 16:04:39 +00:00
Conf *conf;
tree234 *forwardings;
};
New abstraction 'ConnectionLayer'. This is a vtable that wraps up all the functionality required from the SSH connection layer by associated modules like port forwarding and connection sharing. This extra layer of indirection adds nothing useful right now, but when I later separate the SSH-1 and SSH-2 connection layer implementations, it will be convenient for each one to be able to implement this vtable in terms of its own internal data structures. To simplify this vtable, I've moved a lot of the logging duties relating to connection sharing out of ssh.c into sshshare.c: now it handles nearly all the logging itself relating to setting up connection sharing in the first place and downstreams connecting and disconnecting. The only exception is the 'Reusing a shared connection' announcement in the console window, which is now done in ssh.c by detecting downstream status immediately after setup.
2018-09-17 11:14:00 +00:00
PortFwdManager *portfwdmgr_new(ConnectionLayer *cl)
Move port-forwarding setup out of ssh.c. The tree234 storing currently active port forwardings - both local and remote - now lives in portfwd.c, as does the complicated function that updates it based on a Conf listing the new set of desired forwardings. Local port forwardings are passed to ssh.c via the same route as before - once the listening port receives a connection and portfwd.c knows where it should be directed to (in particular, after the SOCKS exchange, if any), it calls ssh_send_port_open. Remote forwardings are now initiated by calling ssh_rportfwd_alloc, which adds an entry to the rportfwds tree (which _is_ still in ssh.c, and still confusingly sorted by a different criterion depending on SSH protocol version) and sends out the appropriate protocol request. ssh_rportfwd_remove cancels one again, sending a protocol request too. Those functions look enough like ssh_{alloc,remove}_sharing_rportfwd that I've merged those into the new pair as well - now allocating an rportfwd allows you to specify either a destination host/port or a sharing context, and returns a handy pointer you can use to cancel the forwarding later.
2018-09-14 16:04:39 +00:00
{
PortFwdManager *mgr = snew(PortFwdManager);
New abstraction 'ConnectionLayer'. This is a vtable that wraps up all the functionality required from the SSH connection layer by associated modules like port forwarding and connection sharing. This extra layer of indirection adds nothing useful right now, but when I later separate the SSH-1 and SSH-2 connection layer implementations, it will be convenient for each one to be able to implement this vtable in terms of its own internal data structures. To simplify this vtable, I've moved a lot of the logging duties relating to connection sharing out of ssh.c into sshshare.c: now it handles nearly all the logging itself relating to setting up connection sharing in the first place and downstreams connecting and disconnecting. The only exception is the 'Reusing a shared connection' announcement in the console window, which is now done in ssh.c by detecting downstream status immediately after setup.
2018-09-17 11:14:00 +00:00
mgr->cl = cl;
Move port-forwarding setup out of ssh.c. The tree234 storing currently active port forwardings - both local and remote - now lives in portfwd.c, as does the complicated function that updates it based on a Conf listing the new set of desired forwardings. Local port forwardings are passed to ssh.c via the same route as before - once the listening port receives a connection and portfwd.c knows where it should be directed to (in particular, after the SOCKS exchange, if any), it calls ssh_send_port_open. Remote forwardings are now initiated by calling ssh_rportfwd_alloc, which adds an entry to the rportfwds tree (which _is_ still in ssh.c, and still confusingly sorted by a different criterion depending on SSH protocol version) and sends out the appropriate protocol request. ssh_rportfwd_remove cancels one again, sending a protocol request too. Those functions look enough like ssh_{alloc,remove}_sharing_rportfwd that I've merged those into the new pair as well - now allocating an rportfwd allows you to specify either a destination host/port or a sharing context, and returns a handy pointer you can use to cancel the forwarding later.
2018-09-14 16:04:39 +00:00
mgr->conf = NULL;
mgr->forwardings = newtree234(pfr_cmp);
return mgr;
}
void portfwdmgr_close(PortFwdManager *mgr, PortFwdRecord *pfr)
{
PortFwdRecord *realpfr = del234(mgr->forwardings, pfr);
if (realpfr == pfr)
pfr_free(pfr);
}
void portfwdmgr_close_all(PortFwdManager *mgr)
{
PortFwdRecord *pfr;
while ((pfr = delpos234(mgr->forwardings, 0)) != NULL)
pfr_free(pfr);
}
void portfwdmgr_free(PortFwdManager *mgr)
{
portfwdmgr_close_all(mgr);
freetree234(mgr->forwardings);
if (mgr->conf)
conf_free(mgr->conf);
sfree(mgr);
}
void portfwdmgr_config(PortFwdManager *mgr, Conf *conf)
{
PortFwdRecord *pfr;
int i;
char *key, *val;
if (mgr->conf)
conf_free(mgr->conf);
mgr->conf = conf_copy(conf);
/*
* Go through the existing port forwardings and tag them
* with status==DESTROY. Any that we want to keep will be
* re-enabled (status==KEEP) as we go through the
* configuration and find out which bits are the same as
* they were before.
*/
for (i = 0; (pfr = index234(mgr->forwardings, i)) != NULL; i++)
pfr->status = DESTROY;
for (val = conf_get_str_strs(conf, CONF_portfwd, NULL, &key);
val != NULL;
val = conf_get_str_strs(conf, CONF_portfwd, key, &key)) {
char *kp, *kp2, *vp, *vp2;
char address_family, type;
int sport, dport, sserv, dserv;
char *sports, *dports, *saddr, *host;
kp = key;
address_family = 'A';
type = 'L';
if (*kp == 'A' || *kp == '4' || *kp == '6')
address_family = *kp++;
if (*kp == 'L' || *kp == 'R')
type = *kp++;
if ((kp2 = host_strchr(kp, ':')) != NULL) {
/*
* There's a colon in the middle of the source port
* string, which means that the part before it is
* actually a source address.
*/
char *saddr_tmp = dupprintf("%.*s", (int)(kp2 - kp), kp);
saddr = host_strduptrim(saddr_tmp);
sfree(saddr_tmp);
sports = kp2+1;
} else {
saddr = NULL;
sports = kp;
}
sport = atoi(sports);
sserv = 0;
if (sport == 0) {
sserv = 1;
sport = net_service_lookup(sports);
if (!sport) {
Refactor the LogContext type. LogContext is now the owner of the logevent() function that back ends and so forth are constantly calling. Previously, logevent was owned by the Frontend, which would store the message into its list for the GUI Event Log dialog (or print it to standard error, or whatever) and then pass it _back_ to LogContext to write to the currently open log file. Now it's the other way round: LogContext gets the message from the back end first, writes it to its log file if it feels so inclined, and communicates it back to the front end. This means that lots of parts of the back end system no longer need to have a pointer to a full-on Frontend; the only thing they needed it for was logging, so now they just have a LogContext (which many of them had to have anyway, e.g. for logging SSH packets or session traffic). LogContext itself also doesn't get a full Frontend pointer any more: it now talks back to the front end via a little vtable of its own called LogPolicy, which contains the method that passes Event Log entries through, the old askappend() function that decides whether to truncate a pre-existing log file, and an emergency function for printing an especially prominent message if the log file can't be created. One minor nice effect of this is that console and GUI apps can implement that last function subtly differently, so that Unix console apps can write it with a plain \n instead of the \r\n (harmless but inelegant) that the old centralised implementation generated. One other consequence of this is that the LogContext has to be provided to backend_init() so that it's available to backends from the instant of creation, rather than being provided via a separate API call a couple of function calls later, because backends have typically started doing things that need logging (like making network connections) before the call to backend_provide_logctx. Fortunately, there's no case in the whole code base where we don't already have logctx by the time we make a backend (so I don't actually remember why I ever delayed providing one). So that shortens the backend API by one function, which is always nice. While I'm tidying up, I've also moved the printf-style logeventf() and the handy logevent_and_free() into logging.c, instead of having copies of them scattered around other places. This has also let me remove some stub functions from a couple of outlying applications like Pageant. Finally, I've removed the pointless "_tag" at the end of LogContext's official struct name.
2018-10-10 18:26:18 +00:00
logeventf(mgr->cl->logctx, "Service lookup failed for source"
Move port-forwarding setup out of ssh.c. The tree234 storing currently active port forwardings - both local and remote - now lives in portfwd.c, as does the complicated function that updates it based on a Conf listing the new set of desired forwardings. Local port forwardings are passed to ssh.c via the same route as before - once the listening port receives a connection and portfwd.c knows where it should be directed to (in particular, after the SOCKS exchange, if any), it calls ssh_send_port_open. Remote forwardings are now initiated by calling ssh_rportfwd_alloc, which adds an entry to the rportfwds tree (which _is_ still in ssh.c, and still confusingly sorted by a different criterion depending on SSH protocol version) and sends out the appropriate protocol request. ssh_rportfwd_remove cancels one again, sending a protocol request too. Those functions look enough like ssh_{alloc,remove}_sharing_rportfwd that I've merged those into the new pair as well - now allocating an rportfwd allows you to specify either a destination host/port or a sharing context, and returns a handy pointer you can use to cancel the forwarding later.
2018-09-14 16:04:39 +00:00
" port \"%s\"", sports);
}
}
if (type == 'L' && !strcmp(val, "D")) {
/* dynamic forwarding */
host = NULL;
dports = NULL;
dport = -1;
dserv = 0;
type = 'D';
} else {
/* ordinary forwarding */
vp = val;
vp2 = vp + host_strcspn(vp, ":");
host = dupprintf("%.*s", (int)(vp2 - vp), vp);
if (*vp2)
vp2++;
dports = vp2;
dport = atoi(dports);
dserv = 0;
if (dport == 0) {
dserv = 1;
dport = net_service_lookup(dports);
if (!dport) {
Refactor the LogContext type. LogContext is now the owner of the logevent() function that back ends and so forth are constantly calling. Previously, logevent was owned by the Frontend, which would store the message into its list for the GUI Event Log dialog (or print it to standard error, or whatever) and then pass it _back_ to LogContext to write to the currently open log file. Now it's the other way round: LogContext gets the message from the back end first, writes it to its log file if it feels so inclined, and communicates it back to the front end. This means that lots of parts of the back end system no longer need to have a pointer to a full-on Frontend; the only thing they needed it for was logging, so now they just have a LogContext (which many of them had to have anyway, e.g. for logging SSH packets or session traffic). LogContext itself also doesn't get a full Frontend pointer any more: it now talks back to the front end via a little vtable of its own called LogPolicy, which contains the method that passes Event Log entries through, the old askappend() function that decides whether to truncate a pre-existing log file, and an emergency function for printing an especially prominent message if the log file can't be created. One minor nice effect of this is that console and GUI apps can implement that last function subtly differently, so that Unix console apps can write it with a plain \n instead of the \r\n (harmless but inelegant) that the old centralised implementation generated. One other consequence of this is that the LogContext has to be provided to backend_init() so that it's available to backends from the instant of creation, rather than being provided via a separate API call a couple of function calls later, because backends have typically started doing things that need logging (like making network connections) before the call to backend_provide_logctx. Fortunately, there's no case in the whole code base where we don't already have logctx by the time we make a backend (so I don't actually remember why I ever delayed providing one). So that shortens the backend API by one function, which is always nice. While I'm tidying up, I've also moved the printf-style logeventf() and the handy logevent_and_free() into logging.c, instead of having copies of them scattered around other places. This has also let me remove some stub functions from a couple of outlying applications like Pageant. Finally, I've removed the pointless "_tag" at the end of LogContext's official struct name.
2018-10-10 18:26:18 +00:00
logeventf(mgr->cl->logctx,
Move port-forwarding setup out of ssh.c. The tree234 storing currently active port forwardings - both local and remote - now lives in portfwd.c, as does the complicated function that updates it based on a Conf listing the new set of desired forwardings. Local port forwardings are passed to ssh.c via the same route as before - once the listening port receives a connection and portfwd.c knows where it should be directed to (in particular, after the SOCKS exchange, if any), it calls ssh_send_port_open. Remote forwardings are now initiated by calling ssh_rportfwd_alloc, which adds an entry to the rportfwds tree (which _is_ still in ssh.c, and still confusingly sorted by a different criterion depending on SSH protocol version) and sends out the appropriate protocol request. ssh_rportfwd_remove cancels one again, sending a protocol request too. Those functions look enough like ssh_{alloc,remove}_sharing_rportfwd that I've merged those into the new pair as well - now allocating an rportfwd allows you to specify either a destination host/port or a sharing context, and returns a handy pointer you can use to cancel the forwarding later.
2018-09-14 16:04:39 +00:00
"Service lookup failed for destination"
" port \"%s\"", dports);
}
}
}
if (sport && dport) {
/* Set up a description of the source port. */
pfr = snew(PortFwdRecord);
pfr->type = type;
pfr->saddr = saddr;
pfr->sserv = sserv ? dupstr(sports) : NULL;
pfr->sport = sport;
pfr->daddr = host;
pfr->dserv = dserv ? dupstr(dports) : NULL;
pfr->dport = dport;
pfr->local = NULL;
pfr->remote = NULL;
pfr->addressfamily = (address_family == '4' ? ADDRTYPE_IPV4 :
address_family == '6' ? ADDRTYPE_IPV6 :
ADDRTYPE_UNSPEC);
PortFwdRecord *existing = add234(mgr->forwardings, pfr);
if (existing != pfr) {
if (existing->status == DESTROY) {
/*
* We already have a port forwarding up and running
* with precisely these parameters. Hence, no need
* to do anything; simply re-tag the existing one
* as KEEP.
*/
existing->status = KEEP;
}
/*
* Anything else indicates that there was a duplicate
* in our input, which we'll silently ignore.
*/
pfr_free(pfr);
} else {
pfr->status = CREATE;
}
} else {
sfree(saddr);
sfree(host);
}
}
/*
* Now go through and destroy any port forwardings which were
* not re-enabled.
*/
for (i = 0; (pfr = index234(mgr->forwardings, i)) != NULL; i++) {
if (pfr->status == DESTROY) {
char *message;
message = dupprintf("%s port forwarding from %s%s%d",
pfr->type == 'L' ? "local" :
pfr->type == 'R' ? "remote" : "dynamic",
pfr->saddr ? pfr->saddr : "",
pfr->saddr ? ":" : "",
pfr->sport);
if (pfr->type != 'D') {
char *msg2 = dupprintf("%s to %s:%d", message,
pfr->daddr, pfr->dport);
sfree(message);
message = msg2;
}
Refactor the LogContext type. LogContext is now the owner of the logevent() function that back ends and so forth are constantly calling. Previously, logevent was owned by the Frontend, which would store the message into its list for the GUI Event Log dialog (or print it to standard error, or whatever) and then pass it _back_ to LogContext to write to the currently open log file. Now it's the other way round: LogContext gets the message from the back end first, writes it to its log file if it feels so inclined, and communicates it back to the front end. This means that lots of parts of the back end system no longer need to have a pointer to a full-on Frontend; the only thing they needed it for was logging, so now they just have a LogContext (which many of them had to have anyway, e.g. for logging SSH packets or session traffic). LogContext itself also doesn't get a full Frontend pointer any more: it now talks back to the front end via a little vtable of its own called LogPolicy, which contains the method that passes Event Log entries through, the old askappend() function that decides whether to truncate a pre-existing log file, and an emergency function for printing an especially prominent message if the log file can't be created. One minor nice effect of this is that console and GUI apps can implement that last function subtly differently, so that Unix console apps can write it with a plain \n instead of the \r\n (harmless but inelegant) that the old centralised implementation generated. One other consequence of this is that the LogContext has to be provided to backend_init() so that it's available to backends from the instant of creation, rather than being provided via a separate API call a couple of function calls later, because backends have typically started doing things that need logging (like making network connections) before the call to backend_provide_logctx. Fortunately, there's no case in the whole code base where we don't already have logctx by the time we make a backend (so I don't actually remember why I ever delayed providing one). So that shortens the backend API by one function, which is always nice. While I'm tidying up, I've also moved the printf-style logeventf() and the handy logevent_and_free() into logging.c, instead of having copies of them scattered around other places. This has also let me remove some stub functions from a couple of outlying applications like Pageant. Finally, I've removed the pointless "_tag" at the end of LogContext's official struct name.
2018-10-10 18:26:18 +00:00
logeventf(mgr->cl->logctx, "Cancelling %s", message);
Move port-forwarding setup out of ssh.c. The tree234 storing currently active port forwardings - both local and remote - now lives in portfwd.c, as does the complicated function that updates it based on a Conf listing the new set of desired forwardings. Local port forwardings are passed to ssh.c via the same route as before - once the listening port receives a connection and portfwd.c knows where it should be directed to (in particular, after the SOCKS exchange, if any), it calls ssh_send_port_open. Remote forwardings are now initiated by calling ssh_rportfwd_alloc, which adds an entry to the rportfwds tree (which _is_ still in ssh.c, and still confusingly sorted by a different criterion depending on SSH protocol version) and sends out the appropriate protocol request. ssh_rportfwd_remove cancels one again, sending a protocol request too. Those functions look enough like ssh_{alloc,remove}_sharing_rportfwd that I've merged those into the new pair as well - now allocating an rportfwd allows you to specify either a destination host/port or a sharing context, and returns a handy pointer you can use to cancel the forwarding later.
2018-09-14 16:04:39 +00:00
sfree(message);
/* pfr->remote or pfr->local may be NULL if setting up a
* forwarding failed. */
if (pfr->remote) {
/*
* Cancel the port forwarding at the server
* end.
*
* Actually closing the listening port on the server
* side may fail - because in SSH-1 there's no message
* in the protocol to request it!
*
* Instead, we simply remove the record of the
* forwarding from our local end, so that any
* connections the server tries to make on it are
* rejected.
*/
New abstraction 'ConnectionLayer'. This is a vtable that wraps up all the functionality required from the SSH connection layer by associated modules like port forwarding and connection sharing. This extra layer of indirection adds nothing useful right now, but when I later separate the SSH-1 and SSH-2 connection layer implementations, it will be convenient for each one to be able to implement this vtable in terms of its own internal data structures. To simplify this vtable, I've moved a lot of the logging duties relating to connection sharing out of ssh.c into sshshare.c: now it handles nearly all the logging itself relating to setting up connection sharing in the first place and downstreams connecting and disconnecting. The only exception is the 'Reusing a shared connection' announcement in the console window, which is now done in ssh.c by detecting downstream status immediately after setup.
2018-09-17 11:14:00 +00:00
ssh_rportfwd_remove(mgr->cl, pfr->remote);
Move port-forwarding setup out of ssh.c. The tree234 storing currently active port forwardings - both local and remote - now lives in portfwd.c, as does the complicated function that updates it based on a Conf listing the new set of desired forwardings. Local port forwardings are passed to ssh.c via the same route as before - once the listening port receives a connection and portfwd.c knows where it should be directed to (in particular, after the SOCKS exchange, if any), it calls ssh_send_port_open. Remote forwardings are now initiated by calling ssh_rportfwd_alloc, which adds an entry to the rportfwds tree (which _is_ still in ssh.c, and still confusingly sorted by a different criterion depending on SSH protocol version) and sends out the appropriate protocol request. ssh_rportfwd_remove cancels one again, sending a protocol request too. Those functions look enough like ssh_{alloc,remove}_sharing_rportfwd that I've merged those into the new pair as well - now allocating an rportfwd allows you to specify either a destination host/port or a sharing context, and returns a handy pointer you can use to cancel the forwarding later.
2018-09-14 16:04:39 +00:00
} else if (pfr->local) {
pfl_terminate(pfr->local);
}
delpos234(mgr->forwardings, i);
pfr_free(pfr);
i--; /* so we don't skip one in the list */
}
}
/*
* And finally, set up any new port forwardings (status==CREATE).
*/
for (i = 0; (pfr = index234(mgr->forwardings, i)) != NULL; i++) {
if (pfr->status == CREATE) {
char *sportdesc, *dportdesc;
sportdesc = dupprintf("%s%s%s%s%d%s",
pfr->saddr ? pfr->saddr : "",
pfr->saddr ? ":" : "",
pfr->sserv ? pfr->sserv : "",
pfr->sserv ? "(" : "",
pfr->sport,
pfr->sserv ? ")" : "");
if (pfr->type == 'D') {
dportdesc = NULL;
} else {
dportdesc = dupprintf("%s:%s%s%d%s",
pfr->daddr,
pfr->dserv ? pfr->dserv : "",
pfr->dserv ? "(" : "",
pfr->dport,
pfr->dserv ? ")" : "");
}
if (pfr->type == 'L') {
char *err = pfl_listen(pfr->daddr, pfr->dport,
pfr->saddr, pfr->sport,
New abstraction 'ConnectionLayer'. This is a vtable that wraps up all the functionality required from the SSH connection layer by associated modules like port forwarding and connection sharing. This extra layer of indirection adds nothing useful right now, but when I later separate the SSH-1 and SSH-2 connection layer implementations, it will be convenient for each one to be able to implement this vtable in terms of its own internal data structures. To simplify this vtable, I've moved a lot of the logging duties relating to connection sharing out of ssh.c into sshshare.c: now it handles nearly all the logging itself relating to setting up connection sharing in the first place and downstreams connecting and disconnecting. The only exception is the 'Reusing a shared connection' announcement in the console window, which is now done in ssh.c by detecting downstream status immediately after setup.
2018-09-17 11:14:00 +00:00
mgr->cl, conf, &pfr->local,
Move port-forwarding setup out of ssh.c. The tree234 storing currently active port forwardings - both local and remote - now lives in portfwd.c, as does the complicated function that updates it based on a Conf listing the new set of desired forwardings. Local port forwardings are passed to ssh.c via the same route as before - once the listening port receives a connection and portfwd.c knows where it should be directed to (in particular, after the SOCKS exchange, if any), it calls ssh_send_port_open. Remote forwardings are now initiated by calling ssh_rportfwd_alloc, which adds an entry to the rportfwds tree (which _is_ still in ssh.c, and still confusingly sorted by a different criterion depending on SSH protocol version) and sends out the appropriate protocol request. ssh_rportfwd_remove cancels one again, sending a protocol request too. Those functions look enough like ssh_{alloc,remove}_sharing_rportfwd that I've merged those into the new pair as well - now allocating an rportfwd allows you to specify either a destination host/port or a sharing context, and returns a handy pointer you can use to cancel the forwarding later.
2018-09-14 16:04:39 +00:00
pfr->addressfamily);
Refactor the LogContext type. LogContext is now the owner of the logevent() function that back ends and so forth are constantly calling. Previously, logevent was owned by the Frontend, which would store the message into its list for the GUI Event Log dialog (or print it to standard error, or whatever) and then pass it _back_ to LogContext to write to the currently open log file. Now it's the other way round: LogContext gets the message from the back end first, writes it to its log file if it feels so inclined, and communicates it back to the front end. This means that lots of parts of the back end system no longer need to have a pointer to a full-on Frontend; the only thing they needed it for was logging, so now they just have a LogContext (which many of them had to have anyway, e.g. for logging SSH packets or session traffic). LogContext itself also doesn't get a full Frontend pointer any more: it now talks back to the front end via a little vtable of its own called LogPolicy, which contains the method that passes Event Log entries through, the old askappend() function that decides whether to truncate a pre-existing log file, and an emergency function for printing an especially prominent message if the log file can't be created. One minor nice effect of this is that console and GUI apps can implement that last function subtly differently, so that Unix console apps can write it with a plain \n instead of the \r\n (harmless but inelegant) that the old centralised implementation generated. One other consequence of this is that the LogContext has to be provided to backend_init() so that it's available to backends from the instant of creation, rather than being provided via a separate API call a couple of function calls later, because backends have typically started doing things that need logging (like making network connections) before the call to backend_provide_logctx. Fortunately, there's no case in the whole code base where we don't already have logctx by the time we make a backend (so I don't actually remember why I ever delayed providing one). So that shortens the backend API by one function, which is always nice. While I'm tidying up, I've also moved the printf-style logeventf() and the handy logevent_and_free() into logging.c, instead of having copies of them scattered around other places. This has also let me remove some stub functions from a couple of outlying applications like Pageant. Finally, I've removed the pointless "_tag" at the end of LogContext's official struct name.
2018-10-10 18:26:18 +00:00
logeventf(mgr->cl->logctx,
Move port-forwarding setup out of ssh.c. The tree234 storing currently active port forwardings - both local and remote - now lives in portfwd.c, as does the complicated function that updates it based on a Conf listing the new set of desired forwardings. Local port forwardings are passed to ssh.c via the same route as before - once the listening port receives a connection and portfwd.c knows where it should be directed to (in particular, after the SOCKS exchange, if any), it calls ssh_send_port_open. Remote forwardings are now initiated by calling ssh_rportfwd_alloc, which adds an entry to the rportfwds tree (which _is_ still in ssh.c, and still confusingly sorted by a different criterion depending on SSH protocol version) and sends out the appropriate protocol request. ssh_rportfwd_remove cancels one again, sending a protocol request too. Those functions look enough like ssh_{alloc,remove}_sharing_rportfwd that I've merged those into the new pair as well - now allocating an rportfwd allows you to specify either a destination host/port or a sharing context, and returns a handy pointer you can use to cancel the forwarding later.
2018-09-14 16:04:39 +00:00
"Local %sport %s forwarding to %s%s%s",
pfr->addressfamily == ADDRTYPE_IPV4 ? "IPv4 " :
pfr->addressfamily == ADDRTYPE_IPV6 ? "IPv6 " : "",
sportdesc, dportdesc,
err ? " failed: " : "", err ? err : "");
if (err)
sfree(err);
} else if (pfr->type == 'D') {
char *err = pfl_listen(NULL, -1, pfr->saddr, pfr->sport,
New abstraction 'ConnectionLayer'. This is a vtable that wraps up all the functionality required from the SSH connection layer by associated modules like port forwarding and connection sharing. This extra layer of indirection adds nothing useful right now, but when I later separate the SSH-1 and SSH-2 connection layer implementations, it will be convenient for each one to be able to implement this vtable in terms of its own internal data structures. To simplify this vtable, I've moved a lot of the logging duties relating to connection sharing out of ssh.c into sshshare.c: now it handles nearly all the logging itself relating to setting up connection sharing in the first place and downstreams connecting and disconnecting. The only exception is the 'Reusing a shared connection' announcement in the console window, which is now done in ssh.c by detecting downstream status immediately after setup.
2018-09-17 11:14:00 +00:00
mgr->cl, conf, &pfr->local,
Move port-forwarding setup out of ssh.c. The tree234 storing currently active port forwardings - both local and remote - now lives in portfwd.c, as does the complicated function that updates it based on a Conf listing the new set of desired forwardings. Local port forwardings are passed to ssh.c via the same route as before - once the listening port receives a connection and portfwd.c knows where it should be directed to (in particular, after the SOCKS exchange, if any), it calls ssh_send_port_open. Remote forwardings are now initiated by calling ssh_rportfwd_alloc, which adds an entry to the rportfwds tree (which _is_ still in ssh.c, and still confusingly sorted by a different criterion depending on SSH protocol version) and sends out the appropriate protocol request. ssh_rportfwd_remove cancels one again, sending a protocol request too. Those functions look enough like ssh_{alloc,remove}_sharing_rportfwd that I've merged those into the new pair as well - now allocating an rportfwd allows you to specify either a destination host/port or a sharing context, and returns a handy pointer you can use to cancel the forwarding later.
2018-09-14 16:04:39 +00:00
pfr->addressfamily);
Refactor the LogContext type. LogContext is now the owner of the logevent() function that back ends and so forth are constantly calling. Previously, logevent was owned by the Frontend, which would store the message into its list for the GUI Event Log dialog (or print it to standard error, or whatever) and then pass it _back_ to LogContext to write to the currently open log file. Now it's the other way round: LogContext gets the message from the back end first, writes it to its log file if it feels so inclined, and communicates it back to the front end. This means that lots of parts of the back end system no longer need to have a pointer to a full-on Frontend; the only thing they needed it for was logging, so now they just have a LogContext (which many of them had to have anyway, e.g. for logging SSH packets or session traffic). LogContext itself also doesn't get a full Frontend pointer any more: it now talks back to the front end via a little vtable of its own called LogPolicy, which contains the method that passes Event Log entries through, the old askappend() function that decides whether to truncate a pre-existing log file, and an emergency function for printing an especially prominent message if the log file can't be created. One minor nice effect of this is that console and GUI apps can implement that last function subtly differently, so that Unix console apps can write it with a plain \n instead of the \r\n (harmless but inelegant) that the old centralised implementation generated. One other consequence of this is that the LogContext has to be provided to backend_init() so that it's available to backends from the instant of creation, rather than being provided via a separate API call a couple of function calls later, because backends have typically started doing things that need logging (like making network connections) before the call to backend_provide_logctx. Fortunately, there's no case in the whole code base where we don't already have logctx by the time we make a backend (so I don't actually remember why I ever delayed providing one). So that shortens the backend API by one function, which is always nice. While I'm tidying up, I've also moved the printf-style logeventf() and the handy logevent_and_free() into logging.c, instead of having copies of them scattered around other places. This has also let me remove some stub functions from a couple of outlying applications like Pageant. Finally, I've removed the pointless "_tag" at the end of LogContext's official struct name.
2018-10-10 18:26:18 +00:00
logeventf(mgr->cl->logctx,
Move port-forwarding setup out of ssh.c. The tree234 storing currently active port forwardings - both local and remote - now lives in portfwd.c, as does the complicated function that updates it based on a Conf listing the new set of desired forwardings. Local port forwardings are passed to ssh.c via the same route as before - once the listening port receives a connection and portfwd.c knows where it should be directed to (in particular, after the SOCKS exchange, if any), it calls ssh_send_port_open. Remote forwardings are now initiated by calling ssh_rportfwd_alloc, which adds an entry to the rportfwds tree (which _is_ still in ssh.c, and still confusingly sorted by a different criterion depending on SSH protocol version) and sends out the appropriate protocol request. ssh_rportfwd_remove cancels one again, sending a protocol request too. Those functions look enough like ssh_{alloc,remove}_sharing_rportfwd that I've merged those into the new pair as well - now allocating an rportfwd allows you to specify either a destination host/port or a sharing context, and returns a handy pointer you can use to cancel the forwarding later.
2018-09-14 16:04:39 +00:00
"Local %sport %s SOCKS dynamic forwarding%s%s",
pfr->addressfamily == ADDRTYPE_IPV4 ? "IPv4 " :
pfr->addressfamily == ADDRTYPE_IPV6 ? "IPv6 " : "",
sportdesc,
err ? " failed: " : "", err ? err : "");
if (err)
sfree(err);
} else {
const char *shost;
if (pfr->saddr) {
shost = pfr->saddr;
} else if (conf_get_int(conf, CONF_rport_acceptall)) {
shost = "";
} else {
shost = "localhost";
}
pfr->remote = ssh_rportfwd_alloc(
New abstraction 'ConnectionLayer'. This is a vtable that wraps up all the functionality required from the SSH connection layer by associated modules like port forwarding and connection sharing. This extra layer of indirection adds nothing useful right now, but when I later separate the SSH-1 and SSH-2 connection layer implementations, it will be convenient for each one to be able to implement this vtable in terms of its own internal data structures. To simplify this vtable, I've moved a lot of the logging duties relating to connection sharing out of ssh.c into sshshare.c: now it handles nearly all the logging itself relating to setting up connection sharing in the first place and downstreams connecting and disconnecting. The only exception is the 'Reusing a shared connection' announcement in the console window, which is now done in ssh.c by detecting downstream status immediately after setup.
2018-09-17 11:14:00 +00:00
mgr->cl, shost, pfr->sport, pfr->daddr, pfr->dport,
Move port-forwarding setup out of ssh.c. The tree234 storing currently active port forwardings - both local and remote - now lives in portfwd.c, as does the complicated function that updates it based on a Conf listing the new set of desired forwardings. Local port forwardings are passed to ssh.c via the same route as before - once the listening port receives a connection and portfwd.c knows where it should be directed to (in particular, after the SOCKS exchange, if any), it calls ssh_send_port_open. Remote forwardings are now initiated by calling ssh_rportfwd_alloc, which adds an entry to the rportfwds tree (which _is_ still in ssh.c, and still confusingly sorted by a different criterion depending on SSH protocol version) and sends out the appropriate protocol request. ssh_rportfwd_remove cancels one again, sending a protocol request too. Those functions look enough like ssh_{alloc,remove}_sharing_rportfwd that I've merged those into the new pair as well - now allocating an rportfwd allows you to specify either a destination host/port or a sharing context, and returns a handy pointer you can use to cancel the forwarding later.
2018-09-14 16:04:39 +00:00
pfr->addressfamily, sportdesc, pfr, NULL);
if (!pfr->remote) {
Refactor the LogContext type. LogContext is now the owner of the logevent() function that back ends and so forth are constantly calling. Previously, logevent was owned by the Frontend, which would store the message into its list for the GUI Event Log dialog (or print it to standard error, or whatever) and then pass it _back_ to LogContext to write to the currently open log file. Now it's the other way round: LogContext gets the message from the back end first, writes it to its log file if it feels so inclined, and communicates it back to the front end. This means that lots of parts of the back end system no longer need to have a pointer to a full-on Frontend; the only thing they needed it for was logging, so now they just have a LogContext (which many of them had to have anyway, e.g. for logging SSH packets or session traffic). LogContext itself also doesn't get a full Frontend pointer any more: it now talks back to the front end via a little vtable of its own called LogPolicy, which contains the method that passes Event Log entries through, the old askappend() function that decides whether to truncate a pre-existing log file, and an emergency function for printing an especially prominent message if the log file can't be created. One minor nice effect of this is that console and GUI apps can implement that last function subtly differently, so that Unix console apps can write it with a plain \n instead of the \r\n (harmless but inelegant) that the old centralised implementation generated. One other consequence of this is that the LogContext has to be provided to backend_init() so that it's available to backends from the instant of creation, rather than being provided via a separate API call a couple of function calls later, because backends have typically started doing things that need logging (like making network connections) before the call to backend_provide_logctx. Fortunately, there's no case in the whole code base where we don't already have logctx by the time we make a backend (so I don't actually remember why I ever delayed providing one). So that shortens the backend API by one function, which is always nice. While I'm tidying up, I've also moved the printf-style logeventf() and the handy logevent_and_free() into logging.c, instead of having copies of them scattered around other places. This has also let me remove some stub functions from a couple of outlying applications like Pageant. Finally, I've removed the pointless "_tag" at the end of LogContext's official struct name.
2018-10-10 18:26:18 +00:00
logeventf(mgr->cl->logctx,
Move port-forwarding setup out of ssh.c. The tree234 storing currently active port forwardings - both local and remote - now lives in portfwd.c, as does the complicated function that updates it based on a Conf listing the new set of desired forwardings. Local port forwardings are passed to ssh.c via the same route as before - once the listening port receives a connection and portfwd.c knows where it should be directed to (in particular, after the SOCKS exchange, if any), it calls ssh_send_port_open. Remote forwardings are now initiated by calling ssh_rportfwd_alloc, which adds an entry to the rportfwds tree (which _is_ still in ssh.c, and still confusingly sorted by a different criterion depending on SSH protocol version) and sends out the appropriate protocol request. ssh_rportfwd_remove cancels one again, sending a protocol request too. Those functions look enough like ssh_{alloc,remove}_sharing_rportfwd that I've merged those into the new pair as well - now allocating an rportfwd allows you to specify either a destination host/port or a sharing context, and returns a handy pointer you can use to cancel the forwarding later.
2018-09-14 16:04:39 +00:00
"Duplicate remote port forwarding to %s:%d",
pfr->daddr, pfr->dport);
pfr_free(pfr);
} else {
Refactor the LogContext type. LogContext is now the owner of the logevent() function that back ends and so forth are constantly calling. Previously, logevent was owned by the Frontend, which would store the message into its list for the GUI Event Log dialog (or print it to standard error, or whatever) and then pass it _back_ to LogContext to write to the currently open log file. Now it's the other way round: LogContext gets the message from the back end first, writes it to its log file if it feels so inclined, and communicates it back to the front end. This means that lots of parts of the back end system no longer need to have a pointer to a full-on Frontend; the only thing they needed it for was logging, so now they just have a LogContext (which many of them had to have anyway, e.g. for logging SSH packets or session traffic). LogContext itself also doesn't get a full Frontend pointer any more: it now talks back to the front end via a little vtable of its own called LogPolicy, which contains the method that passes Event Log entries through, the old askappend() function that decides whether to truncate a pre-existing log file, and an emergency function for printing an especially prominent message if the log file can't be created. One minor nice effect of this is that console and GUI apps can implement that last function subtly differently, so that Unix console apps can write it with a plain \n instead of the \r\n (harmless but inelegant) that the old centralised implementation generated. One other consequence of this is that the LogContext has to be provided to backend_init() so that it's available to backends from the instant of creation, rather than being provided via a separate API call a couple of function calls later, because backends have typically started doing things that need logging (like making network connections) before the call to backend_provide_logctx. Fortunately, there's no case in the whole code base where we don't already have logctx by the time we make a backend (so I don't actually remember why I ever delayed providing one). So that shortens the backend API by one function, which is always nice. While I'm tidying up, I've also moved the printf-style logeventf() and the handy logevent_and_free() into logging.c, instead of having copies of them scattered around other places. This has also let me remove some stub functions from a couple of outlying applications like Pageant. Finally, I've removed the pointless "_tag" at the end of LogContext's official struct name.
2018-10-10 18:26:18 +00:00
logeventf(mgr->cl->logctx, "Requesting remote port %s"
Move port-forwarding setup out of ssh.c. The tree234 storing currently active port forwardings - both local and remote - now lives in portfwd.c, as does the complicated function that updates it based on a Conf listing the new set of desired forwardings. Local port forwardings are passed to ssh.c via the same route as before - once the listening port receives a connection and portfwd.c knows where it should be directed to (in particular, after the SOCKS exchange, if any), it calls ssh_send_port_open. Remote forwardings are now initiated by calling ssh_rportfwd_alloc, which adds an entry to the rportfwds tree (which _is_ still in ssh.c, and still confusingly sorted by a different criterion depending on SSH protocol version) and sends out the appropriate protocol request. ssh_rportfwd_remove cancels one again, sending a protocol request too. Those functions look enough like ssh_{alloc,remove}_sharing_rportfwd that I've merged those into the new pair as well - now allocating an rportfwd allows you to specify either a destination host/port or a sharing context, and returns a handy pointer you can use to cancel the forwarding later.
2018-09-14 16:04:39 +00:00
" forward to %s", sportdesc, dportdesc);
}
}
sfree(sportdesc);
sfree(dportdesc);
}
}
}
Add an actual SSH server program. 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).
2018-10-20 21:09:54 +00:00
int portfwdmgr_listen(PortFwdManager *mgr, const char *host, int port,
const char *keyhost, int keyport, Conf *conf)
{
PortFwdRecord *pfr;
pfr = snew(PortFwdRecord);
pfr->type = 'L';
pfr->saddr = host ? dupstr(host) : NULL;
pfr->daddr = keyhost ? dupstr(keyhost) : NULL;
pfr->sserv = pfr->dserv = NULL;
pfr->sport = port;
pfr->dport = keyport;
pfr->local = NULL;
pfr->remote = NULL;
pfr->addressfamily = ADDRTYPE_UNSPEC;
PortFwdRecord *existing = add234(mgr->forwardings, pfr);
if (existing != pfr) {
/*
* We had this record already. Return failure.
*/
pfr_free(pfr);
Adopt C99 <stdbool.h>'s true/false. This commit includes <stdbool.h> from defs.h and deletes my traditional definitions of TRUE and FALSE, but other than that, it's a 100% mechanical search-and-replace transforming all uses of TRUE and FALSE into the C99-standardised lowercase spellings. No actual types are changed in this commit; that will come next. This is just getting the noise out of the way, so that subsequent commits can have a higher proportion of signal.
2018-10-29 19:50:29 +00:00
return false;
Add an actual SSH server program. 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).
2018-10-20 21:09:54 +00:00
}
char *err = pfl_listen(keyhost, keyport, host, port,
mgr->cl, conf, &pfr->local, pfr->addressfamily);
logeventf(mgr->cl->logctx,
"%s on port %s:%d to forward to client%s%s",
err ? "Failed to listen" : "Listening", host, port,
err ? ": " : "", err ? err : "");
if (err) {
sfree(err);
del234(mgr->forwardings, pfr);
pfr_free(pfr);
Adopt C99 <stdbool.h>'s true/false. This commit includes <stdbool.h> from defs.h and deletes my traditional definitions of TRUE and FALSE, but other than that, it's a 100% mechanical search-and-replace transforming all uses of TRUE and FALSE into the C99-standardised lowercase spellings. No actual types are changed in this commit; that will come next. This is just getting the noise out of the way, so that subsequent commits can have a higher proportion of signal.
2018-10-29 19:50:29 +00:00
return false;
Add an actual SSH server program. 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).
2018-10-20 21:09:54 +00:00
}
Adopt C99 <stdbool.h>'s true/false. This commit includes <stdbool.h> from defs.h and deletes my traditional definitions of TRUE and FALSE, but other than that, it's a 100% mechanical search-and-replace transforming all uses of TRUE and FALSE into the C99-standardised lowercase spellings. No actual types are changed in this commit; that will come next. This is just getting the noise out of the way, so that subsequent commits can have a higher proportion of signal.
2018-10-29 19:50:29 +00:00
return true;
Add an actual SSH server program. 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).
2018-10-20 21:09:54 +00:00
}
int portfwdmgr_unlisten(PortFwdManager *mgr, const char *host, int port)
{
PortFwdRecord pfr_key;
pfr_key.type = 'L';
/* Safe to cast the const away here, because it will only be used
* by pfr_cmp, which won't write to the string */
pfr_key.saddr = pfr_key.daddr = (char *)host;
pfr_key.sserv = pfr_key.dserv = NULL;
pfr_key.sport = pfr_key.dport = port;
pfr_key.local = NULL;
pfr_key.remote = NULL;
pfr_key.addressfamily = ADDRTYPE_UNSPEC;
PortFwdRecord *pfr = del234(mgr->forwardings, &pfr_key);
if (!pfr)
Adopt C99 <stdbool.h>'s true/false. This commit includes <stdbool.h> from defs.h and deletes my traditional definitions of TRUE and FALSE, but other than that, it's a 100% mechanical search-and-replace transforming all uses of TRUE and FALSE into the C99-standardised lowercase spellings. No actual types are changed in this commit; that will come next. This is just getting the noise out of the way, so that subsequent commits can have a higher proportion of signal.
2018-10-29 19:50:29 +00:00
return false;
Add an actual SSH server program. 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).
2018-10-20 21:09:54 +00:00
logeventf(mgr->cl->logctx, "Closing listening port %s:%d", host, port);
pfr_free(pfr);
Adopt C99 <stdbool.h>'s true/false. This commit includes <stdbool.h> from defs.h and deletes my traditional definitions of TRUE and FALSE, but other than that, it's a 100% mechanical search-and-replace transforming all uses of TRUE and FALSE into the C99-standardised lowercase spellings. No actual types are changed in this commit; that will come next. This is just getting the noise out of the way, so that subsequent commits can have a higher proportion of signal.
2018-10-29 19:50:29 +00:00
return true;
Add an actual SSH server program. 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).
2018-10-20 21:09:54 +00:00
}
Move port-forwarding setup out of ssh.c. The tree234 storing currently active port forwardings - both local and remote - now lives in portfwd.c, as does the complicated function that updates it based on a Conf listing the new set of desired forwardings. Local port forwardings are passed to ssh.c via the same route as before - once the listening port receives a connection and portfwd.c knows where it should be directed to (in particular, after the SOCKS exchange, if any), it calls ssh_send_port_open. Remote forwardings are now initiated by calling ssh_rportfwd_alloc, which adds an entry to the rportfwds tree (which _is_ still in ssh.c, and still confusingly sorted by a different criterion depending on SSH protocol version) and sends out the appropriate protocol request. ssh_rportfwd_remove cancels one again, sending a protocol request too. Those functions look enough like ssh_{alloc,remove}_sharing_rportfwd that I've merged those into the new pair as well - now allocating an rportfwd allows you to specify either a destination host/port or a sharing context, and returns a handy pointer you can use to cancel the forwarding later.
2018-09-14 16:04:39 +00:00
/*
* Called when receiving a PORT OPEN from the server to make a
* connection to a destination host.
*
* On success, returns NULL and fills in *pf_ret. On error, returns a
* dynamically allocated error message string.
*/
char *portfwdmgr_connect(PortFwdManager *mgr, Channel **chan_ret,
char *hostname, int port, SshChannel *c,
int addressfamily)
{
Get rid of lots of implicit pointer types. All the main backend structures - Ssh, Telnet, Pty, Serial etc - now describe structure types themselves rather than pointers to them. The same goes for the codebase-wide trait types Socket and Plug, and the supporting types SockAddr and Pinger. All those things that were typedefed as pointers are older types; the newer ones have the explicit * at the point of use, because that's what I now seem to be preferring. But whichever one of those is better, inconsistently using a mixture of the two styles is worse, so let's make everything consistent. A few types are still implicitly pointers, such as Bignum and some of the GSSAPI types; generally this is either because they have to be void *, or because they're typedefed differently on different platforms and aren't always pointers at all. Can't be helped. But I've got rid of the main ones, at least.
2018-10-04 18:10:23 +00:00
SockAddr *addr;
Move port-forwarding setup out of ssh.c. The tree234 storing currently active port forwardings - both local and remote - now lives in portfwd.c, as does the complicated function that updates it based on a Conf listing the new set of desired forwardings. Local port forwardings are passed to ssh.c via the same route as before - once the listening port receives a connection and portfwd.c knows where it should be directed to (in particular, after the SOCKS exchange, if any), it calls ssh_send_port_open. Remote forwardings are now initiated by calling ssh_rportfwd_alloc, which adds an entry to the rportfwds tree (which _is_ still in ssh.c, and still confusingly sorted by a different criterion depending on SSH protocol version) and sends out the appropriate protocol request. ssh_rportfwd_remove cancels one again, sending a protocol request too. Those functions look enough like ssh_{alloc,remove}_sharing_rportfwd that I've merged those into the new pair as well - now allocating an rportfwd allows you to specify either a destination host/port or a sharing context, and returns a handy pointer you can use to cancel the forwarding later.
2018-09-14 16:04:39 +00:00
const char *err;
char *dummy_realhost = NULL;
struct PortForwarding *pf;
/*
* Try to find host.
*/
addr = name_lookup(hostname, port, &dummy_realhost, mgr->conf,
addressfamily, NULL, NULL);
if ((err = sk_addr_error(addr)) != NULL) {
char *err_ret = dupstr(err);
sk_addr_free(addr);
sfree(dummy_realhost);
return err_ret;
}
/*
* Open socket.
*/
pf = new_portfwd_state();
*chan_ret = &pf->chan;
Make Socket and Plug into structs. I think that means that _every_ one of my traitoids is now a struct containing a vtable pointer as one of its fields (albeit sometimes the only field), and never just a bare pointer.
2018-10-05 06:24:16 +00:00
pf->plug.vt = &PortForwarding_plugvt;
Move port-forwarding setup out of ssh.c. The tree234 storing currently active port forwardings - both local and remote - now lives in portfwd.c, as does the complicated function that updates it based on a Conf listing the new set of desired forwardings. Local port forwardings are passed to ssh.c via the same route as before - once the listening port receives a connection and portfwd.c knows where it should be directed to (in particular, after the SOCKS exchange, if any), it calls ssh_send_port_open. Remote forwardings are now initiated by calling ssh_rportfwd_alloc, which adds an entry to the rportfwds tree (which _is_ still in ssh.c, and still confusingly sorted by a different criterion depending on SSH protocol version) and sends out the appropriate protocol request. ssh_rportfwd_remove cancels one again, sending a protocol request too. Those functions look enough like ssh_{alloc,remove}_sharing_rportfwd that I've merged those into the new pair as well - now allocating an rportfwd allows you to specify either a destination host/port or a sharing context, and returns a handy pointer you can use to cancel the forwarding later.
2018-09-14 16:04:39 +00:00
pf->chan.initial_fixed_window_size = 0;
pf->chan.vt = &PortForwarding_channelvt;
Adopt C99 <stdbool.h>'s true/false. This commit includes <stdbool.h> from defs.h and deletes my traditional definitions of TRUE and FALSE, but other than that, it's a 100% mechanical search-and-replace transforming all uses of TRUE and FALSE into the C99-standardised lowercase spellings. No actual types are changed in this commit; that will come next. This is just getting the noise out of the way, so that subsequent commits can have a higher proportion of signal.
2018-10-29 19:50:29 +00:00
pf->input_wanted = true;
Move port-forwarding setup out of ssh.c. The tree234 storing currently active port forwardings - both local and remote - now lives in portfwd.c, as does the complicated function that updates it based on a Conf listing the new set of desired forwardings. Local port forwardings are passed to ssh.c via the same route as before - once the listening port receives a connection and portfwd.c knows where it should be directed to (in particular, after the SOCKS exchange, if any), it calls ssh_send_port_open. Remote forwardings are now initiated by calling ssh_rportfwd_alloc, which adds an entry to the rportfwds tree (which _is_ still in ssh.c, and still confusingly sorted by a different criterion depending on SSH protocol version) and sends out the appropriate protocol request. ssh_rportfwd_remove cancels one again, sending a protocol request too. Those functions look enough like ssh_{alloc,remove}_sharing_rportfwd that I've merged those into the new pair as well - now allocating an rportfwd allows you to specify either a destination host/port or a sharing context, and returns a handy pointer you can use to cancel the forwarding later.
2018-09-14 16:04:39 +00:00
pf->ready = 1;
pf->c = c;
New abstraction 'ConnectionLayer'. This is a vtable that wraps up all the functionality required from the SSH connection layer by associated modules like port forwarding and connection sharing. This extra layer of indirection adds nothing useful right now, but when I later separate the SSH-1 and SSH-2 connection layer implementations, it will be convenient for each one to be able to implement this vtable in terms of its own internal data structures. To simplify this vtable, I've moved a lot of the logging duties relating to connection sharing out of ssh.c into sshshare.c: now it handles nearly all the logging itself relating to setting up connection sharing in the first place and downstreams connecting and disconnecting. The only exception is the 'Reusing a shared connection' announcement in the console window, which is now done in ssh.c by detecting downstream status immediately after setup.
2018-09-17 11:14:00 +00:00
pf->cl = mgr->cl;
Move port-forwarding setup out of ssh.c. The tree234 storing currently active port forwardings - both local and remote - now lives in portfwd.c, as does the complicated function that updates it based on a Conf listing the new set of desired forwardings. Local port forwardings are passed to ssh.c via the same route as before - once the listening port receives a connection and portfwd.c knows where it should be directed to (in particular, after the SOCKS exchange, if any), it calls ssh_send_port_open. Remote forwardings are now initiated by calling ssh_rportfwd_alloc, which adds an entry to the rportfwds tree (which _is_ still in ssh.c, and still confusingly sorted by a different criterion depending on SSH protocol version) and sends out the appropriate protocol request. ssh_rportfwd_remove cancels one again, sending a protocol request too. Those functions look enough like ssh_{alloc,remove}_sharing_rportfwd that I've merged those into the new pair as well - now allocating an rportfwd allows you to specify either a destination host/port or a sharing context, and returns a handy pointer you can use to cancel the forwarding later.
2018-09-14 16:04:39 +00:00
pf->socks_state = SOCKS_NONE;
pf->s = new_connection(addr, dummy_realhost, port,
Make Socket and Plug into structs. I think that means that _every_ one of my traitoids is now a struct containing a vtable pointer as one of its fields (albeit sometimes the only field), and never just a bare pointer.
2018-10-05 06:24:16 +00:00
0, 1, 0, 0, &pf->plug, mgr->conf);
Move port-forwarding setup out of ssh.c. The tree234 storing currently active port forwardings - both local and remote - now lives in portfwd.c, as does the complicated function that updates it based on a Conf listing the new set of desired forwardings. Local port forwardings are passed to ssh.c via the same route as before - once the listening port receives a connection and portfwd.c knows where it should be directed to (in particular, after the SOCKS exchange, if any), it calls ssh_send_port_open. Remote forwardings are now initiated by calling ssh_rportfwd_alloc, which adds an entry to the rportfwds tree (which _is_ still in ssh.c, and still confusingly sorted by a different criterion depending on SSH protocol version) and sends out the appropriate protocol request. ssh_rportfwd_remove cancels one again, sending a protocol request too. Those functions look enough like ssh_{alloc,remove}_sharing_rportfwd that I've merged those into the new pair as well - now allocating an rportfwd allows you to specify either a destination host/port or a sharing context, and returns a handy pointer you can use to cancel the forwarding later.
2018-09-14 16:04:39 +00:00
sfree(dummy_realhost);
if ((err = sk_socket_error(pf->s)) != NULL) {
char *err_ret = dupstr(err);
sk_close(pf->s);
free_portfwd_state(pf);
*chan_ret = NULL;
return err_ret;
}
return NULL;
Replace enum+union of local channel types with a vtable. There's now an interface called 'Channel', which handles the local side of an SSH connection-layer channel, in terms of knowing where to send incoming channel data to, whether to close the channel, etc. Channel and the previous 'struct ssh_channel' mutually refer. The latter contains all the SSH-specific parts, and as much of the common logic as possible: in particular, Channel doesn't have to know anything about SSH packet formats, or which SSH protocol version is in use, or deal with all the fiddly stuff about window sizes - with the exception that x11fwd.c's implementation of it does have to be able to ask for a small fixed initial window size for the bodgy system that distinguishes upstream from downstream X forwardings. I've taken the opportunity to move the code implementing the detailed behaviour of agent forwarding out of ssh.c, now that all of it is on the far side of a uniform interface. (This also means that if I later implement agent forwarding directly to a Unix socket as an alternative, it'll be a matter of changing just the one call to agentf_new() that makes the Channel to plug into a forwarding.)
2018-09-12 14:03:47 +00:00
}
Reference in New Issue Copy Permalink