I'd say it is.
Changing the below is typically all I'll do. Sometimes I'll spend a little more time on more public servers and more precise options, but they are generally options that deal with the two computers, and not "3rd parties".
However, I've yet to see, in any capacity, that the below is in any way more "insecure" then say, a vpn setup.

Setting up passwordless SSH is also very simple.
Not to mention I can do it completely in the command line without any guides
Also, accessing multiple, separate servers is very useful. Is this trivially possible with VPN? Seems like it'd mostly only be good for accessing a single (or group of related) servers.

Then change the below

I feel like this settles the issue.

You should probably address your concerns to the project's mailing lists: http://www.openssh.com/list.html

Some reading on proper SSH configuration from a reputable author: https://www.michaelwlucas.com/tools/ssh

Just a point of clarification for the users here that are new to this stuff: you do not find "certificates" in an "authorized_keys" file. You find "public keys". The two are quite different things. Since we have gone back and forth between "certificate authentication", "pubkey authentication" and "password authentication" in this thread, it's important to keep the terminology correct so as not to confuse the less experienced. This was just a simple typo by @sundialsvcs, but could throw some users into a fit of misunderstanding.

I know fail2ban.
But the OP claims that using an OpenVPN minimizes flooding the sshd with unauthorized login attempts. Since I do use OpenVPN and do not like some aspects of fail2ban, I'd like to know if the OP claims this because he knows a smarter way to avoid thousands of login attempts.

jlinkels

Apparently you need "ChallengeResponseAuthentication no" as well. That's the one that actually sends out the "Password: " challenge and is considered marginally more difficult for an attack script than is simple "PasswordAuthentication".

Do you have any examples of this being explioted? I ask because I can't say just as I type whether I have that set or not but I know that I cannot attempt to use SSH to connect to my machine without having a valid key.

I'm just going by what I read about the openssh options. Part of this is going to be controlled by what methods the local ssh agent is configured to try or fallback to.

Thank you for the clarification.

But, functionally speaking, the two are, at some level, similar: they are both things that you must possess a copy of, in order to gain access. They consist of thousands of strongly-pseudorandom bits, thereby creating a level of "entropy" that dwarfs that of any possible "password (PSK)." But a "public key" has no concept of, say, being "signed" by a "certifying authority (CA)." And, the SSH authorized-keys file for a particular user is located in a place that the user himself can access and control.

OpenVPN certificates use the same TLS/SSL technology that is at the center of "https" web-sites. Certificates are issued and then (self-)signed by a central authority (a "CA") within the company ... or, within your home, and it is that signature that makes them valid. They are stored in a place that users cannot reach, and they are not particular to any user. They do not grant "login access." VPN is a secure networking layer, [i]not[/u] any sort of a "shell."

With OpenVPN, if you do not possess a valid (tls-auth ...) preliminary certificate, you can't even attempt to connect. In fact, you can't even discover that an OpenVPN server is out there!

OpenVPN will reduce the "number of unauthorized access attempts" to ... zero.

Set up your "sshd" so that it listens only to the inside of the tunnel. Firewall it away from being able to access, or being accessible by, the outside world, and have it listen only to the virtual IP-address that represents the tunnel. Now, the only way to reach "sshd" is to first pass through the OpenVPN gantlet. (There are numerous Internet articles which describe exactly how to do this.)

Next, use tls-auth and strong, one-of-a-kind digital certificates to set up your OpenVPN. Authorized users bearing non-revoked credentials will be able to pass through easily, and then, having done so, they will perceive "sshd" and everything else that you've decided to expose.

Everyone else in the world finds – nothing at all! There are no "open ports" to "scan." Attempts to establish an OpenVPN connection are ignored, and this means that you can't even detect that an OpenVPN server exists. (The server "silently drops" the connection-request packet, having determined on the basis of this one packet's initial content that it was not provided by a possessor of the tls-auth certificate.)

After all ... think about it ... "who do you want to even give the opportunity to connect to your machine?" The whole damned world? I think not! But, at the end of the day, and in spite of the fact that it encrypts the traffic that it passes to the host, "sshd" is "a shell." And it just might be open to the entire world, maybe giving all of them this prompt:

:eek: login: :eek:

No, with ssh you only need plain user access to change the authorized_keys file for that user. However, I wouldn't be especially confident that your VPN server is safe after an intruder getting in "just" once.

Using both ssh and VPN is a reasonable choice.


