Best practices for securing SSH access? Is certificate-based VPN server a good solution?

Question

I run a server on a hosting. I want to harden it, but ssh access is giving me a bit of concerns.

I usually access from home most of the times. I have a provider subscription with the usual DHCP setup which assigns some IP address to my home. Usually it's the same. But I know it has changed some time.

The server has ufw running. Right now, I have a rule closing down ssh access to a /16 address range because I don't want to risk myself being locked out if the provider changes IP and I have a host-only access to the server.

SSH access is by ssh keys btw, not password, root access is disabled and only a user can acccess.

So I thought I might be installing an OpenVPN server on the remote server and configure it to allow access via certificates only. I like this because it would allow me to be flexible and access from anywhere provided I have the certificate.

However, this got me thinking.

• This means that the VPN server port needs to be accessible from anywhere, while if the access is firewall based, I could lock down
• The certs become the weak point, obviously if those get compromised they get full access (can the client certificates be password protected? I thought that doesn't apply)
• On the other hand, for example if I request a static IP from my provider (of course, additional costs...), I could lock it down to my home only, but then I wouldn't be able to access from some other location.

I am even considering a small low-resource VPS somewhere to be the jumphost, but then I have to secure that one. At least the "target" server is locked down to just one or two addresses.

What are best practices to secure the ssh access in my case?

Answer 1

OpenSSH is rather secure out of the box. The risk of suffering exploits, especially if you regularly update it, is quite low. I consider it more secure than even the best VPN servers. You can harden it using guides like stribika's Secure Secure Shell article, but that was last updated in 2017 and a lot of its suggestions (like preferring ED25519) are now defaults in OpenSSH.

The most important configuration changes to make in sshd_config are to disallow root, disallow password logins, and randomly drop failed authentications:

PermitRootLogin no
PasswordAuthentication no

# MaxStartups is START:RATE:FULL (default = 10:30:100), where
# it randomly drops at RATE% after START failed logins within LoginGraceTime
# and increases that drop rate to 100% by FULL
MaxStartups 5:30:60

(Requiring a security key is roughly the same as requiring a certificate. I believe OpenSSH also supports certificates, but I suggest ED25519 keys instead.

For a higher level of security, you can also set up 2FA. There are many guides online describing how to do this, such as Ubuntu's Configure SSH to use two-factor authentication tutorial.

There are additional security provisions you can make, such as using an alternate port (I suggest something between ports 1-1024 since those should be restricted to root) and an automatic firewall for authentication failures (e.g. Fail2ban, which is a more complete variation of MaxStartups). There's also the concept of port knocking, which (like hosting on an alternate port) is more of a security-through-obscurity measure unless you use some sort of secure port-knocker. I discuss alt ports, Fail2ban, and port knocking in this answer.

Answer 2

There is more than one way to approach this problem.

My own setup is that I have a small VPS with OpenVPN server installed on it and it does nothing else.

To SSH to my other machines I must be using VPN. On the other machines I have whitelisted the IP address of the OpenVPN server, plus a couple static addresses I can use as a last resort. Thus the SSH service is not exposed to the public Internet and the attack surface is virtually nil as it applies to most other services.

But the VPN is exposed though (on port 443 (SSL) so it could pass for an https site when running a cursory scan).

My webhost also provides a QEMU web interface to the server so I can always take over even if the firewall was to block everything.

If you have a residential connection with an IP address that can change infrequently but without notice, you could use DDNS. Your router might support the feature, have a look. What is DDNS? How does it work and how to setup DDNS?

In case your home router picks up a new address it would take just a few minutes for your server to detect the change. You may need a cron job to update firewall rules, I'm not familiar with UFW.

If you want to be able to access your server from other remote locations, then VPN would be a good solution.

If all you need is to be able to SSH from home, then DDNS could suffice.

PS: your ISP probably has more IP address ranges than the /16 you have whitelisted. You could check against their AS number on bgp.he.net for example.

Answer 3

Consider two servers - One running OpenSSH, and one running OpenVPN.

• Both are secured using the same type and same length keys (e.g. 4096 bit RSA).

• Both are running the services on ports that are publicly accessible.

• Each is running the latest version of OpenSSH and OpenVPN respectively, which have no known vulnerabilities.

• Both servers employ hardened configurations. In the case of the OpenSSH server, OpenSSH has been hardened to only allow key-based authentication (not password-based authentication), to not allow root logins, etc.

Barring a zero-day vulnerability in OpenSSH or OpenVPN or side-channel attacks - it is hard to see how either one could be any more or less secure than the other, in as much as allowing an attacker unauthorized access to the server.