On 26/3/25 03:45, Nicolas George wrote:
Let us not exaggerate please. A ssh server publicly available on its usual port is annoying with the logging noise, but unless you are very constrained in terms of CPU or bandwidth it is not a danger.
The general principal is to not expose any system/service you aren't prepared to have compromised. e.g. if you expose an IIS server to the internet you will do it only with a VM and have no valuable content on it, and certainly no connection to the rest of your systems.
For my openvpn service I have an isolated openvpn host and a firewall between it and my internal network. With the firewall I can detect if my openvpn host is compromised and can limit any exploitation.
A second general principal is to minimise the attack surface. That is if you have two potentially vulnerable services (here ssh and VPN) then exposing only one reduces the number of potential vulnerabilites.
An arrangement where you use VPN as your primary public service and ssh as something carried through the VPN means an attacker must first compromise the VPN and then compromise ssh. This is much less likely than a compromise of either individually.
The reverse model of ssh as the public service and VPN tunneled through it is something I have done before but it was much harder for users and had poor performance.