This article seems fairly convincing that ChallengeResponseAuthentication is by default basically another form of password authentication (although it's meant to allow some other custom kinds of authentication).

There is no need to be mysterious about it. A certificate contains a public key encoded within it.

This is getting ridiculous. It just isn't hard to disable password login in sshd. Your scaremongering just makes your argument less credible.

It takes like 5 minutes for a newbie to read the entire sshd_config file and figure out how to say "n" to everything they don't want. It takes 2 minutes for a newbie to confirm that an attempt to ssh in does NOT produce a login prompt.

The only part that requires a tiny bit of outside knowledge is determining what would be a good custom port to use (e.g. one that isn't used for something else, and which isn't blocked by whatever filters the ISP may have).

That answers the question. Thanks

jlinkels

Come, now. There's no reason to take personal offense at an opinion, even if you don't agree! :) No "scaremongering" here. We're just talking about crypto technology here, and there are no hard-and-fast rules. Pax.

That being said – I can port-scan your entire IP-address in a couple minutes, and discover which port-number you are using, because you are using "a TCP/IP port." And then, I can discover that I am talking to "sshd." The next thing that my scanner must do is to try to throw a user-id and password at it. Yes, at that point I can determine whether you are allowing password authentication. (If you aren't, I know that it's useless to try. But you are the smart exception, not the rule. The typical experience is that instead "the hornets gather, by the thousands, incessantly pounding your system and sucking-up valuable resources in doing it, until you – poor slob – finally run out of dictionary." :eek: )

"ssh" also has the potential problem of being optional, because it operates as a user-level program on top of the stack. If you don't do it right, each and every time you do it, traffic might not actually pass through the "ssh tunnel" that you have created. You might well be sending data "in the clear" and you don't know it. You could be talking to a "man in the middle" and once again you wouldn't know. At the end of the day, "ssh" is precisely what it was designed to be: "a shell," which can also be pressed into service to provide a limited form of tunneling between two specific logged-on user sessions.

OpenVPN, properly used, literally does deliver on the promise of a "virtual private network." A single user can connect to another system, and/or two distant subnets can be linked to one another, and the result is as if the two systems were connected by a bulletproof – yet, undetectable – piece of wire. It serves all system users and processes. This becomes the outer bastion of defense, with "sshd" perhaps being the second layer of defense but not the first. (Or, as when connecting two subnets, no further defenses are deemed necessary.) The result, as promised, is that there are now no unauthorized connection attempts, because the secret door, which uses no TCP/IP ports at all, cannot even be found by the uninitiated.

The 'ace-in-the-hole' for SSH for me is the ability to create a reverse secure shell tunnel.
I often tunnel between a work server and my home computer. The home IP address is subject to change, which requires updating a URL by dynamic DNS. The work server runs a cron job that regularly calls out to the home URL and establishes a reverse SSH connection if available (using key authentication and host key checking). I can then tunnel back to the work server (again using key authentication and host key checking).
The work server is seen as having a static IP address, so it is easy to firewall off unwanted SSH probes on my home router. The work server has no SSH port open for incoming connections, so also a 'dwarvish' door.

I appreciate that SSH by default has minimum security, as it allows for easy setup of new machines. The hardening process after initial key exchange is simple and well documented.

For simple setups, SSH is easier. VPN comes into it's own in corporate environments with many users. Managing SSH keys for more than a few users rapidly becomes painful. Configuring a VPN client can be a very time consuming process.

You keep on repeating this thing, with funny colors and emojis, as if it were a real problem. It just isn't a problem.

Do you have ANYTHING to back that up? How many folks are using a custom ssh port and also allowing password authentication? How does that compare to the number of folks using a custom ssh port and locking it down? My guess is that the latter is the common thing, not "the smart exception".

And do you have any idea at all about how many folks have OpenVPN on the standard ports, or not configured to your particular opinion on exactly how it's supposed to be done? Do you think you are "the smart exception", or do you think everyone else has OpenVPN configured exactly the way you insist is the only correct way to do it?

See, there you go again. Claiming a problem which is not a problem, using a silly emoji and you think this helps make your point. In reality, it just makes your point look silly.

You know what? I just really don't see how this ever actually happens. If you actually care the slightest bit about security, you have a firewall filter on your router. It's only going to have your one custom ssh port open. So how the heck are you supposed to accidentally connect up through that router via an insecure "in the clear" protocol? It'll just bounce off iptables rather than actually working.

And when you use an ssh tunnel, you've got to hit localhost, not some other IP address out there. How are you supposed to accidentally not know you're hitting a completely wrong IP address that's not localhost? How the heck are you supposed to mistake some random IP address or host name for localhost?

No, that's what the keys are for. Ssh is extremely vocal when they don't match what is expected.

Yeah, I don't want that on-the-road. I want a very limited connection that is only used for a couple things on a temporary basis. I don't trust my on-the-road laptops as much as I trust the machines that always stay at home.

