I suggest not bothering to try to "win" this "argument". Note false statements, and leave it that. People will continue to be wrong on the internet no matter what you do.

He's right about restricting users and other methods of hardening SSH. I've used SSH for years and love it. But I'm looking in to VPN to see what use it could be.

Please, please, understand that I am not(!!) "saying that you should not use SSH!"

After all, "why on earth should I be?"

It should be perfectly obvious to one and all that "here we have two (actually, more than two ...) security technologies that are equally available to us." My OP-purpose was actually never to "slam" one in favor of the other.

Rather, my entire original purpose was – and still is – to point out how one could be used to achieve very-significant pragmatic advantages. Particularly if one was used as an "outer bastion" front-end to the other.

Each technology is "more-than venerable." Legendary, by now. And yet, "by design, not the same." Therefore, it ought to be obvious that I could not be advocating an "either/or" decision. Such a proposition is technically meaningless. Therefore, I would have thought it to be quite clear that this could not have been my latent intention.

I have utterly no "personal skin in this game." I am merely introducing a cryptographic technology that might be less well-known to this community, but which might be of significant pragmatic use to them ... as it certainly has turned out to be, for Yours Truly.

"That is all."

Okay, okay! I'm sorry. I got carried away and lost the whole point of the discussion.

I'm still trying to find a good guide on how to actually set up OpenVPN. This one seems pretty straightforward, although it does refer to some scripts which seem to be Debian specific (or at least easy-rsa specific):

https://wiki.debian.org/OpenVPN

It seems to only describe static key and self signing, which is good enough for my purposes.

It still seems to me a lot more complex than OpenSwan:

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

Either way, it's probably not a good idea to use either VPN as an outer layer for ssh access, if ssh access is all you ultimately want (i.e. remote command line access and/or sshfs). If you follow a random guide on setting up OpenVPN, it will set things up so that all ports are allowed, not just the ssh port. Even worse, it will route/bridge all ports through the VPN server so all computers within the LAN are exposed! This opens up a lot of potential vulnerabilities, especially considering the potential for mistakes, compared to only configuring ssh (and not installing VPN at all).

With ssh only, only the ssh server itself is exposed, and only the ssh process explicitly given the key file's passphrase by the user will be able to connect.

One thing that should be clarified is that "any VPN acts as a network appliance, constructed in software. OpenVPN reserves for its own use a range of IP-addresses – generally 10.8.0.x. It assigns itself positions #1 and #255 (broadcast address), and anything that is directly connected to it will have an address with x > 1. These are the addresses of "the various software routers that exist on this virtual network," including perhaps your own laptop at the coffee shop. These are also the addresses through which traffic bound for attached subnets will be routed to their destinations, using routing directives that OpenVPN itself will issue.

This, then, is also the address that your sshd or what-not would "listen to" for connection requests, at the exclusion of any-and-all public addresses. This represents traffic that is coming in through the tunnel.

Isaac, you are correct that VPNs function as a router, but you can in fact control exactly what is and isn't exposed on the various subnets (and the host machine), to the extent that you so choose. Particularly if you use tunnel mode ("a router") rather than bridge mode ("a dumb switch"), you do have control. The resulting situation is really just like it would be if you were actually using a computer that was physically connected to the networks in question with a piece of wire and a plastic box with blinking lights on it. However, you can positively identify each and every user who is authorized to connect, because every one of them has a unique credential which you issued, and which you can also selectively revoke. You're not "exposing" anything to anyone other than a trusted user, who you would also trust not to fsck things up if (s)he were physically inside the building.

One very-pragmatic reason why companies use VPNs as an outer bastion (or, as their entire defense) is that employees do leave the company from time to time. They don't want to have to change passwords and they don't want to worry about someone "slipping a Mickey" in the form of a rogue SSH-key that no one knew about. The ability to have "router" functionality, identical to that of a real plastic box, is also very useful to them. (Some companies put their VPNs into these plastic boxes. Even off-the-shelf routers often support IPSec (OpenSWAN), and many nowdays also support – or can be readily made to support – OpenVPN.) The resulting security is unobtrusive to the end-user, and can be centrally managed. (Key-materials can be distributed using LDAP, for instance.)

But, unlike (ordinary) SSH, VPNs do connect networks, not users. They function as routers or bridges, not shells.

Yes, and that's more exposure than I'm comfortable with. It depends on the situation, of course, and what the goals are.

Most enterprises do not allow employees to connect their own laptop to their internal network via ethernet cable. It's not just a matter of trusting the user. It's a matter of trusting the user's computer.

In my case, I do trust the user (myself only). But I trust my on-the-go laptops less than I trust the computers which stay at home.

