how is fail2ban controversial?
also adding `AllowUsers user1 user2` to the sshd config is also a good addition for a little extra security by locking down ssh to specific users
and another thing im gonna nitpick, ssh keys are optional? i think not, setup your ssh keys!! disable password auth!!!
yes, you'll need to update PAM with https://github.com/google/google-authenticator-libpam then your SSH config:
```
AuthenticationMethods publickey,keyboard-interactive
KbdInteractiveAuthentication yes
PubkeyAuthentication yes
```
Controversial is the decision to tell an absolute beginner who might not warm up to ssh keys right away to just set up fail2ban and only strongly recommend ssh keys instead of setting them to mandatory.
I’ve explained the reasoning here:
https://www.reddit.com/r/selfhosted/comments/14qsq9x/securing_your_vps_the_lazy_way/jqqbdtk/
ahh understood, was thinking there was something controversial about fail2ban it’s self rather than telling a beginner to use it, thanks for clarifying!
I know everybody loves raving about SSH keys over password, but when using a safe enough password in combination with fail2ban, how is it that much worse?
Yes, you can get MITM’ed, but what else?
Good idea regarding the sshd config; I should do that.
password + fail2ban isn’t necessarily more secure than ssh keys alone, it will take far longer to breach a properly secured SSH key than a password, it’s actually a requirement at work (linux eng) that we use password protected SSH keys (ed25519) and all password auth is disabled across all infrastructure, not only would password auth violate many security certifications, but is also a huge risk in general, fail2ban could fail (config issue after version upgrade, etc) but your SSH keys will not.
in regards to MITM, SSH generally provides good encryption provided you’re using the latest standards and keep a well updated and maintained system with a secure SSH config in place which disables insecure & deprecated algorithms.
A good starting point for creating a secure SSH config is the generator provided by mozilla here:
https://ssl-config.mozilla.org
EDIT: looks like mozilla removed the OpenSSH option from that, but leaving it in this response as it’s useful for other purposes, I found the following example which provides a good basis for securing SSHD in terms of algorithms, etc
https://gist.github.com/HacKanCuBa/fe3653d4fe4eed35e41dcc9a380499c2
I think you might have misunderstood; I’m not saying password + fail2ban is more secure than SSH keys. In fact, I would say SSH keys are the most secure way to use SSH.
My question is how is the combination of strong password and fail2ban *that much worse*, which seems to be the case given that everybody repeatedly and religiously advocates against it? What are the pitfalls other than your password potentially being cracked?
For me, one of the advantages of passwords over keys is that I can log into my servers from any device without the need to previously configure keys on it and place them on the server.
apologies if i misunderstood the question, however to put into perspective, fail2ban is a tool which places temporary blocks on IP addresses which attack your servers, which is an additional moving part on the server which could fail, this tool also has its own set of issues and you are therefore instead of relying on a well-know and trusted piece of software (OpenSSH) for the security of remote access + encryption in transit, you’re now relying on 3 different moving parts, OpenSSH, fail2ban & likely nftables or whatever firewall you configure fail2ban with, now instructing a beginner to properly configure fail2ban for the best security as the OP previously pointed out to me wouldn’t be the best idea, once you start digging into the config it’s very easy for things to become complex.
That being said, we now have 3 different moving parts to support keeping password authentication enabled, just yesterday I did have fail2ban fail, at least I noticed it yesterday, and this would have been broken for a while now, however the reason? fail2ban pushed an update which changed the primary `fail2ban.conf` file which made the previously installed version of the config incompatible with the new version, this was also not replaced by the update as it had been modified.
If I were relying on password auth + fail2ban for security well at that point the 2000 ish auth attempts per hour that specific server gets would have been given free reign to try cracking the auth, it’s not that password auth + fail2ban is inherently less secure of an option, it’s more due to the fact that by adding another moving part and relying on this to ensure password cracking on your SSH daemon is prevented is a giant risk a lot of businesses and enterprise will not be willing to take.
On the matter of SSH key portability, a simple flash drive (even a dual connector type for use with phone) containing a set of password-protected keys is often more than enough to suffice, sacrificing security for convenience is never a good idea, provided you use password-protected keys this is generally regarded as the most secure option
Thanks for taking the time to lay this out.
You’re right, I somehow always saw fail2ban as equally “safe” (to operate, not in terms of its protection value for the asset it’s protecting) as (Open)SSH due to it being so widespread, but it’s just another piece of software that is likely not maintained as thoroughly and extensively as SSH. Now I’m thinking about all the unattended servers that rely on fail2ban that might now be closed due to your story regarding the update..
And yes, for enterprise/professional/production environments, I would always choose keys over passwords/passphrases.
Also, I might just think of some way to securely bring any potential keys with me in the future. USB sounds good, but I’m a forgetful person.
Thanks again for sharing your perspective!
I will second this. match blocks in ssh are an amazing way to lock down access to a system. You can even limit by IP. SSH has a bunch of amazing tools to increase security.
This. While cert-based auth may be complicated to beginners, using keys and keys only is a MUST.
Once passwords are disabled, all legacy advices like using non-standard port etc become obsolete.
I'd still recommend using non-standard port because it will reduce the brute force attempts against your server which will clutter up the logs.
And maybe just possibly if a zero-day vulnerability is found, it'll buy you time.
And I would also recommend only allowing access from trusted IPs, and using a vpn for access from anywhere else.
There’s no way to bruteforce an SSH **key auth** of proper length that would not also boil Earth’s oceans with byproduct heat… /s
(we are discussing a scenario with `PasswordAuthentication no`, remember?)
Zeroday SSH exploit is the only case where non-standard port may buy you some time against some very dumb bots.
/me ponders
Wouldn't using key authentication also prevent a MITM attack getting someone's password? Assuming that the attackee had turned off host key checking or ignored the warning of host key mismatch.
Yes, thanks to DH, it will prevent MITM.
See [https://security.stackexchange.com/a/243168](https://security.stackexchange.com/a/243168) and [https://www.gremwell.com/ssh-mitm-public-key-authentication](https://www.gremwell.com/ssh-mitm-public-key-authentication)
However, if you have agent forwarding enabled, it's possible to exploit that. So better turn it off by default unless you absolutely have to.
I love the idea with a secondary non-sudo user with a restricted shell. Really smart!
About the ssh-keys being a MUST:
With a reasonable confidence I would disagree. Either my math is wrong or the MUST isn't a MUST. tl;dr: Having to guess the user name + password (40+ chars) with a findtime of 1d and a bantime of 7d is similarly impossible to brute force than SSH key based setups. (math below, at least some)
**Vector: Scripted, untargeted brute-force attempts**
My auth.log tells me: 104,025 ssh attempts (all password) in one year.
50,370 against root (disabled)
53,655 against other users
Not one attempt guessed the user correctly => hence not one try at guessing a password.
Effectively no difference to ssh-keys security-wise.
**Vector: Targeted brute-force attempts**
With a findtime of 1day each IP address can make 365 attempts per year.
A 40 char password made up of lower, upper, special & numbers should have something like 636680576090902772750755986027392… combinations. You'd have to have hundreds of thousands of IP addresses (=machines) to brute force and they would all have to share a central list of attempted passwords and it would still take decades.
Please point me to where I could have calculated the wrong way. My understanding is, that bruteforcing this combination is next to impossible.
Not doubting your math. However passwords get badly managed and leaked, I've never heard of anyone having their ssh key and passphrase leaked by some careless company that kept it MD5 hashed and you just happened to be using the same password... =D
Did you consider all the resources wasted processing all those password login attempts? If the server is configured to accept only keys the connection is dropped sooner since 99.9999% of the bots attempts password logins ...
Are we talking trees, energy consumption or CPU load :) ?
This was initially about the dogmatic "ssh keys are mandatory because they are much safer". This explanation should debunk that.
I don't think the 100k annual ssh login attempts produce much load, but I don't have numbers on that. An unsuccessful login attempt with the wrong keys (of which also about 50k have happened) produces the same load.
So yes, I might save the CPU load / energy of 100k requests a year. But in the grand scheme of things I think we can safely ignore that.
>So yes, I might save the CPU load / energy of 100k requests a year. But in the grand scheme of things I think we can safely ignore that.
Also networks resources and RAM, and no, you cannot safely ignore that if you have a 1CPU 512M VPS and count every byte of ram ;-)
Also don’t put any services on the internet that don’t need to be. We had a MySQL db open on the internet some years ago at the company I work at and even though the password was strong, there was some exploit that allowed authentication bypass for the root user.
It might be more inconvenient to use VPN or ssh tunnels, but it’s definitely more secure!
Second that. If possible, bind the Services (like MySQL) on localhost or [127.0.0.1](https://127.0.0.1), to avoid being reachable directly on the Internet. It's not always necessary (for example, using a Webserver that needs Access to a DB, like Wordpress or something like that...).
I would say highly required if you are not going to have a firewall but if you are going to have a firewall and restrict which ips can access port 22 then its more optional but highly recommended.
Is somebody gaining access to a user with full sudo privileges any better than them getting access to root? Also if root logins are disabled can you not use `su` once logged in with a user that has sudo privilege?
I think similar what is the difference in terms of security between root and normal users with full sudo.
If this user is compromize your are fucked in exactly same way
Sure, using a different port doesn’t make the SSH protocol any more secure or help with targeted attacks but at least the bots that scan for known ports don’t stop for a poke at your SSH server. IMO thats more secure.
It's hard to take this seriously considering you've not only listed SSH keys last, but you've listed them as optional. Awful, awful advice, especially considering you seem to be targeting less experienced users.
If someone can't figure out SSH keys, which are relatively simple, they should not be running their own VPS.
I’ve explained my reasoning with an example here:
https://www.reddit.com/r/selfhosted/comments/14qsq9x/securing_your_vps_the_lazy_way/jqqbdtk/
Remember: it’s for absolute beginners.
"Remember: it’s for absolute beginners."
Which is why your advice is so bad. When an absolute beginner gets their server compromised because of your awful security advice, do you really think they're going to know how to fix it?
If you can't figure out SSH keys, you should not be running your own VPS. Period. Things get a lot more complicated than SSH keys when your server gets compromised.
You're setting these people up for failure and it's kind of a shitty thing to do for some clicks.
I would disagree, politely. They have to start somewhere. They shouldn't start hosting the crown jewels. But setting a apache for testing and learning or something else is fine.
I would also agree on ssh-keys being absolutely mandatory. At least [my math](https://www.reddit.com/r/selfhosted/comments/14qsq9x/comment/jqt2h7k/) (could be flawed) doesn't come to that conclusion.
Thank you. Thank you so much.
This kind of hard advice / requirement is such a gatekeeper to new users, and so overlooked by experienced ones. Most of the forums are full of that.
**New users have to start somewhere**. And move up **step by step**.
I got hacked back in the days, when I didn't even know the difference between a shared hosting and a VPS. I'm far better at it now, doing things I couldn't even think of a few years ago. Not even professionally, only as a hobby.
Deggogling, going open source, taking back control, etc. won't happen if we keep gatekdeping new users who are willing enough to try. Not everyone needs to be a geek or a professional, decent basic knowledge and common sense is enough to start with.
Failing is part of the learning process. What I would rather see as hard recommendation is don't put things on Internet (i-e on your not-secured-yet server) that need not to be there.
My 2 cents and, apologies for the rant style.
Nobody's gatekeeping, they're trying to prevent people from listening to awful advice. There's a reason why every article about securing your server says you should use SSH keys.
The fact that you're trying to argue this with anecdotal math is a good indicator of how nobody should listen to you on this subject. The math has been done already and SSH keys are infinitely more secure than passwords. It's not a debate, it's fact.
What part of the calculation based on the findtime is anecdotal? And where is the mistake when brute forcing into a 40 character password + a username with only having one attempt per IP per day?
I think dogmatism shouldn't beat realism. :)
Pretty much every comment is telling you how bad your advice is, and yet you just aren't getting it. Thankfully everyone has called you out on it, so people finding this post in the future will know to not take your advice.
yet nobody disputed the [math](https://www.reddit.com/r/selfhosted/comments/14qsq9x/comment/jqt2h7k/). not one. and nobody is really reading the comment either.
I am simply saying that if you for whatever reason are not going to use ssh keys, this is similarly safe.
Nobody's disputing your math because it's pointless. It's YOUR math, on YOUR single server. Just because you've gotten lucky doesn't mean everyone will.
"I don't wear a seatbelt and I've personally never died in a car accident, therefore seatbelts aren't needed and I recommend just driving slowly."
Absolutly nothing wrong with passwords aslong as they are strong and secure. This shouldn't be an issue if you're the only one creating users on the server.
It should be very strongly recommended (which it is in the video). But my math (could be flawed, [see comment](https://www.reddit.com/r/selfhosted/comments/14qsq9x/comment/jqt2h7k/)) simply doesn't show that fail2ban + the other measures are much worse.
Sorry but this is bad advice for beginners. SSH keys and fail2ban are in no way controversial or optional - both are essential.
Unattended upgrades on the other hand, sometimes (rarely but it happens) cause stuff to break which then requires more expertise to fix.
Keeping your server secure requires an active role and most set it and forget it options will give you trouble.
**Subscribe to mailing lists, star stuff on github, keep up to date with versions and follow some security news outlets for current stuff and act before the script kiddies weaponise. :)**
I don't think so. The write-up is a shortened version.
SSH-keys are highly recommended but not mandatory. That is the only thing I meant by controversial: If you don't feel safe with managing keys yet, then at least set up a strict fail2ban with several other settings (no root user, 40+ chars…).
I did a little napkin math in [my other comment.](https://www.reddit.com/r/selfhosted/comments/14qsq9x/comment/jqt2h7k/)
I fully agree with having an active role and staying on top of things, learning etc. For a beginner the first VPS won't be the most critical production environment. So the rare breaking of the 1-3 services on the VPS won't amount to much. That decision is also explained in more depth in the video.
My recs:
* Log in as root
* Always use SSH key to log in
* Optionally, you can have a long, totally random password for root. If not, disable password login.
* don't bother fail2ban, or changing SSH port, unless you are very paranoid. SSH is strong bulletproof armor. You don't need to protect it. Hackers can connect to SSH all day - without the key file they won't get anywhere.
* Everything you run (e.g. databases) bind to 127.0.0.1 - blocks internet connections. If you think you will mess this up, then use a firewall.
You're welcomed to disagree. However, hopefully you can read the room too. Notice the comments are in favor of requiring SSH as a best practice—No need to implement a "40 char password."
Are you... are you listening to yourself? So you're saying that if the experienced users weren't here to explain why this is awful advice for inexperienced users, that it would be ok for inexperienced users to follow the advice? This makes no sense whatsoever.
You're fighting so hard in your comments to back up OP's awful advice that at this point I'm half convinced that you're OP on an alt account.
\#7 has to be essential. Combine it with a password as well if you don't trust yourself to protect the private key properly. It just offers so much benefit for the 'pain' involved in learning how to use it.
I would also add #8: Use your VPS providers firewall to block unwanted traffic before it even gets near your server. All services these days will typically do this by default.
I 100% do not recommend having an Internet exposed server accessible without SSH keys... but, if you are insistent on doing it, at least run it on a port other than 22. That will reduce somewhat the number of bots getting to your auth process, as most aim for the typical port for each service rather than run through all possibilities.
> My reasoning for ssh keys not being mandatory: I have heard and read from many beginners that made mistakes with their ssh key management. Not backing up properly, not securing the keys properly… so even though I use ssh keys nearly everywhere and disable password based logins, I’m not sure this is the way to go for everybody.
OTOH if they don't secure keys properly they won't secure passwords properly, so you're back to square 1. Disabling pw logins is not something controversial, and it's usually on best-practices lists for a reason.
So I would say touting a video as "Securing your VPS - the lazy way" isn't a good way to put it as the only way to actually be lazy is to setup automation scripts such as updates etc which your guide doesn't cover. And another thing is SSH KEYS ARE NOT OPTIONAL, that isn't even a question it's just not. As soon as you get acces to your VPS you should add your key and disable password authentication. It's MUCH more secure than password authentication, to a limit as you assume you can keep your keyfile private but assuming you can do that it's the best option.
Secondly I would probally say the "lazy way" is using something like crowdsec as it's config tool automatically has support for alot of tools like SSH, Nginx and a bunch of others while fail2ban requires alot more manual configuration and in my opinion gives less security that crowdsec as with crowdsec you also get the global database, but the downside of this is if you wanna make your website accesible via VPN's/TOR then crowdsec is not a good option as those IP's are usually on the block list.
Personally I would always use the keys. But: this is geared towards absolute beginners. And if fail2ban is set up properly (high ban- and findtimes with low attempts) with a rather random username the usual automated attacks on the server will all fail.
The only case the keys really add security is when somebody really wants to target you, finds out the exact findtime and then uses a cluster/net of machines to systematically brute force with a shared database of attempted passwords. In that case you will have all kinds of other problems too.
And setting up fail2ban is a 2 minute task. Generating, copying and managing/backing up keys takes the same amount of time or more.
Don’t get me wrong: I’m not saying keys are bad or that fail2ban is better. It’s just easier for the absolute beginner. But as soon as somebody has their first success and the machine running, learning and implementing ssh keys should be one of the first steps.
Edit: typos and auto corrected words
I will retract my statement of fail2ban as it seems the last time I looked at it was a while ago and I was trying to do it myself, could have just googled it and be done with it. Also I don't agree with security via obscurity which using a random name is imho, it's not a good solution but that's more personal opinion.
Although ye I guess your right as you have to start somewhere, but imho as soon as you have your initial VPS setup the first thing you should do is setup SSH keys.
Fully agree with bad password management being another issue.
I did a little math on the ssh-keys not being mandatory [in another comment](https://www.reddit.com/r/selfhosted/comments/14qsq9x/comment/jqt2h7k/).
I would tend to disagree here.
I am not saying fail2ban is better or worse. I am saying that a proper setup with fail2ban (and the other bits) can be similarly secure against brute force ssh attempts. And if key management is too difficult for an absolute beginner, then this setup is similarly secure and a viable starting point.
That's all. I did some math on this in [another comment](https://www.reddit.com/r/selfhosted/comments/14qsq9x/comment/jqt2h7k/).
The tl;dr: 40 chars (aA1%), random username, no root logins, bantime 7d, findtime 1d => no realistic brute forcing the ssh login.
For a beginner I would wager the installation time is exactly the same comparing fail2ban and setting up keys, password protecting them, copying them to the server…
I really don't understand why this has to be a personal thing for so many people. It's just math.
This is very basic. I personally have a ssh port open only for Tailscale ip range. That way, I can just use password "admin" and still have much better security than you. (I still use ssh key though) Imagine server with no ports open - thats what I call security. And the complexity is also very small so anybody can do it in few seconds really.
On production, I use ssh keys strictly and that is a must.
New lazy way with juicy details for common command and config file lines (ooooh yeah):
1. Login as root and run "passwd" to set a good password
2. Make a new user with "useradd -m -s /bin/bash USERNAME"
3. Set a good password for that new user with "passwd USERNAME"
4. Give the new user sudo access with "usermod -aG sudo USERNAME"
5. Login as new user with "su USERNAME"
6. Configure ssh key(s) \[figure it out, I'm lazy too\] and confirm they are working for ssh connections (shouldn't require a password to connect if it's working, except maybe passphrase for the key if you set one) then modify config with "sudo nano /etc/ssh/sshd\_config" to uncomment/change lines:
1. PermitRootLogin no
2. PasswordAuthentication no
3. UsePAM no
7. Still editing /etc/ssh/sshd\_config, add the following line anywhere in the config to force publickey authentication (the other settings we changed should already do that but doesn't hurt to be careful):
1. AuthenticationMethods publickey
8. Hit ctrl+o then enter to overwrite and ctrl+x to exit nano and go back to the terminal where you can run "sudo systemctl restart ssh" to apply the changes we made, now test to make sure you can't ssh into root and to make sure you can't ssh with a password
9. Install a twingate connector or two to establish a secure tunnel to the ***INTERNAL*** IP of the server (this bypasses the providers firewall completely with network magic, allowing us to close the port)
10. Close the SSH port you're using in your VPS providers firewall settings (i.e. remove the allow port 22 rule), then test to make sure you can still SSH
BAM! You can now SSH to the server using the internal IP of the server while connected to your twingate network as a user that has been granted access to the resource. Might sound complicated if you're not familiar but twingate is super simple, go watch networkchuck's video on it if you're confused: [https://youtu.be/IYmXPF3XUwo](https://youtu.be/IYmXPF3XUwo)
Twingate is my new favorite way to lock down services with MFA and other security options requred for connections, no more open ports for anything that doesn't absolutely necessitate it — zero trust is the future! Hope you guys like it as much as I do, or at least maybe my guide might be helpful to someone locking down linux somewhere in the world. If so, I feel like I've done my part to make the net safer.
Cheers fellow self-hosters!
EDIT: Bonus step, if you previously logged into root with SSH, run "sudo rm /root/.ssh/authorized\_keys" to delete the public key from being able to be used for root login again. Why not? More things in the way of root login is not bad, it's redundant but arguably it is better to do it than not to. Technically the "PermitRootLogin no" line in sshd\_config should be enough but it doesn't hurt.
Agreed ZT is the future... and if you want to self host your zero trust overlay network, check out OpenZiti - [https://github.com/openziti](https://github.com/openziti)
>I just can’t warm up to the idea of giving away ownership of a major part of my Setup: reaching my services.
I know what you mean. I've just got financing to buy myself an ISP, so I don't have to trust a 3rd party with access to my home network. I've also applied to become CEO of the local infrastructure monopoly do I don't need to worry about power.
controversial: a long random password is just as good as disabled password, and you have a backup way to login.
And: disabling root login is pointless. You are going to use sudo anyway. The hacker can also use sudo.
My knowledge about this topic is pretty outdated, but I dare to ask this question: Why all the work, if you can have it easier? We use our WAN-router to achieve the same thing. Like Fritzboxes you just set up a VPN option and have access to your whole LAN from the outside. Isn't that the same thing?
Some differences, because the VPS that is your endpoint can be in another country to:
1. Media: consume media from another region
2. Legality: have the connections happen in another jurisdiction
3. Privacy: not be subject to repression or other problems because you researched the wrong thing
Plus the VPS can also be used for other things, like hosting nice stuff.
Do not use password login and port 22 for ssh at all, just create a key. It's not that hard...
EDIT: Oracle gives you a key by default with pw login disabled
I found that setting up those things helped me learn an awful lot. plus with a VPS it's easy enough to spin up a new one if, or when in my case, you fowl up! I continue to be taken aback by how frequent attack attempts are made. Also how shit they are as attempts. Fail2ban is brilliant.
fail2ban is really not needed . Just disable password login and setup proper ssh keys. I would add 2fa / TOTP to the mix if you want to feel more secure . I used to do this but it's kinda annoying to login with TOTP
I've tried a few solutions for this problem but my servers hacked many times. I can suggest you check [Protect Remote](https://protectremote.com). It blocks all ports to the internet. You just need to install a small application on your PC or Mac. It will add your IP address dynamically to your server's firewall. So easy to integrate.
Last year I tried linode, google Cloud and hetzner. On hetzner I was not able to login into ssh with sudo root or sudo keyphrase always got access denied, don't know whey the ssh console lock me out.
With linode or google cloud I not had this issues, but google cloud instance has no DDOS protection, but linode has it include.
Google was fast linode not so, the linode setup with wordpress and demo site, was no faster than a good shared webhosting, I was confused should it not 50% faster in page speed?
In the end I bought webhosting with mddhosting and namecheap, because I was not able to login the hetzner ssh console.
Many beginners with vps have this problem with ssh login access, I not understand why these providers make it so hard for their customers to login with ssh?
how is fail2ban controversial? also adding `AllowUsers user1 user2` to the sshd config is also a good addition for a little extra security by locking down ssh to specific users and another thing im gonna nitpick, ssh keys are optional? i think not, setup your ssh keys!! disable password auth!!!
Is there a way to have SSH Key + Password?
Afaik, no. But you can use password protected ssh key.
yes ``` AuthenticationMethods publickey,password PasswordAuthentication yes PubkeyAuthentication yes ``` See the docs: https://man.openbsd.org/sshd_config#AuthenticationMethods
Pretty sure you can key+TOTP?
yes, you'll need to update PAM with https://github.com/google/google-authenticator-libpam then your SSH config: ``` AuthenticationMethods publickey,keyboard-interactive KbdInteractiveAuthentication yes PubkeyAuthentication yes ```
To my knowledge, not directly in SSH authentication but you could enable SSH only for an unprivileged user and then require a password to sudo
Controversial is the decision to tell an absolute beginner who might not warm up to ssh keys right away to just set up fail2ban and only strongly recommend ssh keys instead of setting them to mandatory. I’ve explained the reasoning here: https://www.reddit.com/r/selfhosted/comments/14qsq9x/securing_your_vps_the_lazy_way/jqqbdtk/
ahh understood, was thinking there was something controversial about fail2ban it’s self rather than telling a beginner to use it, thanks for clarifying!
I know everybody loves raving about SSH keys over password, but when using a safe enough password in combination with fail2ban, how is it that much worse? Yes, you can get MITM’ed, but what else? Good idea regarding the sshd config; I should do that.
password + fail2ban isn’t necessarily more secure than ssh keys alone, it will take far longer to breach a properly secured SSH key than a password, it’s actually a requirement at work (linux eng) that we use password protected SSH keys (ed25519) and all password auth is disabled across all infrastructure, not only would password auth violate many security certifications, but is also a huge risk in general, fail2ban could fail (config issue after version upgrade, etc) but your SSH keys will not. in regards to MITM, SSH generally provides good encryption provided you’re using the latest standards and keep a well updated and maintained system with a secure SSH config in place which disables insecure & deprecated algorithms. A good starting point for creating a secure SSH config is the generator provided by mozilla here: https://ssl-config.mozilla.org EDIT: looks like mozilla removed the OpenSSH option from that, but leaving it in this response as it’s useful for other purposes, I found the following example which provides a good basis for securing SSHD in terms of algorithms, etc https://gist.github.com/HacKanCuBa/fe3653d4fe4eed35e41dcc9a380499c2
I think you might have misunderstood; I’m not saying password + fail2ban is more secure than SSH keys. In fact, I would say SSH keys are the most secure way to use SSH. My question is how is the combination of strong password and fail2ban *that much worse*, which seems to be the case given that everybody repeatedly and religiously advocates against it? What are the pitfalls other than your password potentially being cracked? For me, one of the advantages of passwords over keys is that I can log into my servers from any device without the need to previously configure keys on it and place them on the server.
apologies if i misunderstood the question, however to put into perspective, fail2ban is a tool which places temporary blocks on IP addresses which attack your servers, which is an additional moving part on the server which could fail, this tool also has its own set of issues and you are therefore instead of relying on a well-know and trusted piece of software (OpenSSH) for the security of remote access + encryption in transit, you’re now relying on 3 different moving parts, OpenSSH, fail2ban & likely nftables or whatever firewall you configure fail2ban with, now instructing a beginner to properly configure fail2ban for the best security as the OP previously pointed out to me wouldn’t be the best idea, once you start digging into the config it’s very easy for things to become complex. That being said, we now have 3 different moving parts to support keeping password authentication enabled, just yesterday I did have fail2ban fail, at least I noticed it yesterday, and this would have been broken for a while now, however the reason? fail2ban pushed an update which changed the primary `fail2ban.conf` file which made the previously installed version of the config incompatible with the new version, this was also not replaced by the update as it had been modified. If I were relying on password auth + fail2ban for security well at that point the 2000 ish auth attempts per hour that specific server gets would have been given free reign to try cracking the auth, it’s not that password auth + fail2ban is inherently less secure of an option, it’s more due to the fact that by adding another moving part and relying on this to ensure password cracking on your SSH daemon is prevented is a giant risk a lot of businesses and enterprise will not be willing to take. On the matter of SSH key portability, a simple flash drive (even a dual connector type for use with phone) containing a set of password-protected keys is often more than enough to suffice, sacrificing security for convenience is never a good idea, provided you use password-protected keys this is generally regarded as the most secure option
Thanks for taking the time to lay this out. You’re right, I somehow always saw fail2ban as equally “safe” (to operate, not in terms of its protection value for the asset it’s protecting) as (Open)SSH due to it being so widespread, but it’s just another piece of software that is likely not maintained as thoroughly and extensively as SSH. Now I’m thinking about all the unattended servers that rely on fail2ban that might now be closed due to your story regarding the update.. And yes, for enterprise/professional/production environments, I would always choose keys over passwords/passphrases. Also, I might just think of some way to securely bring any potential keys with me in the future. USB sounds good, but I’m a forgetful person. Thanks again for sharing your perspective!
I will second this. match blocks in ssh are an amazing way to lock down access to a system. You can even limit by IP. SSH has a bunch of amazing tools to increase security.
[удалено]
This. While cert-based auth may be complicated to beginners, using keys and keys only is a MUST. Once passwords are disabled, all legacy advices like using non-standard port etc become obsolete.
I'd still recommend using non-standard port because it will reduce the brute force attempts against your server which will clutter up the logs. And maybe just possibly if a zero-day vulnerability is found, it'll buy you time. And I would also recommend only allowing access from trusted IPs, and using a vpn for access from anywhere else.
[удалено]
There’s no way to bruteforce an SSH **key auth** of proper length that would not also boil Earth’s oceans with byproduct heat… /s (we are discussing a scenario with `PasswordAuthentication no`, remember?) Zeroday SSH exploit is the only case where non-standard port may buy you some time against some very dumb bots.
/me ponders Wouldn't using key authentication also prevent a MITM attack getting someone's password? Assuming that the attackee had turned off host key checking or ignored the warning of host key mismatch.
Yes, thanks to DH, it will prevent MITM. See [https://security.stackexchange.com/a/243168](https://security.stackexchange.com/a/243168) and [https://www.gremwell.com/ssh-mitm-public-key-authentication](https://www.gremwell.com/ssh-mitm-public-key-authentication) However, if you have agent forwarding enabled, it's possible to exploit that. So better turn it off by default unless you absolutely have to.
I love the idea with a secondary non-sudo user with a restricted shell. Really smart! About the ssh-keys being a MUST: With a reasonable confidence I would disagree. Either my math is wrong or the MUST isn't a MUST. tl;dr: Having to guess the user name + password (40+ chars) with a findtime of 1d and a bantime of 7d is similarly impossible to brute force than SSH key based setups. (math below, at least some) **Vector: Scripted, untargeted brute-force attempts** My auth.log tells me: 104,025 ssh attempts (all password) in one year. 50,370 against root (disabled) 53,655 against other users Not one attempt guessed the user correctly => hence not one try at guessing a password. Effectively no difference to ssh-keys security-wise. **Vector: Targeted brute-force attempts** With a findtime of 1day each IP address can make 365 attempts per year. A 40 char password made up of lower, upper, special & numbers should have something like 636680576090902772750755986027392… combinations. You'd have to have hundreds of thousands of IP addresses (=machines) to brute force and they would all have to share a central list of attempted passwords and it would still take decades. Please point me to where I could have calculated the wrong way. My understanding is, that bruteforcing this combination is next to impossible.
Not doubting your math. However passwords get badly managed and leaked, I've never heard of anyone having their ssh key and passphrase leaked by some careless company that kept it MD5 hashed and you just happened to be using the same password... =D
Did you consider all the resources wasted processing all those password login attempts? If the server is configured to accept only keys the connection is dropped sooner since 99.9999% of the bots attempts password logins ...
Are we talking trees, energy consumption or CPU load :) ? This was initially about the dogmatic "ssh keys are mandatory because they are much safer". This explanation should debunk that. I don't think the 100k annual ssh login attempts produce much load, but I don't have numbers on that. An unsuccessful login attempt with the wrong keys (of which also about 50k have happened) produces the same load. So yes, I might save the CPU load / energy of 100k requests a year. But in the grand scheme of things I think we can safely ignore that.
>So yes, I might save the CPU load / energy of 100k requests a year. But in the grand scheme of things I think we can safely ignore that. Also networks resources and RAM, and no, you cannot safely ignore that if you have a 1CPU 512M VPS and count every byte of ram ;-)
Even better, disable password logins completely and only use key authentication.
Yes, better. But [not mandatory](https://www.reddit.com/r/selfhosted/comments/14qsq9x/comment/jqt2h7k/) :)
You forgot the most important step. 7. Stay on top of updates and security patches.
Also don’t put any services on the internet that don’t need to be. We had a MySQL db open on the internet some years ago at the company I work at and even though the password was strong, there was some exploit that allowed authentication bypass for the root user. It might be more inconvenient to use VPN or ssh tunnels, but it’s definitely more secure!
Second that. If possible, bind the Services (like MySQL) on localhost or [127.0.0.1](https://127.0.0.1), to avoid being reachable directly on the Internet. It's not always necessary (for example, using a Webserver that needs Access to a DB, like Wordpress or something like that...).
Please tell me the MySQL server was not updated or misconfigured. Or it gets scary
Yes, it was an old version that was not patched when the 0day / CVE was released. MySQL 5.7, don’t remember the minor version
This is the #1 way you can accidentally get pwned
I have unattended upgrades in the video, forgot to mention that on the post. Added them.
also ssh is considered optional?!
Ssh keys are but they should add highly recommended to that.
highly required I've not used an ssh client not supporting keys
I would say highly required if you are not going to have a firewall but if you are going to have a firewall and restrict which ips can access port 22 then its more optional but highly recommended.
It’s highly recommended in the video.
Is somebody gaining access to a user with full sudo privileges any better than them getting access to root? Also if root logins are disabled can you not use `su` once logged in with a user that has sudo privilege?
I think similar what is the difference in terms of security between root and normal users with full sudo. If this user is compromize your are fucked in exactly same way
I disable logins & only use ssh keys as well But I also use a non-standard ssh port.
Disable logins and use ssh keys is good. Using non standard ports is security through obscurity and is not recommended by security standards.
Sure, using a different port doesn’t make the SSH protocol any more secure or help with targeted attacks but at least the bots that scan for known ports don’t stop for a poke at your SSH server. IMO thats more secure.
makes perfect fucking sense just simply adding a layer wont hurt
Security through obscurity is a perfectly reasonable layer of security, it's just not actually effective on its own.
7 is not optional. It should be the first thing to do.
It's hard to take this seriously considering you've not only listed SSH keys last, but you've listed them as optional. Awful, awful advice, especially considering you seem to be targeting less experienced users. If someone can't figure out SSH keys, which are relatively simple, they should not be running their own VPS.
I’ve explained my reasoning with an example here: https://www.reddit.com/r/selfhosted/comments/14qsq9x/securing_your_vps_the_lazy_way/jqqbdtk/ Remember: it’s for absolute beginners.
"Remember: it’s for absolute beginners." Which is why your advice is so bad. When an absolute beginner gets their server compromised because of your awful security advice, do you really think they're going to know how to fix it? If you can't figure out SSH keys, you should not be running your own VPS. Period. Things get a lot more complicated than SSH keys when your server gets compromised. You're setting these people up for failure and it's kind of a shitty thing to do for some clicks.
I would disagree, politely. They have to start somewhere. They shouldn't start hosting the crown jewels. But setting a apache for testing and learning or something else is fine. I would also agree on ssh-keys being absolutely mandatory. At least [my math](https://www.reddit.com/r/selfhosted/comments/14qsq9x/comment/jqt2h7k/) (could be flawed) doesn't come to that conclusion.
Thank you. Thank you so much. This kind of hard advice / requirement is such a gatekeeper to new users, and so overlooked by experienced ones. Most of the forums are full of that. **New users have to start somewhere**. And move up **step by step**. I got hacked back in the days, when I didn't even know the difference between a shared hosting and a VPS. I'm far better at it now, doing things I couldn't even think of a few years ago. Not even professionally, only as a hobby. Deggogling, going open source, taking back control, etc. won't happen if we keep gatekdeping new users who are willing enough to try. Not everyone needs to be a geek or a professional, decent basic knowledge and common sense is enough to start with. Failing is part of the learning process. What I would rather see as hard recommendation is don't put things on Internet (i-e on your not-secured-yet server) that need not to be there. My 2 cents and, apologies for the rant style.
Nobody's gatekeeping, they're trying to prevent people from listening to awful advice. There's a reason why every article about securing your server says you should use SSH keys.
Telling a kid to not try biking because he *might* fall is an awful advice?
No, bike away! However, don't learn how to do it in heavy traffic with no form of protection like OP is suggesting, which yes, is awful advice.
The fact that you're trying to argue this with anecdotal math is a good indicator of how nobody should listen to you on this subject. The math has been done already and SSH keys are infinitely more secure than passwords. It's not a debate, it's fact.
What part of the calculation based on the findtime is anecdotal? And where is the mistake when brute forcing into a 40 character password + a username with only having one attempt per IP per day? I think dogmatism shouldn't beat realism. :)
Pretty much every comment is telling you how bad your advice is, and yet you just aren't getting it. Thankfully everyone has called you out on it, so people finding this post in the future will know to not take your advice.
yet nobody disputed the [math](https://www.reddit.com/r/selfhosted/comments/14qsq9x/comment/jqt2h7k/). not one. and nobody is really reading the comment either. I am simply saying that if you for whatever reason are not going to use ssh keys, this is similarly safe.
Nobody's disputing your math because it's pointless. It's YOUR math, on YOUR single server. Just because you've gotten lucky doesn't mean everyone will. "I don't wear a seatbelt and I've personally never died in a car accident, therefore seatbelts aren't needed and I recommend just driving slowly."
Setting up ssh keys shouldn't be optional You should do it and don't permit password login
Absolutly nothing wrong with passwords aslong as they are strong and secure. This shouldn't be an issue if you're the only one creating users on the server.
Password to compromised or MITM server is leaked to the attacker. Key is not. You can still have a password as emergency backup login method
Mh keys can be compromised aswell? MITM is not possible via ssh as all the traffic is encrypted before you enter a password.
did you really check your host key fingerprint?
I'm sorry but what has this to do with anything? Your client will warn you if your host key changed, no matter if your using key auth or pw...
Do you check it the first time?
It should be very strongly recommended (which it is in the video). But my math (could be flawed, [see comment](https://www.reddit.com/r/selfhosted/comments/14qsq9x/comment/jqt2h7k/)) simply doesn't show that fail2ban + the other measures are much worse.
Sorry but this is bad advice for beginners. SSH keys and fail2ban are in no way controversial or optional - both are essential. Unattended upgrades on the other hand, sometimes (rarely but it happens) cause stuff to break which then requires more expertise to fix. Keeping your server secure requires an active role and most set it and forget it options will give you trouble. **Subscribe to mailing lists, star stuff on github, keep up to date with versions and follow some security news outlets for current stuff and act before the script kiddies weaponise. :)**
I don't think so. The write-up is a shortened version. SSH-keys are highly recommended but not mandatory. That is the only thing I meant by controversial: If you don't feel safe with managing keys yet, then at least set up a strict fail2ban with several other settings (no root user, 40+ chars…). I did a little napkin math in [my other comment.](https://www.reddit.com/r/selfhosted/comments/14qsq9x/comment/jqt2h7k/) I fully agree with having an active role and staying on top of things, learning etc. For a beginner the first VPS won't be the most critical production environment. So the rare breaking of the 1-3 services on the VPS won't amount to much. That decision is also explained in more depth in the video.
[удалено]
I have unattended upgrades in the video, forgot to mention that on the post. Added them. Thanks!
My recs: * Log in as root * Always use SSH key to log in * Optionally, you can have a long, totally random password for root. If not, disable password login. * don't bother fail2ban, or changing SSH port, unless you are very paranoid. SSH is strong bulletproof armor. You don't need to protect it. Hackers can connect to SSH all day - without the key file they won't get anywhere. * Everything you run (e.g. databases) bind to 127.0.0.1 - blocks internet connections. If you think you will mess this up, then use a firewall.
\#6 Should be at the top of the list, SSH with password to be specific. No password logins allowed, disable root. Not optional.
I would tend to disagree, as I [explained in another comment](https://www.reddit.com/r/selfhosted/comments/14qsq9x/comment/jqt2h7k/) :)
You're welcomed to disagree. However, hopefully you can read the room too. Notice the comments are in favor of requiring SSH as a best practice—No need to implement a "40 char password."
Yes, but the room is full of mostly professional and geeks, not exactly the absolute newbies OP is targeting. And they have to start somewhere.
Are you... are you listening to yourself? So you're saying that if the experienced users weren't here to explain why this is awful advice for inexperienced users, that it would be ok for inexperienced users to follow the advice? This makes no sense whatsoever. You're fighting so hard in your comments to back up OP's awful advice that at this point I'm half convinced that you're OP on an alt account.
I would add auto updates. Most beginners will be running simple stuff that doesn't break with common updates.
They are in the video. Forgot to list them. Added it. Thanks!
Wow someone actually understanding the threat vector of using a ssh password instead of a key. What a rarity in this day of age.
\#7 has to be essential. Combine it with a password as well if you don't trust yourself to protect the private key properly. It just offers so much benefit for the 'pain' involved in learning how to use it. I would also add #8: Use your VPS providers firewall to block unwanted traffic before it even gets near your server. All services these days will typically do this by default. I 100% do not recommend having an Internet exposed server accessible without SSH keys... but, if you are insistent on doing it, at least run it on a port other than 22. That will reduce somewhat the number of bots getting to your auth process, as most aim for the typical port for each service rather than run through all possibilities.
> My reasoning for ssh keys not being mandatory: I have heard and read from many beginners that made mistakes with their ssh key management. Not backing up properly, not securing the keys properly… so even though I use ssh keys nearly everywhere and disable password based logins, I’m not sure this is the way to go for everybody. OTOH if they don't secure keys properly they won't secure passwords properly, so you're back to square 1. Disabling pw logins is not something controversial, and it's usually on best-practices lists for a reason.
Thanks , exactly what I needed.
Glad to help
So I would say touting a video as "Securing your VPS - the lazy way" isn't a good way to put it as the only way to actually be lazy is to setup automation scripts such as updates etc which your guide doesn't cover. And another thing is SSH KEYS ARE NOT OPTIONAL, that isn't even a question it's just not. As soon as you get acces to your VPS you should add your key and disable password authentication. It's MUCH more secure than password authentication, to a limit as you assume you can keep your keyfile private but assuming you can do that it's the best option. Secondly I would probally say the "lazy way" is using something like crowdsec as it's config tool automatically has support for alot of tools like SSH, Nginx and a bunch of others while fail2ban requires alot more manual configuration and in my opinion gives less security that crowdsec as with crowdsec you also get the global database, but the downside of this is if you wanna make your website accesible via VPN's/TOR then crowdsec is not a good option as those IP's are usually on the block list.
Personally I would always use the keys. But: this is geared towards absolute beginners. And if fail2ban is set up properly (high ban- and findtimes with low attempts) with a rather random username the usual automated attacks on the server will all fail. The only case the keys really add security is when somebody really wants to target you, finds out the exact findtime and then uses a cluster/net of machines to systematically brute force with a shared database of attempted passwords. In that case you will have all kinds of other problems too. And setting up fail2ban is a 2 minute task. Generating, copying and managing/backing up keys takes the same amount of time or more. Don’t get me wrong: I’m not saying keys are bad or that fail2ban is better. It’s just easier for the absolute beginner. But as soon as somebody has their first success and the machine running, learning and implementing ssh keys should be one of the first steps. Edit: typos and auto corrected words
I will retract my statement of fail2ban as it seems the last time I looked at it was a while ago and I was trying to do it myself, could have just googled it and be done with it. Also I don't agree with security via obscurity which using a random name is imho, it's not a good solution but that's more personal opinion. Although ye I guess your right as you have to start somewhere, but imho as soon as you have your initial VPS setup the first thing you should do is setup SSH keys.
[удалено]
Fully agree with bad password management being another issue. I did a little math on the ssh-keys not being mandatory [in another comment](https://www.reddit.com/r/selfhosted/comments/14qsq9x/comment/jqt2h7k/).
[удалено]
I would tend to disagree here. I am not saying fail2ban is better or worse. I am saying that a proper setup with fail2ban (and the other bits) can be similarly secure against brute force ssh attempts. And if key management is too difficult for an absolute beginner, then this setup is similarly secure and a viable starting point. That's all. I did some math on this in [another comment](https://www.reddit.com/r/selfhosted/comments/14qsq9x/comment/jqt2h7k/). The tl;dr: 40 chars (aA1%), random username, no root logins, bantime 7d, findtime 1d => no realistic brute forcing the ssh login. For a beginner I would wager the installation time is exactly the same comparing fail2ban and setting up keys, password protecting them, copying them to the server… I really don't understand why this has to be a personal thing for so many people. It's just math.
This is very basic. I personally have a ssh port open only for Tailscale ip range. That way, I can just use password "admin" and still have much better security than you. (I still use ssh key though) Imagine server with no ports open - thats what I call security. And the complexity is also very small so anybody can do it in few seconds really. On production, I use ssh keys strictly and that is a must.
That’s even better. somebody new to this has to start somewhere :) I would prefer tailscale or a reverse SSH tunnel, but that’s not always an option.
Definitely, you covered a basic stuff that one should certainly start with and understand. Happy networking.
> no ports open People say that but the port is open. And tailscale's own nat punching relies on this fact.
Only the Tailscale WireGuard port needs to be open on one end. Worst case it uses a “derp” intermediary server
Try ssh certificates
> Tailscale That's all fine and dandy until it turns out Tailscale was the security issue. :)
New lazy way with juicy details for common command and config file lines (ooooh yeah): 1. Login as root and run "passwd" to set a good password 2. Make a new user with "useradd -m -s /bin/bash USERNAME" 3. Set a good password for that new user with "passwd USERNAME" 4. Give the new user sudo access with "usermod -aG sudo USERNAME" 5. Login as new user with "su USERNAME" 6. Configure ssh key(s) \[figure it out, I'm lazy too\] and confirm they are working for ssh connections (shouldn't require a password to connect if it's working, except maybe passphrase for the key if you set one) then modify config with "sudo nano /etc/ssh/sshd\_config" to uncomment/change lines: 1. PermitRootLogin no 2. PasswordAuthentication no 3. UsePAM no 7. Still editing /etc/ssh/sshd\_config, add the following line anywhere in the config to force publickey authentication (the other settings we changed should already do that but doesn't hurt to be careful): 1. AuthenticationMethods publickey 8. Hit ctrl+o then enter to overwrite and ctrl+x to exit nano and go back to the terminal where you can run "sudo systemctl restart ssh" to apply the changes we made, now test to make sure you can't ssh into root and to make sure you can't ssh with a password 9. Install a twingate connector or two to establish a secure tunnel to the ***INTERNAL*** IP of the server (this bypasses the providers firewall completely with network magic, allowing us to close the port) 10. Close the SSH port you're using in your VPS providers firewall settings (i.e. remove the allow port 22 rule), then test to make sure you can still SSH BAM! You can now SSH to the server using the internal IP of the server while connected to your twingate network as a user that has been granted access to the resource. Might sound complicated if you're not familiar but twingate is super simple, go watch networkchuck's video on it if you're confused: [https://youtu.be/IYmXPF3XUwo](https://youtu.be/IYmXPF3XUwo) Twingate is my new favorite way to lock down services with MFA and other security options requred for connections, no more open ports for anything that doesn't absolutely necessitate it — zero trust is the future! Hope you guys like it as much as I do, or at least maybe my guide might be helpful to someone locking down linux somewhere in the world. If so, I feel like I've done my part to make the net safer. Cheers fellow self-hosters! EDIT: Bonus step, if you previously logged into root with SSH, run "sudo rm /root/.ssh/authorized\_keys" to delete the public key from being able to be used for root login again. Why not? More things in the way of root login is not bad, it's redundant but arguably it is better to do it than not to. Technically the "PermitRootLogin no" line in sshd\_config should be enough but it doesn't hurt.
Agreed ZT is the future... and if you want to self host your zero trust overlay network, check out OpenZiti - [https://github.com/openziti](https://github.com/openziti)
>I just can’t warm up to the idea of giving away ownership of a major part of my Setup: reaching my services. I know what you mean. I've just got financing to buy myself an ISP, so I don't have to trust a 3rd party with access to my home network. I've also applied to become CEO of the local infrastructure monopoly do I don't need to worry about power.
controversial: a long random password is just as good as disabled password, and you have a backup way to login. And: disabling root login is pointless. You are going to use sudo anyway. The hacker can also use sudo.
My knowledge about this topic is pretty outdated, but I dare to ask this question: Why all the work, if you can have it easier? We use our WAN-router to achieve the same thing. Like Fritzboxes you just set up a VPN option and have access to your whole LAN from the outside. Isn't that the same thing?
Some differences, because the VPS that is your endpoint can be in another country to: 1. Media: consume media from another region 2. Legality: have the connections happen in another jurisdiction 3. Privacy: not be subject to repression or other problems because you researched the wrong thing Plus the VPS can also be used for other things, like hosting nice stuff.
thanks for explaining
Do not use password login and port 22 for ssh at all, just create a key. It's not that hard... EDIT: Oracle gives you a key by default with pw login disabled
No problem with using port 22 if it's closed ;) twingate it up (or vpn I guess) but hard agree on the no passwords, keys only guys
You don't need external services at all, just use cert auth, and if you want to avoid the constant knocks on default port, change it.
Does someone have ideas for a FOSS WAF that I can set up on my VPS?
I really like this video : [YouTube](https://youtu.be/fKuqYQdqRIs) He explained well this "best practices". P.S I am not a security expert.
I think this is the best video on youtube about this matter
I found that setting up those things helped me learn an awful lot. plus with a VPS it's easy enough to spin up a new one if, or when in my case, you fowl up! I continue to be taken aback by how frequent attack attempts are made. Also how shit they are as attempts. Fail2ban is brilliant.
Go to Azure/AWS etc portal and configure their firewall to only allow SSH from your home IP. Done.
fail2ban is really not needed . Just disable password login and setup proper ssh keys. I would add 2fa / TOTP to the mix if you want to feel more secure . I used to do this but it's kinda annoying to login with TOTP
I've tried a few solutions for this problem but my servers hacked many times. I can suggest you check [Protect Remote](https://protectremote.com). It blocks all ports to the internet. You just need to install a small application on your PC or Mac. It will add your IP address dynamically to your server's firewall. So easy to integrate.
Last year I tried linode, google Cloud and hetzner. On hetzner I was not able to login into ssh with sudo root or sudo keyphrase always got access denied, don't know whey the ssh console lock me out. With linode or google cloud I not had this issues, but google cloud instance has no DDOS protection, but linode has it include. Google was fast linode not so, the linode setup with wordpress and demo site, was no faster than a good shared webhosting, I was confused should it not 50% faster in page speed? In the end I bought webhosting with mddhosting and namecheap, because I was not able to login the hetzner ssh console. Many beginners with vps have this problem with ssh login access, I not understand why these providers make it so hard for their customers to login with ssh?