The same is true for OpenVPN if the default route isn't set up or pushed to the client, or if some of your traffic has a more specific route that is used in preference to the VPN route.

On a slightly different topic, how can you set up a VPN server so that the VPN starts automatically when the server reboots without having the server's private key exposed in an unencrypted file on that server? I'd love to use VPN as my primary access to my LAN from afield, but that VPN has to come up on an unattended reboot.

With either SSH or VPN, you need to make sure that ALL traffic is going across the tunnel (assuming that's what you want - there are cases where you don't).

It is very easy to set up an SSH tunnel (often referred to as "Dynamic Port Forwarding" or "SOCKS Proxy") and find that the majority of you traffic goes down that tunnel, but your DNS queries do not. DNS queries can reveal a lot about who you are and what you're doing, so you can't always equate them to "unimportant collateral traffic".

With VPN, the server can push directives down to the clients instructing them to send all traffic down the tunnel. But the thing is, the clients don't have to obey this. They can ignore the directive.

With VPN, usually the server directive is good enough. But you still have to check.

With SSH, the choice to send everything down the tunnel is made on the client end. There is no server directive to prompt the client. So it's easier to screw this part up when using SSH than with VPN (but just barely - you have to remember that the server directive is only a suggestion, not a hard and fast rule).

It is a good idea when setting stuff like this up, to establish your secure connection (tunnel) and then check for DNS leaks by going to the site https://www.dnsleaktest.com/ and running their "Extended Test". If you see DNS responses coming back from places outside of what you normally see from your home ISP (assuming your VPN/SSH server is running at your home), then you know you have a DNS leak that needs to be plugged.

I solve the problem by ensuring that the /etc/openvpn directory is owned by root and has a rwx------ permissions-mask.

However, also note that the "certificate and key" information for the server, as stored in this directory, actually serves the self-same purpose as does the "certificate and key" information in each client's credentials: it acts to identify the machine. The certificate is handed to the remote party, and the corresponding secret-key is used to decrypt whatever that remote sends back. But this secret could be replaced at any time, so long as the certificate and the key were replaced together. The mere possession of a certificate/key pair is not "the profound secret."

The certificate/key pair, whether possessed by the server or by any peer, is in fact only a form of identification. A form of identification that is only accepted if it is found to be properly signed. Both client and server use the (public) ca.crt file, shared by all, to verify that a certificate has been signed by the expected authority, and this alone is what causes them to accept it.

The "profound secret" is the signing key which must be used to cause any certificate that is issued to be accepted as "authentic" by all parties. But, they cannot create a new credential given this information, because they do not possess ca.key. Although anyone can crank-out a new SSL key in a matter of a few seconds, they cannot cause it to be accepted.

This "signing" concept does not exist in ssh. If a public-key is present in a authorized-keys file, it is taken to be valid, simply because it is present. While, of course, this is infinitely stronger than "a password," there is still no third-party involved.

- - -
And, please note: "I am not engaged in 'ssh bashing' here!" :)

I do not find it acceptable for access between my computers to be subject to a third party's authority. If I were to use VPN, I'd use some method of authentication which does not involve signing by a third party CA.

That method would be called "self-signed certificates".

Third parties are not authorizing anything. They're just signing certificates saying that they have researched, and indeed who you say you are is really who you are. You probably don't need that within your own network.

However, Firefox, Chrome, and other browsers will still throw up a warning for self-signed certs, even if they are on your own internal network. You need to add yourself (the one who self-signed your certs) to the list of trusted CA's in the web browser. Or, just ignore the warnings and plow right ahead.

But in any case, it is not the third party that is authorizing anything. Only you can do that.

C'mon, don't get personal. We're just two technicians, talking about two different sets of cryptographic technology, and I'm pointing out the advantages of one of them in a fairly-particular use case. If there was no validity to what I am saying, then of course VPNs would never have been invented. (Or, per contra, ssh would no longer be used.) Since neither of these things has happened – or ever will – "let's move on, shall we?" There must be common t-e-c-h-n-i-c-a-l ground. :)

Of course there are many varieties to "ssh tunneling," some of which basically steal-the-playbook from VPNs by also linking themselves into various levels of the TCP/IP protocol stack, but my comment about "accidentally connecting in-the-clear" particularly speaks of outbound connections. Since ordinary, run-of-the-mill "ssh tunnels" do not intrude at all into the stack, there are many assumptions that are being made, all of which must be carefully followed by the user who is setting up the tunnel, without which the traffic might pass "in the clear." VPNs, on the other hand, do integrate into the protocol stack by default, such that they are literally-equivalent to a hardware device on behalf of all system users.

