Anyone who has launched sshd on an Internet-facing server has had the same experience: within a matter of hours or even minutes, the server is receiving hundreds of failed-login attempts per minute. This continues night and day.

In my opinion, the fundamental problems with ssh are twofold:

1. Most damningly, it is "a shell." The fact that it encrypts its network traffic is immaterial: it presents the dreaded prompt:
   Quote:

   login:

2. It reveals its presence to anyone who does a port-scan.

But there is an alternative: OpenVPN with digital certificates and tls-auth security.

As I describe in my blog post How to Build a Dwarvish Door With OpenVPN, it is possible to create an outer portal into your system that not only cannot be penetrated, it cannot be detected!

When the tls-auth feature is used, the OpenVPN server requires that supplicants show possession of a particular digital certificate, on their first exchange with the server. If they do not, OpenVPN silently drops the packet: it does not respond at all. Thus, to a port scan and to a "script kiddie," it simply isn't there.

Someone who does possess the first-level certificate does receive a response, and the only response that should be accepted is: a unique, one-of-a-kind, individually issued (usually, "self-signed") certificate: up to 4,096 bits of pure-random information. (N-E-V-E-R(!!) settle for "Pre-Shared-Keys (PSKs) == Passwords!") Falsification or "brute forcing" of such a thing is impossible, and each recognized certificate is unique. Thus, they can be revoked individually. (For "road warriors," the certificates can also be encrypted such that a password is required to unlock it.)

It is reasonable that authorized users should be subject to further challenges -- user names and passwords, ssh certificates, and so on -- once they have successfully passed through the OpenVPN portal. But, by placing this "undetectable bastion" as your outer-ring defense, you leave 100% of the script-kiddies out in the cold. Your servers (sshd and otherwise ...) should "listen" only to the virtual-tunnel provided by OpenVPN, so that in order to reach any of them you must first have passed through the tunnel.

(Also: you should constantly "port scan" your own systems to be certain that "no ports appear to be open.")

Is it "hard to do?" Frankly, no. OpenVPN uses the same "TLS" cryptographic protocol that is used by https: web sites. It includes the "EasyRSA" toolkit that, as the name implies, makes the necessary operations very "easy."

Try it, and "enjoy the blissful silence." Your server logs simply don't have any(!) "failed login attempts" to report ... period. The script-kiddies never make it that far. And, they never will.

... and yet, your authorized users, each of whom you know by the unique certificates that each one bears, can pass through the gantlet with ease. Once the "tunnel" is connected, they can access network resources as though they were "local." You don't have to worry about their traffic passing through the Internet without encryption if they "do the wrong thing" or "fail to do the right thing." The seemingly-effortless simplicity with which they gain access stands in direct contrast to the impossibility that faces everyone(!) else in the world.

This, in my opinion, is "encryption as it should be."

• Authorized users are not inconvenienced.
• Access is tied to the possession of "a unique thing," not "a (not-so) secret," and each-and-every thing is tied to a single authorized possessor of that particular thing.
• The scenario can be centrally managed.
• Access can be revoked at will, without impacting any other authorized user.
• Unauthorized users face an impenetrable (and, invisible) barricade that they cannot penetrate. ("The door is shut.")

Not that I want to take anything away from your very insightful post, but I don't fully agree with the above.
My personal (Debian) server runs ssh on a non-standard port with a limit set on said port (using ufw). I have had 0 (zero!) brute force attempts since this server went live.

In fact, I found it so strange that I did a little "penetration testing" on my own. To my surprise I found that even though port 123* is open for ssh it does NOT show as an open port using nmap. I did find port 123, but that required some serious effort.

I am not claiming this to be a perfect solution, it is not, but when compared to another server I managed several years ago that ran ssh on the standard (22) port and only in combination with fail2ban, the difference is remarkable.

What I do get however are tons of attemtps to crack via port 80 (I use apache2 for some websites), but I can live with that, and deal with most of them via mod_rewrite.

Finally, thank you for posting, I learn a lot from reading stuff like this.

Best regards,
HMW

*This is not the actual port!

The IP-addresses most commonly probed are those known to be associated with public hosting services or cloud servers.

I helped to deploy a server at one of those sites and we had not even logged-off for the first time before the SSH login-attempts had started, and we logged about 400 attempts per minute. They did not stop ... until we shut the cryptographic door in their face, and the rate dropped neatly to: Zero. Nada. None.

Of course you will continue to get probes of the HTTP(S) ports, but all you need to do there is, well, "don't do stupid things." Don't run Plesk. Don't install PHPMyAdmin. If you do run a CMS, keep it up to date. Use restricted-access SQL passwords. And, so on.

It's a given that any service connected to the 'net introduces an attack surface and VPN is no exception.
Plus there's situations where VPN just isn't doable or practical.
Doesn't mean people shouldn't be aware of the option but it's not (yet?) "the new gold standard" IMHO.