So what's the typical solution? Lock down the VPN server within a DMZ that provides only the required level of access and no more (such as only rdesktop to the user's assigned workstation). In other words, the VPN server should be outside the trusted internal network. But this is something which none of the OpenVPN how-tos I've looked at so far even mention.

This contrasts with another use case, which is to connect the trusted internal networks of 2+ offices together. This has nothing to do with user level access, it's just linking up trusted internal networks together over the Internet in a secure way.

Understand what he said: A VPN can work in one of two modes... bridged or router. You're viewing it as bridged only, but services can be restricted in router mode.

My point is that this is NOT what is described in the OP's suggested usage, nor is it what is described in the how-tos I have gone through so far. What I've seen is setting things up so that all ports are routed through, implicitly assuming the computers on both ends are trustworthy.

In contrast, if you look up a how-to on how to set up ssh securely, you will see a bunch of very similar how-tos which show you how to set up secure key based ssh. There is a wide agreement on ssh best practices, and it's simple and straightforward to set up securely according to those best practices.

It's not like that with OpenVPN. From what I can tell so far, there are three main usage cases which these how-tos cater to:

1) Privacy oriented where you route everything through a VPN (web browsing in particular). The basic idea is to try and minimize how much information about you can be gleaned by packet sniffers when you're web browsing in a coffee shop. Typically, there is only one client user (yourself).

2) Connecting up to a VPN from somewhere on-the-road so you can access various resources as if you were located at home base. Typically, this involves multiple client users.

3) Connecting 2 fixed offices to each other so they act like they're all on the same LAN. In this case, the IP addresses on both ends are fixed, and the connection is permanent.

There isn't one set of best practices, because those 3 use cases are very different from each other. Best practices for at least 1 and 3 would definitely involve routing all ports through. I'm not so sure about best practices for case 2, but the how-tos I've seen so far all revolve around routing all ports through.

I just happen to know that's not the thing enterprises typically do because I have some experience with enterprise VPN setups. But if someone is just trying to set up OpenVPN without previous outside knowledge about that, then they're not going to see something telling them otherwise. Nor will the typical how-to (which I've seen so far) tell them to be restrictive on the ports routed through. Nor does the OP's blog posts suggest being restrictive on the ports routed through.

I haven't had time to investigate this yet, but the first thing I'll do is determine whether OpenSwan or OpenVPN is more secure.

And I've gathered that setup for OpenVPN is sprawling. Trust me, email (Postfix/Dovecot) is ten times worse than anything I've done in the past 20 years.

Times like that I go to what I think is the best documentation for these things: ArchWiki and Gentoo docs.

Quantum, my intuitive opinion is that both OpenSWAN and OpenVPN are – like SSH – "venerable encryption technologies" that are widely used and therefore also widely peer-reviewed. If used properly, I think that all three can be trusted to do their jobs.

Isaac, I think that you have identified the three use-cases quite rightly, and I acknowledge freely that the blog-posts could be further improved. There are all sorts of further security precautions that could be implemented, particularly because the traffic that's going into the tunnel does so through the client's network stack, and the traffic that's coming out does so through the host's stack. VPN solutions also impose various other controls, such as, "should simultaneously-connected users be able to see and to talk to each other?" An all-inclusive blog post, though, just might become incomprehensible.

Sincere thank-yous to both of you for your continued comments and valuable insights.

You're welcome, and I'm sorry for going off the rails there.

As for which is more secure - here's how I think about it for my purposes:

A) If we assume no usage of a third party CA, and we assume there is no fatal flaw in the key generator*, 2048-bit key generation will produce a key which just can't be brute forced.

B) Given the practical impossibility of brute forcing a truly random 2048-bit key, the big question is whether or not you can set things up so that you are truly secured by that key.

C) The big problem points are software developer error and sysadmin error.

So, what about software developer error? Honestly, I'm not a crypto expert and it takes a crypto/security expert to have a good idea of how OpenVPN and OpenSwan stack up to each other. I mean, you can't just count bug reports because the nature of the bugs matter a lot. Since I have no idea how they stack up to each other here, I'll go on the working assumption that it's a wash.

That leaves sysadmin error. That's the big reason I'm more comfortable with simpler things. But that's a judgement call you'll have to make for yourself.

Going through different how-tos on setting up OpenVPN, I'm getting more and more comfortable with the Debian how-to. Obviously I'm biased because I use Debian the most - I won't have to do any "translation" to Debian quirks the way I do when I'm using a Gentoo or Arch document.

* (Unfortunately the infamous Debian SSL bug noticed in 2008 demonstrates that it is possible that there could be a fatal flaw in the key generator.)

Granted. But this is where we stand on the shoulders of giants. I'm sure there are reviews by highly-qualified cryptologists somewhere, and failing that maybe I'll search for problem reports, failures, and breaches of the two respective methods.