github
/
putty
зеркало из https://github.com/github/putty.git
1
0
Форкнуть 0
Код Задачи Пакеты Проекты Релизы Вики Активность
putty/portfwd.c

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

Sprinkle some header comments in various files in an attempt to explain what they're for. [originally from svn r6639]
2006-04-23 22:26:03 +04: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-31 00:36:20 +03: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-09 00:53:27 +04: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 17:03:47 +03: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-09 00:53:27 +04: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-31 00:36:20 +03: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 17:03:47 +03: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 14:14:00 +03: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 17:33:10 +03: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 21:10:23 +03:00
Socket *s;
Convert a lot of 'int' variables to 'bool'. My normal habit these days, in new code, is to treat int and bool as _almost_ completely separate types. I'm still willing to use C's implicit test for zero on an integer (e.g. 'if (!blob.len)' is fine, no need to spell it out as blob.len != 0), but generally, if a variable is going to be conceptually a boolean, I like to declare it bool and assign to it using 'true' or 'false' rather than 0 or 1. PuTTY is an exception, because it predates the C99 bool, and I've stuck to its existing coding style even when adding new code to it. But it's been annoying me more and more, so now that I've decided C99 bool is an acceptable thing to require from our toolchain in the first place, here's a quite thorough trawl through the source doing 'boolification'. Many variables and function parameters are now typed as bool rather than int; many assignments of 0 or 1 to those variables are now spelled 'true' or 'false'. I managed this thorough conversion with the help of a custom clang plugin that I wrote to trawl the AST and apply heuristics to point out where things might want changing. So I've even managed to do a decent job on parts of the code I haven't looked at in years! To make the plugin's work easier, I pushed platform front ends generally in the direction of using standard 'bool' in preference to platform-specific boolean types like Windows BOOL or GTK's gboolean; I've left the platform booleans in places they _have_ to be for the platform APIs to work right, but variables only used by my own code have been converted wherever I found them. In a few places there are int values that look very like booleans in _most_ of the places they're used, but have a rarely-used third value, or a distinction between different nonzero values that most users don't care about. In these cases, I've _removed_ uses of 'true' and 'false' for the return values, to emphasise that there's something more subtle going on than a simple boolean answer: - the 'multisel' field in dialog.h's list box structure, for which the GTK front end in particular recognises a difference between 1 and 2 but nearly everything else treats as boolean - the 'urgent' parameter to plug_receive, where 1 vs 2 tells you something about the specific location of the urgent pointer, but most clients only care about 0 vs 'something nonzero' - the return value of wc_match, where -1 indicates a syntax error in the wildcard. - the return values from SSH-1 RSA-key loading functions, which use -1 for 'wrong passphrase' and 0 for all other failures (so any caller which already knows it's not loading an _encrypted private_ key can treat them as boolean) - term->esc_query, and the 'query' parameter in toggle_mode in terminal.c, which _usually_ hold 0 for ESC[123h or 1 for ESC[?123h, but can also hold -1 for some other intervening character that we don't support. In a few places there's an integer that I haven't turned into a bool even though it really _can_ only take values 0 or 1 (and, as above, tried to make the call sites consistent in not calling those values true and false), on the grounds that I thought it would make it more confusing to imply that the 0 value was in some sense 'negative' or bad and the 1 positive or good: - the return value of plug_accepting uses the POSIXish convention of 0=success and nonzero=error; I think if I made it bool then I'd also want to reverse its sense, and that's a job for a separate piece of work. - the 'screen' parameter to lineptr() in terminal.c, where 0 and 1 represent the default and alternate screens. There's no obvious reason why one of those should be considered 'true' or 'positive' or 'success' - they're just indices - so I've left it as int. ssh_scp_recv had particularly confusing semantics for its previous int return value: its call sites used '<= 0' to check for error, but it never actually returned a negative number, just 0 or 1. Now the function and its call sites agree that it's a bool. In a couple of places I've renamed variables called 'ret', because I don't like that name any more - it's unclear whether it means the return value (in preparation) for the _containing_ function or the return value received from a subroutine call, and occasionally I've accidentally used the same variable for both and introduced a bug. So where one of those got in my way, I've renamed it to 'toret' or 'retd' (the latter short for 'returned') in line with my usual modern practice, but I haven't done a thorough job of finding all of them. Finally, one amusing side effect of doing this is that I've had to separate quite a few chained assignments. It used to be perfectly fine to write 'a = b = c = TRUE' when a,b,c were int and TRUE was just a the 'true' defined by stdbool.h, that idiom provokes a warning from gcc: 'suggest parentheses around assignment used as truth value'!
2018-11-02 22:23:19 +03:00
bool input_wanted;
bool 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-31 00:36:20 +03: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 15:45:21 +04: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 21:23:56 +04: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 15:45:21 +04: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 21:23:56 +04: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 15:45:21 +04: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 21:23:56 +04: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-31 00:36:20 +03: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 21:23:56 +04: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-31 00:36:20 +03: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 11:29:33 +03: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 09:24:16 +03: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 17:03:47 +03: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-09 00:53:27 +04: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 18:04:41 +04: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 14:14:00 +03: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 21:10:23 +03:00
Socket *s;
Convert a lot of 'int' variables to 'bool'. My normal habit these days, in new code, is to treat int and bool as _almost_ completely separate types. I'm still willing to use C's implicit test for zero on an integer (e.g. 'if (!blob.len)' is fine, no need to spell it out as blob.len != 0), but generally, if a variable is going to be conceptually a boolean, I like to declare it bool and assign to it using 'true' or 'false' rather than 0 or 1. PuTTY is an exception, because it predates the C99 bool, and I've stuck to its existing coding style even when adding new code to it. But it's been annoying me more and more, so now that I've decided C99 bool is an acceptable thing to require from our toolchain in the first place, here's a quite thorough trawl through the source doing 'boolification'. Many variables and function parameters are now typed as bool rather than int; many assignments of 0 or 1 to those variables are now spelled 'true' or 'false'. I managed this thorough conversion with the help of a custom clang plugin that I wrote to trawl the AST and apply heuristics to point out where things might want changing. So I've even managed to do a decent job on parts of the code I haven't looked at in years! To make the plugin's work easier, I pushed platform front ends generally in the direction of using standard 'bool' in preference to platform-specific boolean types like Windows BOOL or GTK's gboolean; I've left the platform booleans in places they _have_ to be for the platform APIs to work right, but variables only used by my own code have been converted wherever I found them. In a few places there are int values that look very like booleans in _most_ of the places they're used, but have a rarely-used third value, or a distinction between different nonzero values that most users don't care about. In these cases, I've _removed_ uses of 'true' and 'false' for the return values, to emphasise that there's something more subtle going on than a simple boolean answer: - the 'multisel' field in dialog.h's list box structure, for which the GTK front end in particular recognises a difference between 1 and 2 but nearly everything else treats as boolean - the 'urgent' parameter to plug_receive, where 1 vs 2 tells you something about the specific location of the urgent pointer, but most clients only care about 0 vs 'something nonzero' - the return value of wc_match, where -1 indicates a syntax error in the wildcard. - the return values from SSH-1 RSA-key loading functions, which use -1 for 'wrong passphrase' and 0 for all other failures (so any caller which already knows it's not loading an _encrypted private_ key can treat them as boolean) - term->esc_query, and the 'query' parameter in toggle_mode in terminal.c, which _usually_ hold 0 for ESC[123h or 1 for ESC[?123h, but can also hold -1 for some other intervening character that we don't support. In a few places there's an integer that I haven't turned into a bool even though it really _can_ only take values 0 or 1 (and, as above, tried to make the call sites consistent in not calling those values true and false), on the grounds that I thought it would make it more confusing to imply that the 0 value was in some sense 'negative' or bad and the 1 positive or good: - the return value of plug_accepting uses the POSIXish convention of 0=success and nonzero=error; I think if I made it bool then I'd also want to reverse its sense, and that's a job for a separate piece of work. - the 'screen' parameter to lineptr() in terminal.c, where 0 and 1 represent the default and alternate screens. There's no obvious reason why one of those should be considered 'true' or 'positive' or 'success' - they're just indices - so I've left it as int. ssh_scp_recv had particularly confusing semantics for its previous int return value: its call sites used '<= 0' to check for error, but it never actually returned a negative number, just 0 or 1. Now the function and its call sites agree that it's a bool. In a couple of places I've renamed variables called 'ret', because I don't like that name any more - it's unclear whether it means the return value (in preparation) for the _containing_ function or the return value received from a subroutine call, and occasionally I've accidentally used the same variable for both and introduced a bug. So where one of those got in my way, I've renamed it to 'toret' or 'retd' (the latter short for 'returned') in line with my usual modern practice, but I haven't done a thorough job of finding all of them. Finally, one amusing side effect of doing this is that I've had to separate quite a few chained assignments. It used to be perfectly fine to write 'a = b = c = TRUE' when a,b,c were int and TRUE was just a the 'true' defined by stdbool.h, that idiom provokes a warning from gcc: 'suggest parentheses around assignment used as truth value'!
2018-11-02 22:23:19 +03:00
bool 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 18:04:41 +04: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 11:29:33 +03: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 09:24:16 +03: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 18:04:41 +04: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 21:23:56 +04: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 18:04:41 +04: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 21:23:56 +04: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 18:04:41 +04: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 21:23:56 +04: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 18:04:41 +04: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 21:23:56 +04: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 18:04:41 +04: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-31 00:36:20 +03: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 18:04:41 +04: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 21:23:56 +04: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 21:10:23 +03:00
static void pfd_log(Plug *plug, int type, SockAddr *addr, int port,
Whitespace rationalisation of entire code base. The number of people has been steadily increasing who read our source code with an editor that thinks tab stops are 4 spaces apart, as opposed to the traditional tty-derived 8 that the PuTTY code expects. So I've been wondering for ages about just fixing it, and switching to a spaces-only policy throughout the code. And I recently found out about 'git blame -w', which should make this change not too disruptive for the purposes of source-control archaeology; so perhaps now is the time. While I'm at it, I've also taken the opportunity to remove all the trailing spaces from source lines (on the basis that git dislikes them, and is the only thing that seems to have a strong opinion one way or the other). Apologies to anyone downstream of this code who has complicated patch sets to rebase past this change. I don't intend it to be needed again.
2019-09-08 22:29:00 +03:00
const char *error_msg, int error_code)
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 17:29:34 +03:00
{
/* 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 21:10:23 +03:00
static void pfl_log(Plug *plug, int type, SockAddr *addr, int port,
Whitespace rationalisation of entire code base. The number of people has been steadily increasing who read our source code with an editor that thinks tab stops are 4 spaces apart, as opposed to the traditional tty-derived 8 that the PuTTY code expects. So I've been wondering for ages about just fixing it, and switching to a spaces-only policy throughout the code. And I recently found out about 'git blame -w', which should make this change not too disruptive for the purposes of source-control archaeology; so perhaps now is the time. While I'm at it, I've also taken the opportunity to remove all the trailing spaces from source lines (on the basis that git dislikes them, and is the only thing that seems to have a strong opinion one way or the other). Apologies to anyone downstream of this code who has complicated patch sets to rebase past this change. I don't intend it to be needed again.
2019-09-08 22:29:00 +03:00
const char *error_msg, int error_code)
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 18:04:41 +04:00
{
/* 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 17:03:47 +03: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 21:10:23 +03:00
static void pfd_closing(Plug *plug, const char *error_msg, int error_code,
Whitespace rationalisation of entire code base. The number of people has been steadily increasing who read our source code with an editor that thinks tab stops are 4 spaces apart, as opposed to the traditional tty-derived 8 that the PuTTY code expects. So I've been wondering for ages about just fixing it, and switching to a spaces-only policy throughout the code. And I recently found out about 'git blame -w', which should make this change not too disruptive for the purposes of source-control archaeology; so perhaps now is the time. While I'm at it, I've also taken the opportunity to remove all the trailing spaces from source lines (on the basis that git dislikes them, and is the only thing that seems to have a strong opinion one way or the other). Apologies to anyone downstream of this code who has complicated patch sets to rebase past this change. I don't intend it to be needed again.
2019-09-08 22:29:00 +03:00
bool 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-09 00:53:27 +04: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-06 01:49:08 +03: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-09 00:53:27 +04: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 23:15:58 +04: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 18:04:41 +04: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 12:30:03 +03: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 10:42:36 +04: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 12:30:03 +03: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 10:42:36 +04: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 18:04:41 +04: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 10:42:36 +04: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 23:15:58 +04: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 18:04:41 +04: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 23:15:58 +04: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-09 00:53:27 +04: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 19:04:39 +03: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 21:10:23 +03:00
static void pfl_closing(Plug *plug, const char *error_msg, int error_code,
Whitespace rationalisation of entire code base. The number of people has been steadily increasing who read our source code with an editor that thinks tab stops are 4 spaces apart, as opposed to the traditional tty-derived 8 that the PuTTY code expects. So I've been wondering for ages about just fixing it, and switching to a spaces-only policy throughout the code. And I recently found out about 'git blame -w', which should make this change not too disruptive for the purposes of source-control archaeology; so perhaps now is the time. While I'm at it, I've also taken the opportunity to remove all the trailing spaces from source lines (on the basis that git dislikes them, and is the only thing that seems to have a strong opinion one way or the other). Apologies to anyone downstream of this code who has complicated patch sets to rebase past this change. I don't intend it to be needed again.
2019-09-08 22:29:00 +03:00
bool 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 18:04:41 +04: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 14:14:00 +03: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 21:10:23 +03: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 15:57:45 +03: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 22:06:42 +03: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 15:47:13 +03: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 17:03:47 +03: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 22:06:42 +03: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 15:57:45 +03: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 22:06:42 +03: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 17:03:47 +03: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 15:57:45 +03: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 17:03:47 +03: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 15:57:45 +03: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-31 00:36:20 +03: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));
}
Make lots of 'int' length fields into size_t. This is a general cleanup which has been overdue for some time: lots of length fields are now the machine word type rather than the (in practice) fixed 'int'.
2019-02-06 23:42:44 +03:00
static void pfd_receive(Plug *plug, int urgent, const char *data, size_t 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-09 00:53:27 +04: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-06 01:49:08 +03: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-31 00:36:20 +03: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:
Replace assert(false) with an unreachable() macro. Taking a leaf out of the LLVM code base: this macro still includes an assert(false) so that the message will show up in a typical build, but it follows it up with a call to a function explicitly marked as no- return. So this ought to do a better job of convincing compilers that once a code path hits this function it _really doesn't_ have to still faff about with making up a bogus return value or filling in a variable that 'might be used uninitialised' in the following code that won't be reached anyway. I've gone through the existing code looking for the assert(false) / assert(0) idiom and replaced all the ones I found with the new macro, which also meant I could remove a few pointless return statements and variable initialisations that I'd already had to put in to placate compiler front ends.
2019-01-03 11:12:19 +03:00
unreachable("These case values cannot appear");
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-31 00:36:20 +03:00
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 */
Convert a lot of 'int' variables to 'bool'. My normal habit these days, in new code, is to treat int and bool as _almost_ completely separate types. I'm still willing to use C's implicit test for zero on an integer (e.g. 'if (!blob.len)' is fine, no need to spell it out as blob.len != 0), but generally, if a variable is going to be conceptually a boolean, I like to declare it bool and assign to it using 'true' or 'false' rather than 0 or 1. PuTTY is an exception, because it predates the C99 bool, and I've stuck to its existing coding style even when adding new code to it. But it's been annoying me more and more, so now that I've decided C99 bool is an acceptable thing to require from our toolchain in the first place, here's a quite thorough trawl through the source doing 'boolification'. Many variables and function parameters are now typed as bool rather than int; many assignments of 0 or 1 to those variables are now spelled 'true' or 'false'. I managed this thorough conversion with the help of a custom clang plugin that I wrote to trawl the AST and apply heuristics to point out where things might want changing. So I've even managed to do a decent job on parts of the code I haven't looked at in years! To make the plugin's work easier, I pushed platform front ends generally in the direction of using standard 'bool' in preference to platform-specific boolean types like Windows BOOL or GTK's gboolean; I've left the platform booleans in places they _have_ to be for the platform APIs to work right, but variables only used by my own code have been converted wherever I found them. In a few places there are int values that look very like booleans in _most_ of the places they're used, but have a rarely-used third value, or a distinction between different nonzero values that most users don't care about. In these cases, I've _removed_ uses of 'true' and 'false' for the return values, to emphasise that there's something more subtle going on than a simple boolean answer: - the 'multisel' field in dialog.h's list box structure, for which the GTK front end in particular recognises a difference between 1 and 2 but nearly everything else treats as boolean - the 'urgent' parameter to plug_receive, where 1 vs 2 tells you something about the specific location of the urgent pointer, but most clients only care about 0 vs 'something nonzero' - the return value of wc_match, where -1 indicates a syntax error in the wildcard. - the return values from SSH-1 RSA-key loading functions, which use -1 for 'wrong passphrase' and 0 for all other failures (so any caller which already knows it's not loading an _encrypted private_ key can treat them as boolean) - term->esc_query, and the 'query' parameter in toggle_mode in terminal.c, which _usually_ hold 0 for ESC[123h or 1 for ESC[?123h, but can also hold -1 for some other intervening character that we don't support. In a few places there's an integer that I haven't turned into a bool even though it really _can_ only take values 0 or 1 (and, as above, tried to make the call sites consistent in not calling those values true and false), on the grounds that I thought it would make it more confusing to imply that the 0 value was in some sense 'negative' or bad and the 1 positive or good: - the return value of plug_accepting uses the POSIXish convention of 0=success and nonzero=error; I think if I made it bool then I'd also want to reverse its sense, and that's a job for a separate piece of work. - the 'screen' parameter to lineptr() in terminal.c, where 0 and 1 represent the default and alternate screens. There's no obvious reason why one of those should be considered 'true' or 'positive' or 'success' - they're just indices - so I've left it as int. ssh_scp_recv had particularly confusing semantics for its previous int return value: its call sites used '<= 0' to check for error, but it never actually returned a negative number, just 0 or 1. Now the function and its call sites agree that it's a bool. In a couple of places I've renamed variables called 'ret', because I don't like that name any more - it's unclear whether it means the return value (in preparation) for the _containing_ function or the return value received from a subroutine call, and occasionally I've accidentally used the same variable for both and introduced a bug. So where one of those got in my way, I've renamed it to 'toret' or 'retd' (the latter short for 'returned') in line with my usual modern practice, but I haven't done a thorough job of finding all of them. Finally, one amusing side effect of doing this is that I've had to separate quite a few chained assignments. It used to be perfectly fine to write 'a = b = c = TRUE' when a,b,c were int and TRUE was just a the 'true' defined by stdbool.h, that idiom provokes a warning from gcc: 'suggest parentheses around assignment used as truth value'!
2018-11-02 22:23:19 +03:00
bool 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-31 00:36:20 +03: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 22:50:29 +03: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-31 00:36:20 +03: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 15:45:21 +04:00
Whitespace rationalisation of entire code base. The number of people has been steadily increasing who read our source code with an editor that thinks tab stops are 4 spaces apart, as opposed to the traditional tty-derived 8 that the PuTTY code expects. So I've been wondering for ages about just fixing it, and switching to a spaces-only policy throughout the code. And I recently found out about 'git blame -w', which should make this change not too disruptive for the purposes of source-control archaeology; so perhaps now is the time. While I'm at it, I've also taken the opportunity to remove all the trailing spaces from source lines (on the basis that git dislikes them, and is the only thing that seems to have a strong opinion one way or the other). Apologies to anyone downstream of this code who has complicated patch sets to rebase past this change. I don't intend it to be needed again.
2019-09-08 22:29:00 +03:00
/*
* We come here when we're ready to make an actual
* connection.
*/
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 15:45:21 +04:00
Whitespace rationalisation of entire code base. The number of people has been steadily increasing who read our source code with an editor that thinks tab stops are 4 spaces apart, as opposed to the traditional tty-derived 8 that the PuTTY code expects. So I've been wondering for ages about just fixing it, and switching to a spaces-only policy throughout the code. And I recently found out about 'git blame -w', which should make this change not too disruptive for the purposes of source-control archaeology; so perhaps now is the time. While I'm at it, I've also taken the opportunity to remove all the trailing spaces from source lines (on the basis that git dislikes them, and is the only thing that seems to have a strong opinion one way or the other). Apologies to anyone downstream of this code who has complicated patch sets to rebase past this change. I don't intend it to be needed again.
2019-09-08 22:29:00 +03:00
/*
* Freeze the socket until the SSH server confirms the
* connection.
*/
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 21:33:42 +04: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 14:14:00 +03: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 21:09:23 +04: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 17:03:47 +03: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-09 00:53:27 +04:00
}
Make lots of 'int' length fields into size_t. This is a general cleanup which has been overdue for some time: lots of length fields are now the machine word type rather than the (in practice) fixed 'int'.
2019-02-06 23:42:44 +03:00
static void pfd_sent(Plug *plug, size_t 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 21:09:23 +04: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-06 01:49:08 +03: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 21:09:23 +04: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 18:04:41 +04:00
if (pf->c)
Whitespace rationalisation of entire code base. The number of people has been steadily increasing who read our source code with an editor that thinks tab stops are 4 spaces apart, as opposed to the traditional tty-derived 8 that the PuTTY code expects. So I've been wondering for ages about just fixing it, and switching to a spaces-only policy throughout the code. And I recently found out about 'git blame -w', which should make this change not too disruptive for the purposes of source-control archaeology; so perhaps now is the time. While I'm at it, I've also taken the opportunity to remove all the trailing spaces from source lines (on the basis that git dislikes them, and is the only thing that seems to have a strong opinion one way or the other). Apologies to anyone downstream of this code who has complicated patch sets to rebase past this change. I don't intend it to be needed again.
2019-09-08 22:29:00 +03:00
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 21:09:23 +04: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 09:03:46 +03: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 11:29:33 +03: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 17:03:47 +03: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);
Make lots of 'int' length fields into size_t. This is a general cleanup which has been overdue for some time: lots of length fields are now the machine word type rather than the (in practice) fixed 'int'.
2019-02-06 23:42:44 +03:00
static size_t pfd_send(
Channel *chan, bool is_stderr, const void *data, size_t len);
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 17:03:47 +03:00
static void pfd_send_eof(Channel *chan);
Convert a lot of 'int' variables to 'bool'. My normal habit these days, in new code, is to treat int and bool as _almost_ completely separate types. I'm still willing to use C's implicit test for zero on an integer (e.g. 'if (!blob.len)' is fine, no need to spell it out as blob.len != 0), but generally, if a variable is going to be conceptually a boolean, I like to declare it bool and assign to it using 'true' or 'false' rather than 0 or 1. PuTTY is an exception, because it predates the C99 bool, and I've stuck to its existing coding style even when adding new code to it. But it's been annoying me more and more, so now that I've decided C99 bool is an acceptable thing to require from our toolchain in the first place, here's a quite thorough trawl through the source doing 'boolification'. Many variables and function parameters are now typed as bool rather than int; many assignments of 0 or 1 to those variables are now spelled 'true' or 'false'. I managed this thorough conversion with the help of a custom clang plugin that I wrote to trawl the AST and apply heuristics to point out where things might want changing. So I've even managed to do a decent job on parts of the code I haven't looked at in years! To make the plugin's work easier, I pushed platform front ends generally in the direction of using standard 'bool' in preference to platform-specific boolean types like Windows BOOL or GTK's gboolean; I've left the platform booleans in places they _have_ to be for the platform APIs to work right, but variables only used by my own code have been converted wherever I found them. In a few places there are int values that look very like booleans in _most_ of the places they're used, but have a rarely-used third value, or a distinction between different nonzero values that most users don't care about. In these cases, I've _removed_ uses of 'true' and 'false' for the return values, to emphasise that there's something more subtle going on than a simple boolean answer: - the 'multisel' field in dialog.h's list box structure, for which the GTK front end in particular recognises a difference between 1 and 2 but nearly everything else treats as boolean - the 'urgent' parameter to plug_receive, where 1 vs 2 tells you something about the specific location of the urgent pointer, but most clients only care about 0 vs 'something nonzero' - the return value of wc_match, where -1 indicates a syntax error in the wildcard. - the return values from SSH-1 RSA-key loading functions, which use -1 for 'wrong passphrase' and 0 for all other failures (so any caller which already knows it's not loading an _encrypted private_ key can treat them as boolean) - term->esc_query, and the 'query' parameter in toggle_mode in terminal.c, which _usually_ hold 0 for ESC[123h or 1 for ESC[?123h, but can also hold -1 for some other intervening character that we don't support. In a few places there's an integer that I haven't turned into a bool even though it really _can_ only take values 0 or 1 (and, as above, tried to make the call sites consistent in not calling those values true and false), on the grounds that I thought it would make it more confusing to imply that the 0 value was in some sense 'negative' or bad and the 1 positive or good: - the return value of plug_accepting uses the POSIXish convention of 0=success and nonzero=error; I think if I made it bool then I'd also want to reverse its sense, and that's a job for a separate piece of work. - the 'screen' parameter to lineptr() in terminal.c, where 0 and 1 represent the default and alternate screens. There's no obvious reason why one of those should be considered 'true' or 'positive' or 'success' - they're just indices - so I've left it as int. ssh_scp_recv had particularly confusing semantics for its previous int return value: its call sites used '<= 0' to check for error, but it never actually returned a negative number, just 0 or 1. Now the function and its call sites agree that it's a bool. In a couple of places I've renamed variables called 'ret', because I don't like that name any more - it's unclear whether it means the return value (in preparation) for the _containing_ function or the return value received from a subroutine call, and occasionally I've accidentally used the same variable for both and introduced a bug. So where one of those got in my way, I've renamed it to 'toret' or 'retd' (the latter short for 'returned') in line with my usual modern practice, but I haven't done a thorough job of finding all of them. Finally, one amusing side effect of doing this is that I've had to separate quite a few chained assignments. It used to be perfectly fine to write 'a = b = c = TRUE' when a,b,c were int and TRUE was just a the 'true' defined by stdbool.h, that idiom provokes a warning from gcc: 'suggest parentheses around assignment used as truth value'!
2018-11-02 22:23:19 +03:00
static void pfd_set_input_wanted(Channel *chan, bool wanted);
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 17:03:47 +03:00
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 20:02:59 +03: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 19:34:20 +03: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 23:48:49 +03: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 20:02:33 +03: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 17:03:47 +03: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-21 00:47:49 +03: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-09 00:53:27 +04: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 18:04:41 +04: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-09 00:53:27 +04: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 18:04:41 +04: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 09:24:16 +03: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 17:03:47 +03: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 22:50:29 +03: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-09 00:53:27 +04: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 18:04:41 +04: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-09 00:53:27 +04: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-21 00:47:49 +03: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 22:50:29 +03:00
pf->input_wanted = true;
Convert a lot of 'int' variables to 'bool'. My normal habit these days, in new code, is to treat int and bool as _almost_ completely separate types. I'm still willing to use C's implicit test for zero on an integer (e.g. 'if (!blob.len)' is fine, no need to spell it out as blob.len != 0), but generally, if a variable is going to be conceptually a boolean, I like to declare it bool and assign to it using 'true' or 'false' rather than 0 or 1. PuTTY is an exception, because it predates the C99 bool, and I've stuck to its existing coding style even when adding new code to it. But it's been annoying me more and more, so now that I've decided C99 bool is an acceptable thing to require from our toolchain in the first place, here's a quite thorough trawl through the source doing 'boolification'. Many variables and function parameters are now typed as bool rather than int; many assignments of 0 or 1 to those variables are now spelled 'true' or 'false'. I managed this thorough conversion with the help of a custom clang plugin that I wrote to trawl the AST and apply heuristics to point out where things might want changing. So I've even managed to do a decent job on parts of the code I haven't looked at in years! To make the plugin's work easier, I pushed platform front ends generally in the direction of using standard 'bool' in preference to platform-specific boolean types like Windows BOOL or GTK's gboolean; I've left the platform booleans in places they _have_ to be for the platform APIs to work right, but variables only used by my own code have been converted wherever I found them. In a few places there are int values that look very like booleans in _most_ of the places they're used, but have a rarely-used third value, or a distinction between different nonzero values that most users don't care about. In these cases, I've _removed_ uses of 'true' and 'false' for the return values, to emphasise that there's something more subtle going on than a simple boolean answer: - the 'multisel' field in dialog.h's list box structure, for which the GTK front end in particular recognises a difference between 1 and 2 but nearly everything else treats as boolean - the 'urgent' parameter to plug_receive, where 1 vs 2 tells you something about the specific location of the urgent pointer, but most clients only care about 0 vs 'something nonzero' - the return value of wc_match, where -1 indicates a syntax error in the wildcard. - the return values from SSH-1 RSA-key loading functions, which use -1 for 'wrong passphrase' and 0 for all other failures (so any caller which already knows it's not loading an _encrypted private_ key can treat them as boolean) - term->esc_query, and the 'query' parameter in toggle_mode in terminal.c, which _usually_ hold 0 for ESC[123h or 1 for ESC[?123h, but can also hold -1 for some other intervening character that we don't support. In a few places there's an integer that I haven't turned into a bool even though it really _can_ only take values 0 or 1 (and, as above, tried to make the call sites consistent in not calling those values true and false), on the grounds that I thought it would make it more confusing to imply that the 0 value was in some sense 'negative' or bad and the 1 positive or good: - the return value of plug_accepting uses the POSIXish convention of 0=success and nonzero=error; I think if I made it bool then I'd also want to reverse its sense, and that's a job for a separate piece of work. - the 'screen' parameter to lineptr() in terminal.c, where 0 and 1 represent the default and alternate screens. There's no obvious reason why one of those should be considered 'true' or 'positive' or 'success' - they're just indices - so I've left it as int. ssh_scp_recv had particularly confusing semantics for its previous int return value: its call sites used '<= 0' to check for error, but it never actually returned a negative number, just 0 or 1. Now the function and its call sites agree that it's a bool. In a couple of places I've renamed variables called 'ret', because I don't like that name any more - it's unclear whether it means the return value (in preparation) for the _containing_ function or the return value received from a subroutine call, and occasionally I've accidentally used the same variable for both and introduced a bug. So where one of those got in my way, I've renamed it to 'toret' or 'retd' (the latter short for 'returned') in line with my usual modern practice, but I haven't done a thorough job of finding all of them. Finally, one amusing side effect of doing this is that I've had to separate quite a few chained assignments. It used to be perfectly fine to write 'a = b = c = TRUE' when a,b,c were int and TRUE was just a the 'true' defined by stdbool.h, that idiom provokes a warning from gcc: 'suggest parentheses around assignment used as truth value'!
2018-11-02 22:23:19 +03:00
pf->ready = false;
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-21 00:47:49 +03:00
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 16:04:04 +03:00
if ((err = sk_socket_error(s)) != NULL) {
Whitespace rationalisation of entire code base. The number of people has been steadily increasing who read our source code with an editor that thinks tab stops are 4 spaces apart, as opposed to the traditional tty-derived 8 that the PuTTY code expects. So I've been wondering for ages about just fixing it, and switching to a spaces-only policy throughout the code. And I recently found out about 'git blame -w', which should make this change not too disruptive for the purposes of source-control archaeology; so perhaps now is the time. While I'm at it, I've also taken the opportunity to remove all the trailing spaces from source lines (on the basis that git dislikes them, and is the only thing that seems to have a strong opinion one way or the other). Apologies to anyone downstream of this code who has complicated patch sets to rebase past this change. I don't intend it to be needed again.
2019-09-08 22:29:00 +03:00
portfwd_raw_free(chan);
return 1;
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-09 00:53:27 +04: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-21 00:47:49 +03: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-09 00:53:27 +04: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-31 00:36:20 +03: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-21 00:47:49 +03:00
pf->s = s;
Whitespace rationalisation of entire code base. The number of people has been steadily increasing who read our source code with an editor that thinks tab stops are 4 spaces apart, as opposed to the traditional tty-derived 8 that the PuTTY code expects. So I've been wondering for ages about just fixing it, and switching to a spaces-only policy throughout the code. And I recently found out about 'git blame -w', which should make this change not too disruptive for the purposes of source-control archaeology; so perhaps now is the time. While I'm at it, I've also taken the opportunity to remove all the trailing spaces from source lines (on the basis that git dislikes them, and is the only thing that seems to have a strong opinion one way or the other). Apologies to anyone downstream of this code who has complicated patch sets to rebase past this change. I don't intend it to be needed again.
2019-09-08 22:29:00 +03:00
pf->socks_state = SOCKS_INITIAL;
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-31 00:36:20 +03:00
pf->socksbuf = strbuf_new();
pf->socksbuf_consumed = 0;
Whitespace rationalisation of entire code base. The number of people has been steadily increasing who read our source code with an editor that thinks tab stops are 4 spaces apart, as opposed to the traditional tty-derived 8 that the PuTTY code expects. So I've been wondering for ages about just fixing it, and switching to a spaces-only policy throughout the code. And I recently found out about 'git blame -w', which should make this change not too disruptive for the purposes of source-control archaeology; so perhaps now is the time. While I'm at it, I've also taken the opportunity to remove all the trailing spaces from source lines (on the basis that git dislikes them, and is the only thing that seems to have a strong opinion one way or the other). Apologies to anyone downstream of this code who has complicated patch sets to rebase past this change. I don't intend it to be needed again.
2019-09-08 22:29:00 +03:00
pf->port = 0; /* "hostname" buffer is so far empty */
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-09 00:53:27 +04:00
} else {
Whitespace rationalisation of entire code base. The number of people has been steadily increasing who read our source code with an editor that thinks tab stops are 4 spaces apart, as opposed to the traditional tty-derived 8 that the PuTTY code expects. So I've been wondering for ages about just fixing it, and switching to a spaces-only policy throughout the code. And I recently found out about 'git blame -w', which should make this change not too disruptive for the purposes of source-control archaeology; so perhaps now is the time. While I'm at it, I've also taken the opportunity to remove all the trailing spaces from source lines (on the basis that git dislikes them, and is the only thing that seems to have a strong opinion one way or the other). Apologies to anyone downstream of this code who has complicated patch sets to rebase past this change. I don't intend it to be needed again.
2019-09-08 22:29:00 +03: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-21 00:47:49 +03: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-09 00:53:27 +04: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 09:03:46 +03: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 11:29:33 +03: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-09 00:53:27 +04: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 18:04:41 +04: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 19:04:39 +03: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 18:04:41 +04: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-09 00:53:27 +04:00
*/
Add some missing 'const' in pfl_listen.
2018-10-21 00:46:24 +03: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 19:04:39 +03: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-09 00:53:27 +04: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 18:18:18 +04: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 18:04:41 +04: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-09 00:53:27 +04: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 18:04:41 +04: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 09:24:16 +03: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 15:45:21 +04:00
if (desthost) {
Whitespace rationalisation of entire code base. The number of people has been steadily increasing who read our source code with an editor that thinks tab stops are 4 spaces apart, as opposed to the traditional tty-derived 8 that the PuTTY code expects. So I've been wondering for ages about just fixing it, and switching to a spaces-only policy throughout the code. And I recently found out about 'git blame -w', which should make this change not too disruptive for the purposes of source-control archaeology; so perhaps now is the time. While I'm at it, I've also taken the opportunity to remove all the trailing spaces from source lines (on the basis that git dislikes them, and is the only thing that seems to have a strong opinion one way or the other). Apologies to anyone downstream of this code who has complicated patch sets to rebase past this change. I don't intend it to be needed again.
2019-09-08 22:29:00 +03:00
pl->hostname = dupstr(desthost);
pl->port = destport;
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 15:45:21 +04:00
} else
Whitespace rationalisation of entire code base. The number of people has been steadily increasing who read our source code with an editor that thinks tab stops are 4 spaces apart, as opposed to the traditional tty-derived 8 that the PuTTY code expects. So I've been wondering for ages about just fixing it, and switching to a spaces-only policy throughout the code. And I recently found out about 'git blame -w', which should make this change not too disruptive for the purposes of source-control archaeology; so perhaps now is the time. While I'm at it, I've also taken the opportunity to remove all the trailing spaces from source lines (on the basis that git dislikes them, and is the only thing that seems to have a strong opinion one way or the other). Apologies to anyone downstream of this code who has complicated patch sets to rebase past this change. I don't intend it to be needed again.
2019-09-08 22:29:00 +03: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 14:14:00 +03: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 18:04:41 +04: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 09:24:16 +03:00
pl->s = new_listener(srcaddr, port, &pl->plug,
Switch some Conf settings over to being bool. I think this is the full set of things that ought logically to be boolean. One annoyance is that quite a few radio-button controls in config.c address Conf fields that are now bool rather than int, which means that the shared handler function can't just access them all with conf_{get,set}_int. Rather than back out the rigorous separation of int and bool in conf.c itself, I've just added a similar alternative handler function for the bool-typed ones.
2018-10-29 22:57:31 +03:00
!conf_get_bool(conf, CONF_lport_acceptall),
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 18:04:41 +04:00
conf, address_family);
if ((err = sk_socket_error(pl->s)) != NULL) {
char *err_ret = dupstr(err);
sk_close(pl->s);
Whitespace rationalisation of entire code base. The number of people has been steadily increasing who read our source code with an editor that thinks tab stops are 4 spaces apart, as opposed to the traditional tty-derived 8 that the PuTTY code expects. So I've been wondering for ages about just fixing it, and switching to a spaces-only policy throughout the code. And I recently found out about 'git blame -w', which should make this change not too disruptive for the purposes of source-control archaeology; so perhaps now is the time. While I'm at it, I've also taken the opportunity to remove all the trailing spaces from source lines (on the basis that git dislikes them, and is the only thing that seems to have a strong opinion one way or the other). Apologies to anyone downstream of this code who has complicated patch sets to rebase past this change. I don't intend it to be needed again.
2019-09-08 22:29:00 +03:00
free_portlistener_state(pl);
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 18:04:41 +04:00
*pl_ret = NULL;
Whitespace rationalisation of entire code base. The number of people has been steadily increasing who read our source code with an editor that thinks tab stops are 4 spaces apart, as opposed to the traditional tty-derived 8 that the PuTTY code expects. So I've been wondering for ages about just fixing it, and switching to a spaces-only policy throughout the code. And I recently found out about 'git blame -w', which should make this change not too disruptive for the purposes of source-control archaeology; so perhaps now is the time. While I'm at it, I've also taken the opportunity to remove all the trailing spaces from source lines (on the basis that git dislikes them, and is the only thing that seems to have a strong opinion one way or the other). Apologies to anyone downstream of this code who has complicated patch sets to rebase past this change. I don't intend it to be needed again.
2019-09-08 22:29:00 +03:00
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-09 00:53:27 +04: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 17:03:47 +03: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-09 00:53:27 +04: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 18:04:41 +04:00
if (!pf)
Whitespace rationalisation of entire code base. The number of people has been steadily increasing who read our source code with an editor that thinks tab stops are 4 spaces apart, as opposed to the traditional tty-derived 8 that the PuTTY code expects. So I've been wondering for ages about just fixing it, and switching to a spaces-only policy throughout the code. And I recently found out about 'git blame -w', which should make this change not too disruptive for the purposes of source-control archaeology; so perhaps now is the time. While I'm at it, I've also taken the opportunity to remove all the trailing spaces from source lines (on the basis that git dislikes them, and is the only thing that seems to have a strong opinion one way or the other). Apologies to anyone downstream of this code who has complicated patch sets to rebase past this change. I don't intend it to be needed again.
2019-09-08 22:29:00 +03:00
return;
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-09 00:53:27 +04: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 18:04:41 +04: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-09 00:53:27 +04: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 17:07:05 +03: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 19:04:39 +03: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 17:07:05 +03: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 18:04:41 +04:00
if (!pl)
Whitespace rationalisation of entire code base. The number of people has been steadily increasing who read our source code with an editor that thinks tab stops are 4 spaces apart, as opposed to the traditional tty-derived 8 that the PuTTY code expects. So I've been wondering for ages about just fixing it, and switching to a spaces-only policy throughout the code. And I recently found out about 'git blame -w', which should make this change not too disruptive for the purposes of source-control archaeology; so perhaps now is the time. While I'm at it, I've also taken the opportunity to remove all the trailing spaces from source lines (on the basis that git dislikes them, and is the only thing that seems to have a strong opinion one way or the other). Apologies to anyone downstream of this code who has complicated patch sets to rebase past this change. I don't intend it to be needed again.
2019-09-08 22:29:00 +03: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 18:04:41 +04:00
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 17:07:05 +03:00
}
Convert a lot of 'int' variables to 'bool'. My normal habit these days, in new code, is to treat int and bool as _almost_ completely separate types. I'm still willing to use C's implicit test for zero on an integer (e.g. 'if (!blob.len)' is fine, no need to spell it out as blob.len != 0), but generally, if a variable is going to be conceptually a boolean, I like to declare it bool and assign to it using 'true' or 'false' rather than 0 or 1. PuTTY is an exception, because it predates the C99 bool, and I've stuck to its existing coding style even when adding new code to it. But it's been annoying me more and more, so now that I've decided C99 bool is an acceptable thing to require from our toolchain in the first place, here's a quite thorough trawl through the source doing 'boolification'. Many variables and function parameters are now typed as bool rather than int; many assignments of 0 or 1 to those variables are now spelled 'true' or 'false'. I managed this thorough conversion with the help of a custom clang plugin that I wrote to trawl the AST and apply heuristics to point out where things might want changing. So I've even managed to do a decent job on parts of the code I haven't looked at in years! To make the plugin's work easier, I pushed platform front ends generally in the direction of using standard 'bool' in preference to platform-specific boolean types like Windows BOOL or GTK's gboolean; I've left the platform booleans in places they _have_ to be for the platform APIs to work right, but variables only used by my own code have been converted wherever I found them. In a few places there are int values that look very like booleans in _most_ of the places they're used, but have a rarely-used third value, or a distinction between different nonzero values that most users don't care about. In these cases, I've _removed_ uses of 'true' and 'false' for the return values, to emphasise that there's something more subtle going on than a simple boolean answer: - the 'multisel' field in dialog.h's list box structure, for which the GTK front end in particular recognises a difference between 1 and 2 but nearly everything else treats as boolean - the 'urgent' parameter to plug_receive, where 1 vs 2 tells you something about the specific location of the urgent pointer, but most clients only care about 0 vs 'something nonzero' - the return value of wc_match, where -1 indicates a syntax error in the wildcard. - the return values from SSH-1 RSA-key loading functions, which use -1 for 'wrong passphrase' and 0 for all other failures (so any caller which already knows it's not loading an _encrypted private_ key can treat them as boolean) - term->esc_query, and the 'query' parameter in toggle_mode in terminal.c, which _usually_ hold 0 for ESC[123h or 1 for ESC[?123h, but can also hold -1 for some other intervening character that we don't support. In a few places there's an integer that I haven't turned into a bool even though it really _can_ only take values 0 or 1 (and, as above, tried to make the call sites consistent in not calling those values true and false), on the grounds that I thought it would make it more confusing to imply that the 0 value was in some sense 'negative' or bad and the 1 positive or good: - the return value of plug_accepting uses the POSIXish convention of 0=success and nonzero=error; I think if I made it bool then I'd also want to reverse its sense, and that's a job for a separate piece of work. - the 'screen' parameter to lineptr() in terminal.c, where 0 and 1 represent the default and alternate screens. There's no obvious reason why one of those should be considered 'true' or 'positive' or 'success' - they're just indices - so I've left it as int. ssh_scp_recv had particularly confusing semantics for its previous int return value: its call sites used '<= 0' to check for error, but it never actually returned a negative number, just 0 or 1. Now the function and its call sites agree that it's a bool. In a couple of places I've renamed variables called 'ret', because I don't like that name any more - it's unclear whether it means the return value (in preparation) for the _containing_ function or the return value received from a subroutine call, and occasionally I've accidentally used the same variable for both and introduced a bug. So where one of those got in my way, I've renamed it to 'toret' or 'retd' (the latter short for 'returned') in line with my usual modern practice, but I haven't done a thorough job of finding all of them. Finally, one amusing side effect of doing this is that I've had to separate quite a few chained assignments. It used to be perfectly fine to write 'a = b = c = TRUE' when a,b,c were int and TRUE was just a the 'true' defined by stdbool.h, that idiom provokes a warning from gcc: 'suggest parentheses around assignment used as truth value'!
2018-11-02 22:23:19 +03:00
static void pfd_set_input_wanted(Channel *chan, bool 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 21:09:23 +04: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 17:03:47 +03: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-06 01:49:08 +03: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 17:03:47 +03: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 21:09:23 +04: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 17:03:47 +03: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 21:09:23 +04: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 17:03:47 +03: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-06 01:49:08 +03: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 17:03:47 +03: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 21:09:23 +04: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-09 00:53:27 +04:00
/*
* Called to send data down the raw connection.
*/
Make lots of 'int' length fields into size_t. This is a general cleanup which has been overdue for some time: lots of length fields are now the machine word type rather than the (in practice) fixed 'int'.
2019-02-06 23:42:44 +03:00
static size_t pfd_send(
Channel *chan, bool is_stderr, const void *data, size_t 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-09 00:53:27 +04: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 17:03:47 +03: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-06 01:49:08 +03: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 18:04:41 +04: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-09 00:53:27 +04: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 17:03:47 +03: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 15:44:03 +04: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 17:03:47 +03: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-06 01:49:08 +03: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 18:04:41 +04: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 15:44:03 +04: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-09 00:53:27 +04: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 17:03:47 +03: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-09 00:53:27 +04: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 17:03:47 +03: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-06 01:49:08 +03: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-09 00:53:27 +04:00
Convert a lot of 'int' variables to 'bool'. My normal habit these days, in new code, is to treat int and bool as _almost_ completely separate types. I'm still willing to use C's implicit test for zero on an integer (e.g. 'if (!blob.len)' is fine, no need to spell it out as blob.len != 0), but generally, if a variable is going to be conceptually a boolean, I like to declare it bool and assign to it using 'true' or 'false' rather than 0 or 1. PuTTY is an exception, because it predates the C99 bool, and I've stuck to its existing coding style even when adding new code to it. But it's been annoying me more and more, so now that I've decided C99 bool is an acceptable thing to require from our toolchain in the first place, here's a quite thorough trawl through the source doing 'boolification'. Many variables and function parameters are now typed as bool rather than int; many assignments of 0 or 1 to those variables are now spelled 'true' or 'false'. I managed this thorough conversion with the help of a custom clang plugin that I wrote to trawl the AST and apply heuristics to point out where things might want changing. So I've even managed to do a decent job on parts of the code I haven't looked at in years! To make the plugin's work easier, I pushed platform front ends generally in the direction of using standard 'bool' in preference to platform-specific boolean types like Windows BOOL or GTK's gboolean; I've left the platform booleans in places they _have_ to be for the platform APIs to work right, but variables only used by my own code have been converted wherever I found them. In a few places there are int values that look very like booleans in _most_ of the places they're used, but have a rarely-used third value, or a distinction between different nonzero values that most users don't care about. In these cases, I've _removed_ uses of 'true' and 'false' for the return values, to emphasise that there's something more subtle going on than a simple boolean answer: - the 'multisel' field in dialog.h's list box structure, for which the GTK front end in particular recognises a difference between 1 and 2 but nearly everything else treats as boolean - the 'urgent' parameter to plug_receive, where 1 vs 2 tells you something about the specific location of the urgent pointer, but most clients only care about 0 vs 'something nonzero' - the return value of wc_match, where -1 indicates a syntax error in the wildcard. - the return values from SSH-1 RSA-key loading functions, which use -1 for 'wrong passphrase' and 0 for all other failures (so any caller which already knows it's not loading an _encrypted private_ key can treat them as boolean) - term->esc_query, and the 'query' parameter in toggle_mode in terminal.c, which _usually_ hold 0 for ESC[123h or 1 for ESC[?123h, but can also hold -1 for some other intervening character that we don't support. In a few places there's an integer that I haven't turned into a bool even though it really _can_ only take values 0 or 1 (and, as above, tried to make the call sites consistent in not calling those values true and false), on the grounds that I thought it would make it more confusing to imply that the 0 value was in some sense 'negative' or bad and the 1 positive or good: - the return value of plug_accepting uses the POSIXish convention of 0=success and nonzero=error; I think if I made it bool then I'd also want to reverse its sense, and that's a job for a separate piece of work. - the 'screen' parameter to lineptr() in terminal.c, where 0 and 1 represent the default and alternate screens. There's no obvious reason why one of those should be considered 'true' or 'positive' or 'success' - they're just indices - so I've left it as int. ssh_scp_recv had particularly confusing semantics for its previous int return value: its call sites used '<= 0' to check for error, but it never actually returned a negative number, just 0 or 1. Now the function and its call sites agree that it's a bool. In a couple of places I've renamed variables called 'ret', because I don't like that name any more - it's unclear whether it means the return value (in preparation) for the _containing_ function or the return value received from a subroutine call, and occasionally I've accidentally used the same variable for both and introduced a bug. So where one of those got in my way, I've renamed it to 'toret' or 'retd' (the latter short for 'returned') in line with my usual modern practice, but I haven't done a thorough job of finding all of them. Finally, one amusing side effect of doing this is that I've had to separate quite a few chained assignments. It used to be perfectly fine to write 'a = b = c = TRUE' when a,b,c were int and TRUE was just a the 'true' defined by stdbool.h, that idiom provokes a warning from gcc: 'suggest parentheses around assignment used as truth value'!
2018-11-02 22:23:19 +03:00
pf->ready = true;
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 18:04:41 +04:00
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-31 00:36:20 +03:00
if (pf->socksbuf) {
Whitespace rationalisation of entire code base. The number of people has been steadily increasing who read our source code with an editor that thinks tab stops are 4 spaces apart, as opposed to the traditional tty-derived 8 that the PuTTY code expects. So I've been wondering for ages about just fixing it, and switching to a spaces-only policy throughout the code. And I recently found out about 'git blame -w', which should make this change not too disruptive for the purposes of source-control archaeology; so perhaps now is the time. While I'm at it, I've also taken the opportunity to remove all the trailing spaces from source lines (on the basis that git dislikes them, and is the only thing that seems to have a strong opinion one way or the other). Apologies to anyone downstream of this code who has complicated patch sets to rebase past this change. I don't intend it to be needed again.
2019-09-08 22:29:00 +03:00
sshfwd_write(pf->c, pf->socksbuf->u + pf->socksbuf_consumed,
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-31 00:36:20 +03:00
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 15:45:21 +04: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-09 00:53:27 +04: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 17:03:47 +03: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-06 01:49:08 +03: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 17:03:47 +03: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 21:26:18 +03: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 23:52:45 +03: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 19:04:39 +03: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 14:14:00 +03: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 19:04:39 +03: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 14:14:00 +03: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 19:04:39 +03: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 14:14:00 +03: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 19:04:39 +03: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 21:26:18 +03: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 19:04:39 +03: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 21:26:18 +03: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 19:04:39 +03: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 21:26:18 +03: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 19:04:39 +03: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 14:14:00 +03:00
ssh_rportfwd_remove(mgr->cl, pfr->remote);
portfwdmgr_config: null out pointers we're destroying. In particular, a report today pointed out that the call to pfl_terminate(pfr->local) directly from portfwdmgr_config() was then repeated from inside pfr_free(pfr) which we called four lines later, leading to a double-free crash. Now we null out pfr->local the first time, so the call in pfr_free is skipped. While I'm at it, I've nulled out pfr->remote similarly; that doesn't cause any crash that I can see, but it's a good habit to get into for futureproofing.
2019-03-25 23:49:04 +03:00
pfr->remote = NULL;
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 19:04:39 +03:00
} else if (pfr->local) {
pfl_terminate(pfr->local);
portfwdmgr_config: null out pointers we're destroying. In particular, a report today pointed out that the call to pfl_terminate(pfr->local) directly from portfwdmgr_config() was then repeated from inside pfr_free(pfr) which we called four lines later, leading to a double-free crash. Now we null out pfr->local the first time, so the call in pfr_free is skipped. While I'm at it, I've nulled out pfr->remote similarly; that doesn't cause any crash that I can see, but it's a good habit to get into for futureproofing.
2019-03-25 23:49:04 +03:00
pfr->local = NULL;
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 19:04:39 +03:00
}
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 14:14:00 +03: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 19:04:39 +03: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 21:26:18 +03: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 19:04:39 +03: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 14:14:00 +03: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 19:04:39 +03: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 21:26:18 +03: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 19:04:39 +03: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;
Switch some Conf settings over to being bool. I think this is the full set of things that ought logically to be boolean. One annoyance is that quite a few radio-button controls in config.c address Conf fields that are now bool rather than int, which means that the shared handler function can't just access them all with conf_{get,set}_int. Rather than back out the rigorous separation of int and bool in conf.c itself, I've just added a similar alternative handler function for the bool-typed ones.
2018-10-29 22:57:31 +03:00
} else if (conf_get_bool(conf, CONF_rport_acceptall)) {
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 19:04:39 +03:00
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 14:14:00 +03: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 19:04:39 +03: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 21:26:18 +03: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 19:04:39 +03: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 21:26:18 +03: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 19:04:39 +03:00
" forward to %s", sportdesc, dportdesc);
}
}
sfree(sportdesc);
sfree(dportdesc);
}
}
}
Convert a lot of 'int' variables to 'bool'. My normal habit these days, in new code, is to treat int and bool as _almost_ completely separate types. I'm still willing to use C's implicit test for zero on an integer (e.g. 'if (!blob.len)' is fine, no need to spell it out as blob.len != 0), but generally, if a variable is going to be conceptually a boolean, I like to declare it bool and assign to it using 'true' or 'false' rather than 0 or 1. PuTTY is an exception, because it predates the C99 bool, and I've stuck to its existing coding style even when adding new code to it. But it's been annoying me more and more, so now that I've decided C99 bool is an acceptable thing to require from our toolchain in the first place, here's a quite thorough trawl through the source doing 'boolification'. Many variables and function parameters are now typed as bool rather than int; many assignments of 0 or 1 to those variables are now spelled 'true' or 'false'. I managed this thorough conversion with the help of a custom clang plugin that I wrote to trawl the AST and apply heuristics to point out where things might want changing. So I've even managed to do a decent job on parts of the code I haven't looked at in years! To make the plugin's work easier, I pushed platform front ends generally in the direction of using standard 'bool' in preference to platform-specific boolean types like Windows BOOL or GTK's gboolean; I've left the platform booleans in places they _have_ to be for the platform APIs to work right, but variables only used by my own code have been converted wherever I found them. In a few places there are int values that look very like booleans in _most_ of the places they're used, but have a rarely-used third value, or a distinction between different nonzero values that most users don't care about. In these cases, I've _removed_ uses of 'true' and 'false' for the return values, to emphasise that there's something more subtle going on than a simple boolean answer: - the 'multisel' field in dialog.h's list box structure, for which the GTK front end in particular recognises a difference between 1 and 2 but nearly everything else treats as boolean - the 'urgent' parameter to plug_receive, where 1 vs 2 tells you something about the specific location of the urgent pointer, but most clients only care about 0 vs 'something nonzero' - the return value of wc_match, where -1 indicates a syntax error in the wildcard. - the return values from SSH-1 RSA-key loading functions, which use -1 for 'wrong passphrase' and 0 for all other failures (so any caller which already knows it's not loading an _encrypted private_ key can treat them as boolean) - term->esc_query, and the 'query' parameter in toggle_mode in terminal.c, which _usually_ hold 0 for ESC[123h or 1 for ESC[?123h, but can also hold -1 for some other intervening character that we don't support. In a few places there's an integer that I haven't turned into a bool even though it really _can_ only take values 0 or 1 (and, as above, tried to make the call sites consistent in not calling those values true and false), on the grounds that I thought it would make it more confusing to imply that the 0 value was in some sense 'negative' or bad and the 1 positive or good: - the return value of plug_accepting uses the POSIXish convention of 0=success and nonzero=error; I think if I made it bool then I'd also want to reverse its sense, and that's a job for a separate piece of work. - the 'screen' parameter to lineptr() in terminal.c, where 0 and 1 represent the default and alternate screens. There's no obvious reason why one of those should be considered 'true' or 'positive' or 'success' - they're just indices - so I've left it as int. ssh_scp_recv had particularly confusing semantics for its previous int return value: its call sites used '<= 0' to check for error, but it never actually returned a negative number, just 0 or 1. Now the function and its call sites agree that it's a bool. In a couple of places I've renamed variables called 'ret', because I don't like that name any more - it's unclear whether it means the return value (in preparation) for the _containing_ function or the return value received from a subroutine call, and occasionally I've accidentally used the same variable for both and introduced a bug. So where one of those got in my way, I've renamed it to 'toret' or 'retd' (the latter short for 'returned') in line with my usual modern practice, but I haven't done a thorough job of finding all of them. Finally, one amusing side effect of doing this is that I've had to separate quite a few chained assignments. It used to be perfectly fine to write 'a = b = c = TRUE' when a,b,c were int and TRUE was just a the 'true' defined by stdbool.h, that idiom provokes a warning from gcc: 'suggest parentheses around assignment used as truth value'!
2018-11-02 22:23:19 +03:00
bool portfwdmgr_listen(PortFwdManager *mgr, const char *host, int port,
const char *keyhost, int keyport, Conf *conf)
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-21 00:09:54 +03:00
{
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 22:50:29 +03: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-21 00:09:54 +03: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 22:50:29 +03: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-21 00:09:54 +03: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 22:50:29 +03: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-21 00:09:54 +03:00
}
Convert a lot of 'int' variables to 'bool'. My normal habit these days, in new code, is to treat int and bool as _almost_ completely separate types. I'm still willing to use C's implicit test for zero on an integer (e.g. 'if (!blob.len)' is fine, no need to spell it out as blob.len != 0), but generally, if a variable is going to be conceptually a boolean, I like to declare it bool and assign to it using 'true' or 'false' rather than 0 or 1. PuTTY is an exception, because it predates the C99 bool, and I've stuck to its existing coding style even when adding new code to it. But it's been annoying me more and more, so now that I've decided C99 bool is an acceptable thing to require from our toolchain in the first place, here's a quite thorough trawl through the source doing 'boolification'. Many variables and function parameters are now typed as bool rather than int; many assignments of 0 or 1 to those variables are now spelled 'true' or 'false'. I managed this thorough conversion with the help of a custom clang plugin that I wrote to trawl the AST and apply heuristics to point out where things might want changing. So I've even managed to do a decent job on parts of the code I haven't looked at in years! To make the plugin's work easier, I pushed platform front ends generally in the direction of using standard 'bool' in preference to platform-specific boolean types like Windows BOOL or GTK's gboolean; I've left the platform booleans in places they _have_ to be for the platform APIs to work right, but variables only used by my own code have been converted wherever I found them. In a few places there are int values that look very like booleans in _most_ of the places they're used, but have a rarely-used third value, or a distinction between different nonzero values that most users don't care about. In these cases, I've _removed_ uses of 'true' and 'false' for the return values, to emphasise that there's something more subtle going on than a simple boolean answer: - the 'multisel' field in dialog.h's list box structure, for which the GTK front end in particular recognises a difference between 1 and 2 but nearly everything else treats as boolean - the 'urgent' parameter to plug_receive, where 1 vs 2 tells you something about the specific location of the urgent pointer, but most clients only care about 0 vs 'something nonzero' - the return value of wc_match, where -1 indicates a syntax error in the wildcard. - the return values from SSH-1 RSA-key loading functions, which use -1 for 'wrong passphrase' and 0 for all other failures (so any caller which already knows it's not loading an _encrypted private_ key can treat them as boolean) - term->esc_query, and the 'query' parameter in toggle_mode in terminal.c, which _usually_ hold 0 for ESC[123h or 1 for ESC[?123h, but can also hold -1 for some other intervening character that we don't support. In a few places there's an integer that I haven't turned into a bool even though it really _can_ only take values 0 or 1 (and, as above, tried to make the call sites consistent in not calling those values true and false), on the grounds that I thought it would make it more confusing to imply that the 0 value was in some sense 'negative' or bad and the 1 positive or good: - the return value of plug_accepting uses the POSIXish convention of 0=success and nonzero=error; I think if I made it bool then I'd also want to reverse its sense, and that's a job for a separate piece of work. - the 'screen' parameter to lineptr() in terminal.c, where 0 and 1 represent the default and alternate screens. There's no obvious reason why one of those should be considered 'true' or 'positive' or 'success' - they're just indices - so I've left it as int. ssh_scp_recv had particularly confusing semantics for its previous int return value: its call sites used '<= 0' to check for error, but it never actually returned a negative number, just 0 or 1. Now the function and its call sites agree that it's a bool. In a couple of places I've renamed variables called 'ret', because I don't like that name any more - it's unclear whether it means the return value (in preparation) for the _containing_ function or the return value received from a subroutine call, and occasionally I've accidentally used the same variable for both and introduced a bug. So where one of those got in my way, I've renamed it to 'toret' or 'retd' (the latter short for 'returned') in line with my usual modern practice, but I haven't done a thorough job of finding all of them. Finally, one amusing side effect of doing this is that I've had to separate quite a few chained assignments. It used to be perfectly fine to write 'a = b = c = TRUE' when a,b,c were int and TRUE was just a the 'true' defined by stdbool.h, that idiom provokes a warning from gcc: 'suggest parentheses around assignment used as truth value'!
2018-11-02 22:23:19 +03:00
bool portfwdmgr_unlisten(PortFwdManager *mgr, const char *host, int port)
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-21 00:09:54 +03:00
{
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 22:50:29 +03: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-21 00:09:54 +03: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 22:50:29 +03: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-21 00:09:54 +03:00
}
Low-level API to open nonstandard port forwardings. The new portfwdmgr_connect_socket() works basically like the existing portfwdmgr_connect(), in that it opens an SSH forwarding channel and gateways it to a Socket. But where portfwdmgr_connect() started from a (hostname,port) pair and used mgr->conf to inform name lookup and proxy settings, portfwdmgr_connect_socket() simply takes a callback that it will call when it wants you to make a Socket for a given Plug, and that callback can make any kind of Socket it likes. The idea is that this way you can make port forwardings that talk to things other than genuine TCP connections, by simply providing an appropriate callback. My immediate use case for this is for agent forwarding, and will appear in the next commit. But it's easy to imagine other purposes you might use a thing like this for, such as forwarding SSH channels to AF_UNIX sockets in general.
2020-01-01 19:46:31 +03:00
struct portfwdmgr_connect_ctx {
SockAddr *addr;
int port;
char *canonical_hostname;
Conf *conf;
};
static Socket *portfwdmgr_connect_helper(void *vctx, Plug *plug)
{
struct portfwdmgr_connect_ctx *ctx = (struct portfwdmgr_connect_ctx *)vctx;
return new_connection(ctx->addr, ctx->canonical_hostname, ctx->port,
false, true, false, false, plug, ctx->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 19:04:39 +03: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)
{
Low-level API to open nonstandard port forwardings. The new portfwdmgr_connect_socket() works basically like the existing portfwdmgr_connect(), in that it opens an SSH forwarding channel and gateways it to a Socket. But where portfwdmgr_connect() started from a (hostname,port) pair and used mgr->conf to inform name lookup and proxy settings, portfwdmgr_connect_socket() simply takes a callback that it will call when it wants you to make a Socket for a given Plug, and that callback can make any kind of Socket it likes. The idea is that this way you can make port forwardings that talk to things other than genuine TCP connections, by simply providing an appropriate callback. My immediate use case for this is for agent forwarding, and will appear in the next commit. But it's easy to imagine other purposes you might use a thing like this for, such as forwarding SSH channels to AF_UNIX sockets in general.
2020-01-01 19:46:31 +03:00
struct portfwdmgr_connect_ctx ctx[1];
const char *err_retd;
char *err_toret;
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 19:04:39 +03:00
/*
* Try to find host.
*/
Low-level API to open nonstandard port forwardings. The new portfwdmgr_connect_socket() works basically like the existing portfwdmgr_connect(), in that it opens an SSH forwarding channel and gateways it to a Socket. But where portfwdmgr_connect() started from a (hostname,port) pair and used mgr->conf to inform name lookup and proxy settings, portfwdmgr_connect_socket() simply takes a callback that it will call when it wants you to make a Socket for a given Plug, and that callback can make any kind of Socket it likes. The idea is that this way you can make port forwardings that talk to things other than genuine TCP connections, by simply providing an appropriate callback. My immediate use case for this is for agent forwarding, and will appear in the next commit. But it's easy to imagine other purposes you might use a thing like this for, such as forwarding SSH channels to AF_UNIX sockets in general.
2020-01-01 19:46:31 +03:00
ctx->addr = name_lookup(hostname, port, &ctx->canonical_hostname,
mgr->conf, addressfamily, NULL, NULL);
if ((err_retd = sk_addr_error(ctx->addr)) != NULL) {
err_toret = dupstr(err_retd);
goto out;
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 19:04:39 +03:00
}
Low-level API to open nonstandard port forwardings. The new portfwdmgr_connect_socket() works basically like the existing portfwdmgr_connect(), in that it opens an SSH forwarding channel and gateways it to a Socket. But where portfwdmgr_connect() started from a (hostname,port) pair and used mgr->conf to inform name lookup and proxy settings, portfwdmgr_connect_socket() simply takes a callback that it will call when it wants you to make a Socket for a given Plug, and that callback can make any kind of Socket it likes. The idea is that this way you can make port forwardings that talk to things other than genuine TCP connections, by simply providing an appropriate callback. My immediate use case for this is for agent forwarding, and will appear in the next commit. But it's easy to imagine other purposes you might use a thing like this for, such as forwarding SSH channels to AF_UNIX sockets in general.
2020-01-01 19:46:31 +03:00
ctx->conf = mgr->conf;
ctx->port = port;
err_toret = portfwdmgr_connect_socket(
mgr, chan_ret, portfwdmgr_connect_helper, ctx, c);
out:
sk_addr_free(ctx->addr);
sfree(ctx->canonical_hostname);
return err_toret;
}
char *portfwdmgr_connect_socket(PortFwdManager *mgr, Channel **chan_ret,
Socket *(*connect)(void *, Plug *), void *ctx,
SshChannel *c)
{
struct PortForwarding *pf;
const char *err;
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 19:04:39 +03:00
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 09:24:16 +03: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 19:04:39 +03: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 22:50:29 +03:00
pf->input_wanted = true;
Convert a lot of 'int' variables to 'bool'. My normal habit these days, in new code, is to treat int and bool as _almost_ completely separate types. I'm still willing to use C's implicit test for zero on an integer (e.g. 'if (!blob.len)' is fine, no need to spell it out as blob.len != 0), but generally, if a variable is going to be conceptually a boolean, I like to declare it bool and assign to it using 'true' or 'false' rather than 0 or 1. PuTTY is an exception, because it predates the C99 bool, and I've stuck to its existing coding style even when adding new code to it. But it's been annoying me more and more, so now that I've decided C99 bool is an acceptable thing to require from our toolchain in the first place, here's a quite thorough trawl through the source doing 'boolification'. Many variables and function parameters are now typed as bool rather than int; many assignments of 0 or 1 to those variables are now spelled 'true' or 'false'. I managed this thorough conversion with the help of a custom clang plugin that I wrote to trawl the AST and apply heuristics to point out where things might want changing. So I've even managed to do a decent job on parts of the code I haven't looked at in years! To make the plugin's work easier, I pushed platform front ends generally in the direction of using standard 'bool' in preference to platform-specific boolean types like Windows BOOL or GTK's gboolean; I've left the platform booleans in places they _have_ to be for the platform APIs to work right, but variables only used by my own code have been converted wherever I found them. In a few places there are int values that look very like booleans in _most_ of the places they're used, but have a rarely-used third value, or a distinction between different nonzero values that most users don't care about. In these cases, I've _removed_ uses of 'true' and 'false' for the return values, to emphasise that there's something more subtle going on than a simple boolean answer: - the 'multisel' field in dialog.h's list box structure, for which the GTK front end in particular recognises a difference between 1 and 2 but nearly everything else treats as boolean - the 'urgent' parameter to plug_receive, where 1 vs 2 tells you something about the specific location of the urgent pointer, but most clients only care about 0 vs 'something nonzero' - the return value of wc_match, where -1 indicates a syntax error in the wildcard. - the return values from SSH-1 RSA-key loading functions, which use -1 for 'wrong passphrase' and 0 for all other failures (so any caller which already knows it's not loading an _encrypted private_ key can treat them as boolean) - term->esc_query, and the 'query' parameter in toggle_mode in terminal.c, which _usually_ hold 0 for ESC[123h or 1 for ESC[?123h, but can also hold -1 for some other intervening character that we don't support. In a few places there's an integer that I haven't turned into a bool even though it really _can_ only take values 0 or 1 (and, as above, tried to make the call sites consistent in not calling those values true and false), on the grounds that I thought it would make it more confusing to imply that the 0 value was in some sense 'negative' or bad and the 1 positive or good: - the return value of plug_accepting uses the POSIXish convention of 0=success and nonzero=error; I think if I made it bool then I'd also want to reverse its sense, and that's a job for a separate piece of work. - the 'screen' parameter to lineptr() in terminal.c, where 0 and 1 represent the default and alternate screens. There's no obvious reason why one of those should be considered 'true' or 'positive' or 'success' - they're just indices - so I've left it as int. ssh_scp_recv had particularly confusing semantics for its previous int return value: its call sites used '<= 0' to check for error, but it never actually returned a negative number, just 0 or 1. Now the function and its call sites agree that it's a bool. In a couple of places I've renamed variables called 'ret', because I don't like that name any more - it's unclear whether it means the return value (in preparation) for the _containing_ function or the return value received from a subroutine call, and occasionally I've accidentally used the same variable for both and introduced a bug. So where one of those got in my way, I've renamed it to 'toret' or 'retd' (the latter short for 'returned') in line with my usual modern practice, but I haven't done a thorough job of finding all of them. Finally, one amusing side effect of doing this is that I've had to separate quite a few chained assignments. It used to be perfectly fine to write 'a = b = c = TRUE' when a,b,c were int and TRUE was just a the 'true' defined by stdbool.h, that idiom provokes a warning from gcc: 'suggest parentheses around assignment used as truth value'!
2018-11-02 22:23:19 +03:00
pf->ready = 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 19:04:39 +03:00
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 14:14:00 +03: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 19:04:39 +03:00
pf->socks_state = SOCKS_NONE;
Low-level API to open nonstandard port forwardings. The new portfwdmgr_connect_socket() works basically like the existing portfwdmgr_connect(), in that it opens an SSH forwarding channel and gateways it to a Socket. But where portfwdmgr_connect() started from a (hostname,port) pair and used mgr->conf to inform name lookup and proxy settings, portfwdmgr_connect_socket() simply takes a callback that it will call when it wants you to make a Socket for a given Plug, and that callback can make any kind of Socket it likes. The idea is that this way you can make port forwardings that talk to things other than genuine TCP connections, by simply providing an appropriate callback. My immediate use case for this is for agent forwarding, and will appear in the next commit. But it's easy to imagine other purposes you might use a thing like this for, such as forwarding SSH channels to AF_UNIX sockets in general.
2020-01-01 19:46:31 +03:00
pf->s = connect(ctx, &pf->plug);
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 19:04:39 +03:00
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 17:03:47 +03:00
}