Still the question: if I need to have SSH access to the hosts which are part of the VPN how do I prevent the above mentioned break-in-attempts. IPtables to allow only traffic from the VPN subnet?

jlinkels

Forgive me, but I still do not see a real point here. VPN (as a networking access technique/concept) and SSH (as a terminal session client) are both excellent concepts that apply to different problems. They are versatile, and SSH CAN be applied to some of the same issues as a VPN, but that does not make it the right answer. VPN is a network concept, while SSH is a client/server session concept.

Any problem that is entirely local that a VPN can solve, can be better solved by smart networking (routing, firewalls, etc.) and should not require VPN software. VPN is an elegant solution to remote network access, and not really appropriate to other uses.

OpenVPN, as a specific VPN application, is very powerful and somewhat complex and designed for network and system administrators.
OpenSSH, as a specific SSH application (server and client), is easier because the server side is intended for system administrators and network administration skills are not as critical. The OpenSSH client applications are intended for normal users, and have useful defaults that are simple enough for any normal user. (And more advanced options for those who are more skilled.)

OpenSSH has, in recent versions, some significant VPN features tacked on. These make host-to-host VPN sessions very easy to do in that tool. Host to remote network (routing through a remote host) solutions are possible, but hardly as secure or stable as when using a proper VPN.

Several messages here make it very clear that there is a learning curve involved in advanced use of either one. It is worth climbing that curve IF you have a good case for that learning, and it is worth the effort if you really want to know.

Arguing that one is better than the other is like arguing the advantages of motorcycles over boats. It depends upon the environment (How wet is YOUR highway?) and where/how you need to use them.

I recommend you search for fail2ban on duckduckgo or google. It provides automated blocking (we assume iptables is available) that is adequate to block those dictionary or brute force attacks by detecting and acting on the activity.

This does not mean I approve the use of SSH for secure network communications where a VPN would be more appropriate, but if that is your limit then making it more secure is only reasonable.

Indeed, i-f you are using only digital certificates for SSH, "brute forcing" of those certificates is impossible. But, SSH has the very annoying characteristic that it will continue to "ratchet down" to lesser and lesser authentication alternatives, accepting the least secure ("passwords") alternative that it has been told to allow.

Furthermore, if an intruder can "slip" a new certificate into the authorized-keys file, he can grant access to himself with a fairly-low probability of actually being detected. All he needs to do is to penetrate the system once, and hope that you're not paying attention.

And, in any case, it's all happening on top of the network stack, and processes which wish to use it e.g. for "tunneling" must do so explicitly. Whereas, VPN operates as a router or a switch, and it normally communicates using UDP. Therefore, I-f you are using one-of-a-kind certificates, not "PSKs" == "passwords"(!), for authentication, you are rewarded with an unobtrusive secure link to a remote system, which both parties can identify with certainty, and which is simply "the route" to that subnet. Any and all traffic bound to/from those IPs will pass through the tunnel, automagically.

It literally is a "Virtual Private Network."

If the connection is secured with both digital certificates and tls-auth, not only penetration but even detection of the link becomes ... impossible. And yet, authorized users can open a new connection in less than ten seconds and thereafter "simply communicate," as though the resources were directly attached using boxes and wires instead of passing through an insecure public network.

As already noted, it is very easy to set up /etc/ssh/sshd_config to lock everyone out except for one user which is only allowed to log in via key (encrypted with pass phrase).

In contrast, it seems that setting up a VPN with the exact right security is NOT so easy. And you're not making it any easier.

Eh, you mean the intruder "just" needs root access once. With root access, there are a zillion different ways to insert a back door without messing with any configuration file. For example, unless you block outgoing web requests (the typical method by which a linux distribution will download security updates), it'll be possible for a compromised executable to reach out with a reverse ssh.

Which, honestly, I am more comfortable with when it comes to on-the-road access. You're assuming the client computer is never compromised, but what are the chances? Physical security on a laptop is typically going to be less robust. If I accidentally leave my laptop unlocked for a minute while distracted or something? It takes only a few seconds to plug in a USB device and run a script kiddie script. It's not root level access, but regular user level access is plenty to start banging around a VPN connected network for any internal vulnerabilities.

I like the fact that when I'm on the road, the only connection back home is a narrow straw - just ssh for text console login and sshfs for file transfers, with only the access level of a single specified regular user to a single machine. The way ssh works, it's not so easy to piggyback on an ssh connection to try and root around for vulnerabilities in the connected computer (much less the LAN connected to it). A script kiddie script could still potentially do a lot of damage, but it's not so easy to cover its tracks when it only has regular user level access.

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".

2 members found this post helpful.

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:

login: