We have a situation where we have an architecture that calls for a Web based UI for querying some data and the data input is through rsync over SSH. I think it would be easier to manage and more secure if we just tunnel SSH through HTTPS so there is only 443 port open rather than have the web server listen on 443 and SSHD listen on some non-standard port (say 2222) and allowing connections on both. What will be the better solution and why?

  • 3
    can you describe how do you plan to tunnel your ssh traffic through https?
    – user284677
    Dec 16, 2022 at 8:55
  • If ssh listens on a port > 1024 and the server goes down, a rogue program running on that system (even as nobody) could stand up its own SSHD on that port. Otherwise, I don't see much risk. The only reason to tunnel ssh through https would be to avoid firewall restrictions.
    – Adam Katz
    Dec 16, 2022 at 17:16
  • If you run SSH only inside the tunnel then SSH related attacks from the public net shouldn't be possible. It maybe also helps a bit against fingerprinting the system for other attacks. Log noise should be lower. Working SSH depends on both the server software and SSH software so two possible points of failure.
    – secfren
    Dec 16, 2022 at 17:53
  • @Spyros - using something like httpd.apache.org/docs/2.4/mod/mod_proxy_connect.html Dec 18, 2022 at 19:29
  • so the web UI will initiate the data retrieval by using rsync+ssh+proxytunnel to connect to apache, that will act as a proxy and forward the connection to your ssh server. Is that correct? Also, why would it be necessary to run the ssh server on a non-standard port? Is it just to avoid unauthorized login attempts or there's a different reason? Will the ssh server be still accessible from the public if you use the apache proxy method?
    – user284677
    Dec 18, 2022 at 22:28

1 Answer 1


The fact that the SSH server listens on port 22 does not make it necessarily directly discoverable; you can block access to that port from the internet and only allow local access by using firewall rules (allowing access from your web server, but blocking it from anywhere else). Thus, you don't have to run the server on a random port just to avoid it being scanned. In the past, running a server on a non-standard port was used in the case where the server had to be accessible from the internet but was not desirable to be easily discoverable. However, this isn't a very practical approach for two reasons:

  • nmap can discover your server anyway (by scanning all ports)
  • running a critical server in a non-privileged port may introduce a security risk (users can run their own versions of servers on unprivileged ports)

Next, even if your server runs on a random port, you still have to block access to it from the internet. So, essentially, you'll have to set it up just like you would if it were running on port 22. As such, there isn't an actual advantage in running it on a non-default port.

Then, there's the problem of discoverability; the fact that you only allow your web server to access your SSH server (as a proxy), does not render the latter inaccessible from unauthorized users, but only makes it more difficult to do. People can use the proxy's CONNECT directive in order to scan for oper ports. This may be slower and more difficult than just scanning your box with nmap, but it's still feasible and has been used in the past with other proxied protocols (e.g. FTP bounce scanning).

So, which one to use? It depends on some key factors:

  • some SSH server implementations, and apache httpd, have stood the test of time, security wise (e.g. openssh, apache httpd). This allows for confidence in exposing them to the internet. Which means that even if your SSH server (in your case) is actually exposed to the internet and discovered, it should not by itself be a problem. Plus, proxy or no proxy, every client will still need to provide credentials in order to use rsync over ssh, which is more important to address than hiding the server
  • introducing mod_proxy and mod_proxy_connect makes configuring the apache web server more complicated; depending on your administration skill level, this may not be desirable compared to a simpler setup
  • as already stated, running your SSH server in a non-standard port does not have any benefit at all
  • as already stated, "hiding" your SSH server behind a proxy does not make it completely inaccessible
  • using ssh through a proxy requires installing and maintaining proxytunnel at your client side; there is maintainance effort associated with it, which may not be desirable
  • of course, if there are firewall rules that only allow access to port 443 from the internet, then you probably don't have any other choice but using the proxy setup

All in all, everything depends on your administration skills and the maintainance effort that you are willing to put on the solution. For me, if there's not a compelling reason to use the proxy feature (e.g. firewall rules) then I would go with the simpler setup of exposing SSH to the public and avoid the rest.

You must log in to answer this question.

Not the answer you're looking for? Browse other questions tagged .