Apparently, some people have interpreted my thread as being "ssh bashing." This is not and never was the case. But, given that there is a sticky thread here that is specifically talking about "failed SSH login attempts," I think that my comments have genuine and pragmatic merit. (And, if I may say, "ought not be perceived as cause for conflict!")

OpenVPN has several fundamental architectural differences which are very significant:

1. The use of the UDP protocol, combined with the ability to conceal itself so that "unauthorized connection attempts" literally do not occur.
2. The connection is made to a system, not to a user.
3. The connection is integrated into the network protocol stack at one of two levels, and therefore covers all possible connections between the systems, regardless of what the users or the processes on either of those systems do or do-not do.
4. Both parties identify themselves to each other, relying on a third party ("the CA") to establish authenticity. Mere possession of anything – a password, or a public-key – is not enough. The parties can verify the credentials, but cannot create credentials which would pass this same verification.
5. Credentials can be selectively revoked. (If "you" quit or get fired, "your" badge drops dead. Mine doesn't.)

However, I never intended to suggest that I was slamming anyone for choosing to use "ssh!" Nor that I was bashing the "ssh" technology! :eek:

Well I for one, welcome my new VPN master. Agree, Isaac cool it.

First though comes research on which is truly the most secure method, OpenSwan, OpenVPN, or IPSec.

I'm aprehensive of the complexity, although I am now conquering email! The Mount Everest of applications!

Nothing I've found can equal sshfs for remote mounts though. Used it for years. And reverse SSH tunnels are wonderful.

What exactly do you get with VPN? Access only to remote daemons that are listening?

You're the one claiming we shouldn't be using SSH, and one of your reasons you keep repeating is just...wrong. I don't see any reason I should concede about that point. When following simple straightforward guides on how to use ssh securely, sshd simply will not be presenting any sort of login prompt. It's that simple.

VPNs could easily have been invented for completely different reasons. For one thing, the basic thing that VPNs tend to be used for is very different from what ssh tends to be used for. Most installs of sshd are used for a remote console interface and/or file transfers. I'm unaware of VPN even being able to do either of those things. It's apples and oranges.

I seriously don't think VPN was invented just because ssh may produce a login prompt. That makes no sense. It would be much easier and simpler to fork a ssssh (super secure ssh) which has no ability to do password authentication.

Come on, the second reply already says how to completely shut out ssh login attempts.

The bottom line is that if someone is using ssh and is naively using password authentication where it's not appropriate, the solution is NOT to use VPN instead. The solution is to lock down sshd to use a passphrase protected key instead.

1. Would you say that anyone using TCP protocol instead is doing it wrong?
   
   
   Quote:

   combined with the ability to conceal itself so that "unauthorized connection attempts" literally do not occur.

   I haven't addressed this before, but honestly I'm skeptical of attempted security through obscurity. It reminds me of the port knocking craze, which really never made sense compared to just using key based authentication. I use a custom port on ssh mainly because it's considered best practices rather than thinking it seriously improves security.
   
   The basic problem is that there aren't very many ports - just 65536, or the equivalent of a measly two bytes worth of password length. If someone is trying to brute force a connection, it only adds TWO BYTES worth of difficulty to the security key...which is already 256 bytes long.
   
   If someone magically has the ability to brute force a 256 byte long key, a 258 byte long key isn't going to save you. They'll just slam all your ports rather than just one port and they'll get it soon enough. (But no, actually that won't happen - because a 256 byte long key is already too much to brute force.)
   
   
   Quote:

   The connection is made to a system, not to a user.

   Okay sure, that's sure different. Depending on the use case, this could be highly undesirable. Certainly, for my remote access use case I definitely want to lock it down to just one specific regular user. For my local LAN use case, I want something a bit different.
   
   
   Quote:

   The connection is integrated into the network protocol stack at one of two levels, and therefore covers all possible connections between the systems, regardless of what the users or the processes on either of those systems do or do-not do. Both parties identify themselves to each other, relying on a third party ("the CA") to establish authenticity. Mere possession of anything – a password, or a public-key – is not enough. The parties can verify the credentials, but cannot create credentials which would pass this same verification. Credentials can be selectively revoked. (If "you" quit or get fired, "your" badge drops dead. Mine doesn't.)

Your subject line literally says we should be using VPN, not SSH.

Possession of that signed key pair would allow someone to impersonate my VPN server. Fortuntely, I find it does not allow someone to impersonate a client if the cert has been properly restricted (error=unsupported certificate purpose).

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!" :eek:

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. :eek:

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.