PuTTY wish portfwd-dynamic-remote

This is a mirror. Follow this link to find the primary PuTTY web site.

summary: Remote-to-local SOCKS-based dynamic port forwarding
class: wish: This is a request for an enhancement.
difficulty: tricky: Needs many tuits.
priority: low: We aren't sure whether to fix this or not.

PuTTY doesn't currently support the remote-to-local direction of dynamic port forwarding, i.e. opening a listening port on the SSH server which functions as a SOCKS server, and responds to requests by making network connections on the client side.

This wouldn't be too difficult to implement in principle. The PuTTY code base already contains all the necessary pieces.

What worries me about it is that there are surely a lot of use cases that don't really want to expose all of the SSH client's local network to the SSH server. SSH servers are often multiuser machines, and a client user's LAN is likely to contain all kinds of poorly secured internal services, and probably in many cases you didn't really want to give all the other users on the server machine access to all those insecure endpoints. So I feel as if, for many uses of this kind of feature, you'd want some kind of passlist/blocklist system that lets you configure what destinations the SOCKS server is willing to let its clients connect to.

That's not too hard in implementation terms, but it's a lot of design effort, because there are so many ways you might want to specify individual passlist/blocklist entries or ranges of them:

by exact match or range match on the destination IP address
by exact match or wildcard match on the input hostname sent down the SOCKS connection (if the server sends one in place of a numeric address)
by exact match or wildcard match on the canonical hostname obtained from a DNS lookup of the provided address or name
a bunch of Boolean logic to specify how to combine those host-based criteria with port numbers, or with each other

and so many ways you might organise the whole collection of individual entries:

pure passlist-based system (list of acceptable destinations)
pure blocklist-based system (list of forbidden destinations)
multiple rule types, with a priority order defined explicitly in the config file
multiple rule types, with an implicit ‘most specific wins’ rule to decide which entries take priority
- … but what counts as more specific, out of an IP range and a canonical-hostname wildcard, which could easily match nontrivially overlapping sets of hosts and the system doesn't know how large those sets are?

By the time you have a full-featured system that can specify all of those things, you've probably written an almost Turing-complete configuration language, which is used solely for this one niche feature of an SSH client. On the other hand, if you leave out any of this stuff, Murphy's Law guarantees that the next user will desperately need whichever part you didn't bother with!

So when I've thought about this in the past I've tended to feel that a more flexible solution is to run a separate SOCKS server on the client machine, and point an ordinary remote port forwarding at that. A dedicated SOCKS server program is likely to have some kind of configuration system already for this kind of thing, so PuTTY wouldn't have to make up its own from scratch. And there would be nothing tying this solution to a particular SOCKS server – you'd be free to use whatever SOCKS server you liked the feature set of best, instead of being constrained to use only the provided one with its limited range of configuration.

(Of course, you could have made the same argument about the existing local-to-remote dynamic forwarding! In the most typical use case of SSH, running a login session on a remote Unix machine where you have a full-featured shell account that can run programs of your choice, there's no reason you couldn't implement that forwarding mode in exactly the same way, by running a SOCKS server on the remote machine and forwarding an ordinary port to it. But the difference is that if you're not in that most typical use case of SSH – e.g. because your access to the server machine is locked down, or perhaps it's a special-purpose device in the first place which can't run arbitrary programs – then you may not have the freedom to run a SOCKS server remotely. So, in that case, local dynamic forwarding really is giving you something you couldn't achieve any other way. Whereas if you're able to run PuTTY on your client machine then you're probably also able to run a SOCKS server on the same machine.)

(The latest PuTTY source code does have the ability to build a very simple standalone SOCKS server, 'psocks'. This is built from bits that were lying around in PuTTY anyway, so it doesn't have any of the configurability discussed above.)

If you want to comment on this web site, see the Feedback page.

Audit trail for this wish.

(last revision of this bug record was at 2021-04-20 21:02:23 +0100)