This is entirely true, but VPN is engineered to act as a secure router (or bridge), implemented in software. You could implement a third subnet on your network, which is located somewhere else and reached through the Internet, and with VPN you would know with whom you were communicating, and you would (if you do it right) also know that no one else on the planet can discover the link (in order to try to log on to it), let alone penetrate it.

I think I'm giving up on OpenVPN after reading many different guides on getting started with it. Too many different ideas on how to secure it, too complex, too many different places to make mistakes and have stumbling blocks. For on-the-road access, I'm more comfortable with the simple and limited ssh on custom port. Even if someone gets the key file, the passphrase still protects it, and it's only for a single non-root user.

For internal use within my LAN, it seems OpenSwan may be easier to set up. Fits on one page:

https://wiki.debian.org/HowTo/openswan

(Obviously, I'll use "systemctl restart ipsec" rather than the init.d script.)

Since I'll be using this strictly for computer-to-computer access within a shared LAN, I'll need to set up dummy interfaces rather than "real" subnets, but this seems simple enough.

Sadly that has been my experience also. I've set up (simple) LAMP servers with HTTPS and use SSH with keys but just can't find a straightforward guide for getting OpenSSH running.

"So, is that why your servers spend X% of their time fighting-off Y,000 'unauthorized access attempts' per hour," until one of their dictionary-bots finally, by pure brute-force tactics, manages to penetrate your system and install a root-kit?"

Even though (Open)VPN documentation is not the best, in my blog, right here, I have sincerely attempted to share the product of my experiences , and I am happy to write more installments.

I found that there are basically two obstacles to the adoption of VPN, among users who are accustomed to SSH:

1. The notion that a VPN serves the role of a network appliance, either a "router" or (much less commonly) a "switch." Frankly, many users have never encountered a network which involved the use of a router other than their "internet router," and have never dealt with "round-trip TCP/IP routing issues" of any kind.
2. The process of creating and then setting-up a TLS "self-signing CA" and then issuing certificates under it. (And subsequently managing those certificates.)

"Real-world" encryption technologies are all about "Alice and Bob, and Eve." (And they never(!) assume that "Eve" can actually "successfully pretend to be Alice, such that Bob cannot tell the difference," merely(!) by "Saying the Magic Word!™") Therefore, they do require a certain amount of patience. Until you get "the entire(!) incantation" just right, the door will not open. And, quite by design, it will strive to give you "not one single miserable hint" what you (presumed to be "Eve!") did wrong.

However, if you persevere, just one time, you will be rewarded with ... silence. With security logs that are ... empty.

P.S.: I will be more than happy to write new articles in my blog, here.

Like I noted before, I looked at your four blog articles, and none of them describe how to set this up.

I'm actually a bit puzzled that you don't already have some sort of documentation of what to do. I have set up various things on my main server, and I have instructions for myself on how to do it all over again. These instructions aren't entirely readable for others, but I include enough detail for myself to replicate what I've done. I've done so several times, because I like to have a drop-in replacement server and I also like to occasionally do a fresh reinstall (about once every Debian Stable release).

I mean, look at my blog. All 8 of my blog posts are detailed instructions on how to do something. Do you think that's only for the benefit of others? Nope, I'm sure the person who refers to them the most is myself. So, not only do I say why you'd want to do X, I also describe how to actually do X. It helps others, sure, but it also helps myself.

My point is - if I had to build a replacement server and install/set up from scratch, I could and it would be done in one night's work thanks to the instructions I maintain for myself.

So why don't you have your own instructions, even if only for your own use? Are you confident that you could replicate your VPN server quickly after a fresh linux install? If not, why not?

I personally wouldn't be comfortable with anything I couldn't set up over again in a straightforward way. When I set up a new server, I don't expect to bang my head against a wall. I expect to follow my notes and for it to work.

Note that you don't need to make a blog post that's more "user friendly" than an info dump. Sometimes, your notes consist of little more than fragments of configuration files and copy/paste commands to enter. It may not be the easiest thing for others to comprehend, but you can just post an info dump and then maybe modify it later with explanations. A lot of times, just seeing raw config file fragments can be more helpful than a wordy description of what to do in the abstract. (My own blog posts combine wordy descriptions with config files/script fragments.)

As for security logs - as others have already noted, this just isn't a problem with ssh on a custom port. Custom ports for ssh just don't get hit often, and even if they did it doesn't matter with password authentication turned off.

A VPN server is much harder to set up than an SSH server. IMHO, there's no comparison between the two in that regard. You will have to don your learning hat to get the most functionality/security out of VPN if you don't already know how to configure it. Same goes for SSH, but the learning hat is much smaller.

Saying "always use UDP for VPN" is entirely too simplistic. I agree that most of the time, for most users, UDP is the way to go. However there are times when TCP will offer more functionality (breaking through restrictive firewalls), or (paradoxically) better performance (when faced with large scale packet loss or rearrangement of packet order).

Next up, you have to decide it you want a TUN or a TAP VPN setup. TUN is also called "a routed VPN" and TAP is called "a bridged VPN". Bridging is easier to set up and comprehend, but routed gives you more fine-tuned control. e.g., You can easily firewall stuff with a routed VPN - not so easy in a bridged one (you can't use iptables for something that is bridged, you have to go to a lower level). So your choice between TAP/TUN will depend on the level of access you want to grant and the amount of trust you have in your VPN users. You can assign VPN users specific IP addresses based on their cert. So when "Fred" comes in, you know it is him for sure, you give him a specific IP address that does not vary, and thus you can control what he can access via iptables rules (on a routed VPN). "Bob" then comes in, has a totally different IP address assigned to him, and you can give him completely different access to things than you gave to "Fred".

VPN is more powerful and flexible than SSH. But with that power and flexibility comes quite a bit of added complexity. And the more you want to up the security, the more complex it gets as well. login/password is the least secure, but the easiest to set up. Next, in the SSH world, comes pubkey authentication. Much better than login/password. But not as good as certificates. Certificate authentication is the standard in VPN (although you can set authentication in other ways). I consider pubkey the standard for SSH in my installations, but many would argue that login/password is the standard in their installations. You can use certificates in SSH. I am not up-to-date in OpenSSL vs. certs. It used to be that OpenSSL (opensource, free) didn't support them, but maybe they do now. I remember having to use Tectia SSH (commercial, paid) to enable client cert authentication years ago for a specific installation at work.

SSH is much easier to test than VPN. Assuming you are sitting at home and all your devices are on the same LAN, you can't bring up a VPN for testing (well you can, but it won't work reliably, probably not at all). This is because packet routings get very confused deciding to send packets directly over the LAN, or over the LAN via the VPN. SSH does not have this constraint, and you can easily test it with all devices on the same LAN.

Conclusion: There is no one answer to VPN vs. SSH. No one answer to UDP vs. TCP. No one answer to TUN vs. TAP. No one answer to login/password vs. pubkey vs. certificate authentication. Every situation has a different balance of ease vs. complexity and ease vs. security. Put on your learning hat and do some research before making a decision.

FWIW - at home, I run VPN on my router. Two instances. One is TUN/UDP, the other is TAP/TCP. Remotely I can connect either way, depending on the situation. But since I only implicitly trust myself, other users of my VPN (limited family members) are all TUN/UDP only. While they are trustworthy, I'm not so sure about the other environments that connect in, thus their actual devices could be compromised. My family VPN users are very tightly firewalled. By default they can't connect to anything, zero network activity allowed, unless I explicitly grant a specific access to each of them, on an individual basis. My router runs OpenVPN. There is a GUI for administering it. But I do not use that. I use good old manual config files that I set up from scratch. I do not trust the GUI configuration to do what I want to do. You never really know what those little GUI checkboxs actually do down in the bowels of the OpenVPN configuration. Some are obvious, others are not.

Also, I run SSH on my home router. Pubkey only. Very tightly configured. I am the only user allowed in. While SSH/pubkey is weaker than VPN/certificate, the way I have it configured it is strong enough for my personal needs, which is what matters.

Also, iptables on my router. Again, manually configured - not with the GUI checkboxes provided in the user interface.

1 members found this post helpful.

Although you have seen that I agree with you that a VPN makes life much easier, just wondering. I do need SSH access to my servers for maintenance and setup. Even if they are on a VPN, I must have SSH open. Is an additional requirement to deny SSH from any subnet except the VPN?

jlinkels

Doesn't apply to SSH with keys.

There are three basic problems with this:

1. Everyone in the Known Universe knows that "ssh" is there, and therefore they will do so.
2. It is actually quite difficult to prevent "ssh" from falling-back to a password prompt.
3. Even when an "ssh tunnel" is successfully established, you must take special precautions to ensure that your traffic is actually passing through it.

Without ... obviously ... "over-simplifying this matter," the VPN approach to security has compelling advantages because "it's just there."

• When you use VPN to connect your private network to another private network, you can basically forget that there is "an Internet" in the way.
• When you use VPN to connect to your private network from the outside, you can basically forget that you are "remote."
• When digital certificates and tls-auth are used, "unauthorized access attempts" become impossible.

"ssh" operates at a level above "the TCP/IP stack," while "VPN" operates within it.

Are you saying that "PasswordAuthentication no" in the sshd_config file is not sufficient?

Do what?

If you rephrase as "it's easy to neglect to forbid password login" I would agree, and it is a real drawback (default is not secure).

I think most people use ssh as a shell, so this is not much of an issue. That is, ssh isn't meant to be a replacement for VPN.

Lock it down with more than just "PasswordAuthentication no". The following is not a complete sshd config, it just touches on security related stuff. Also, some of the settings are not used because other settings negate their need. But it doesn't hurt to set them anyway.

I don't think it's difficult to instruct SSHD to not prompt for passwords. Pretty simple really - just say "no" to the things you don't want and "yes" to the things you do want.

I've spent a fair bit of time playing with virtual machines with various ports open to the internet and it's my experience that if SSH isn't on port 22 that cuts down script kiddies to practically zero*. As to brute force -- if they brute force the private key or my Pi then they've probably wasted a lot of computing power for virtually none. Sure, it's possible but unlikely.


*Less security through obscurity than log management.

The tricky bit is figuring out which things you want. Or that you need to say "no" or "yes" to things in the first place.

It's the same likelihood as brute forcing the VPN certificate.