From a risk perspective, there really isn’t a whole lot of difference between exposing OpenVPN to the internet on port 1194 and exposing a well configured SSH server on port 22 (or preferably some other non-standard port).
There can be many reasons why OpenVPN would not be an option (e.g. most corporate firewalls or machine policies will prevent joining a machine to a non-corporate VPN).
I’m not saying that a VPN isn’t a good option, but I don’t see how it’s any better of an option than SSH.
@Gad_Ofir, this is one of those cases where if you have to ask it might not be the best idea. It takes a lot of knowledge and skills to open up a port on your LAN’s firewall safely. My first choice would be to set it up in a way that doesn’t require opening any ports at all (not even for a VPN). For example:
Then your LAN won’t be under direct attack because it has no ports exposed.
If you insist on exposing a port for ssh, you need to do a lot to make sure it’s secured. Some best practices include:
- only allow certificate authentication, never allow passwords
- put a password on the certificate itself
- set up the NAT so a non-standard port is exposed
- set up Fail2Ban
- monitor the authentication logs and Fail2Ban logs
- if possible, isolate this ssh machine into a DMX with a firewall on both sides. The outside firewall doesn’t allow outgoing connections at all. The inside firewall only allows connection to the one destination machine. Configure this machine with a different set of certs to log into your actual machine, also password protected but with a different password.
I like the two approaches above because it puts that DMZ machine outside your LAN further limiting any attack’s ability to move into your LAN.