Support reverse proxying of SFTP/SCP sessions

[Castaglia]

Just as mod_proxy does for FTP sessions, it would be great if mod_proxy could also proxy (reverse and forward) SFTP/SCP connections, e.g. for mod_sftp.

Update as of 2022-05-04: Since there is no clear path to implementing forward proxying of SSH connections, I'm going to restrict the scope of this ticket to just reverse proxying of SSH connections.

[Castaglia]

Implementing this functionality, in mod_proxy, would be much easier if I could reuse the code that mod_sftp uses, for formatting the SSH2 packets and encrypting/decrypting them properly. Obviously I could simply copy the mod_sftp code into mod_proxy, but that's bad practice, code-wise. So working on this may require/depend on some changes to mod_sftp.

[aderumier]

Hi, do you have a roadmap for this feature ?

[Castaglia]

@aderumier I do not, as yet, have any particular timeline planned for this feature. However, I suspect that it may require some changes in the mod_sftp module itself, and thus will probably happen after proftpd-1.3.6-stable is released.

Do you have particular need for that functionality? If so, I'd like to hear more (perhaps via email) about it!

[aderumier]

@Castaglia No special need, I would like to have a reverse proxy sftp, something like your current reverse ftp implementation. (I'm looking to build a reverse proxy with both ftp/sftp support).

Thanks for your great work !

[kevy1234]

I'm trying to set up an sftp reverse proxy server in DMZ too which relays sftp requests to the internal proftpd server, any suggestions on how to get this done prior to this feature being added?

[Castaglia]

@kevy1234 if your reverse proxy needs are simple, you should be able to use a simple TCP proxy (e.g. haproxy) to proxy the TCP connection between DMZ and backend server. SFTP is a single TCP session. So if your proxy doesn't need to know anything about users, or specific algorithms -- if it only needs to proxy the connection, then a TCP proxy should work.

[kevy1234]

@Castaglia Would there be any security concerns? What we would like to do is terminate user connections in DMZ.
Thanks for the comments.

[Castaglia]

@kevy1234 An excellent question, with several different components.

Terminating connections at the DMZ is a Good Thing. And fortunately, for SFTP/SCP, it is usually enough to terminate the TCP connection at the DMZ, and have some TCP proxy relay that connection to the actual SFTP/SCP server within the LAN. With this sort of arrangement, you can do TCP connection-based load balancing. The external SFTP/SCP client does not (and cannot) know the IP address of the internal server handling the connection. (Unfortunately, because of the DMZ relay, this also means that the internal server cannot know the IP address of the remote client; there are ways of handling this, though.)

Where mod_proxy will (in the future) help with this situation is to be able to do load balancing based on things like the SSH key used, or the specific users, etc -- balancing based on information that is only available if the proxy speaks SSH, rather than just TCP. The mod_proxy module would also allow for things like authenticating the users in the DMZ, and then having the backend SFTP/SCP session use a different username, so that user authentication is centralized/managed in the DMZ, "at the edge" as it were. Some deployments like that sort of arrangement, some do not.

Does that help answer some of your questions/concerns?

[kevy1234]

@Castaglia Very well explained, thank you!
If this is the case, instead of mod_proxy we should be able to use Haproxy Tcp mode in DMZ to proxy FTP/FTPS services as well, am I correct?

[Castaglia]

Unfortunately, using haproxy for FTP/FTPS, as well as SFTP, does not work that well.

The difference is that SFTP/SFTP is based on SSH, and SSH uses single TCP connection only. This means that haproxy, acting as a TCP proxy, will work.

FTP/FTPS, however, uses multiple independent TCP connections: one for the control connection (over which the commands/responses are sent), and other ephemeral data connections, one for each data transfer. These data connections, to make matters worse, use ports which are dynamically negotiated over the control connection (that's the purpose of FTP's PORT, PASV, EPRT, and EPSV commands). This means that haproxy would have to proxy multiple TCP connections -- and it won't know which TCP connections to proxy to the same backend servers.

So, short answer is this: mod_proxy is needed for proxying FTP/FTPS sessions (and this is what it does now). mod_proxy does not (yet) work for proxying SFTP/SCP sessions; you should be able to use e.g. haproxy for proxying SFTP/SCP sessions for now.

[kevy1234]

In your future release it would be great if you can make sftp to ftp proxy work , and vise versa.

[Castaglia]

@kevy1234 Agreed -- but that would be a slightly different task (for which I've opened Issue #86 ).

[kevy1234]

Any progress on this feature?

[Castaglia]

This is currently waiting on some work in mod_sftp proper; see proftpd/proftpd#435. That will reduce the work greatly, i.e. avoiding having to re-implement/copy a lot of code.

[StrongTux]

Hello @Castaglia, making this work would be awesome, i'm currently strugling with reverse sftp/scp proxying...

I will try the tcp proxy, many thanks :)

[Castaglia]

I've just now merged support for the "sticky" reverse connection policies (PerUser, PerGroup, PerHost) for SSH connections.

In terms of remaining work, I've decided that forward proxying of SSH connections will have to wait, as there is no clear path/means for implementing that in a general/interoperable manner. As for the other items, I've filed separate tickets:

• Encrypt-Then-Mac digests (see Implement OpenSSH Encrypt-Then-MAC (ETM) SSH digests #216)
• AAD ciphers such as [email protected] (see Implement AAD SSH ciphers such as AES-GCM #217)

Before I close this ticket, however, I will finish the necessary proxying documentation. As before, please feel free to contact me directly, if you'd like to try this out, while I work on the documentation.

[Castaglia]

Now implemented in master; I hopefully do a release soon.