The best way is to disable password login and use SSH keys only. Any further steps are not required, but you may additionally install fail2ban or sshguard.

I generally do a few things to protect SSH:

1. Disable password login and use keys only
2. Install and configure Fail2Ban
3. Disable root login via ssh altogether. Just change “permit root login” from “no password” to just “no”. You can still become root via sudo or su after you’re connected, but that would trigger an additional password request. I always connect as a normal user and then use sudo if/when I need it. I don’t include NOPASSWD in my sudoers to make certain sudo prompts for a password. Doesn’t do any good to force normal user login if sudo doesn’t require a password.
4. If connecting via the same network or IPs, restrict the SSH open port to only the IPs you trust.
5. I don’t have SSH internet visible. I have my own Wireguard server running on a separate raspberry pi and use that to access SSH when I’m away, but SSH itself is not open to the internet or forwarded in the router.

In addition to what others say, I also have ntfy notifications on successful login.

Move away from port 22, and 90% vanishes. Move it up to a port in the five digit range, and you will rarely see them.

OP, here is what I do. It might seem overboard, and my way doesn’t make it the best, or the most right, but it seems to work for me:

• Fail2ban
• UFW
• Reverse Proxy
• IPtraf (monitor)
• Lynis (Audit)
• OpenVas (Audit)
• Nessus (Audit)
• Non standard SSH port
• CrowdSec + Appsec
• No root logins
• SSH keys
• Tailscale
• RKHunter

The auditing packages, like Lynis, will scour your server, and make suggestions as to how to further harden your server. Crowdsec is very handy in that it covers a lot of ‘stuff’. It’s not the only WAF around. There is Wazuh, Bunkerweb, etc. Lots of other great comments here with great suggestions. I tend to go overboard on security because I do not like mopping up the mess after a breach.

ETA: just looked up one of your attackers:

218.92.0.201 was found in our database! This IP was reported 64,044 times. Confidence of Abuse is 100%: ISP CHINANET jiangsu province network Usage Type Fixed Line ISP ASN AS4134 Domain Name chinatelecom.cn Country China City Shanghai, Shanghai

busy little cunts.

Change the port.

Does SSH have to be your only way? Could you deploy something like Tailscale? Can you restrict the allowed IP ranges on SSH with a firewall rule?

change port + fail2ban + totp (google-authenticator)

In addition to other advice you could also use SSH over Wireguard. Wireguard basically makes the open port invisible. If you don’t provide the proper key upfront you get no response. To an attacker the port might as well be closed.

Here’s at least one article on the subject: https://rair.dev/wireguard-ssh/

Disable passwords and use public private keys and don’t worry about it

For a general guide on how to make ssh more secure I stick to https://www.sshaudit.com/

You can check your config and they also provide step by step guides for several distros…

What VPS are you using?

You should be able to setup a firewall, blocking all access to the SSH port. Then setup a VPN so that only you can access via SSH after making your VPN connection.

If you connect via a static IP, you can also create an ACL for the VPN connection just in case. You can set an ACL for the SSH port forward rule directly as well, but I don’t like that personally. I prefer keeping things behind the VPN.

https://www.crowdsec.net/

Take the concept of Fail2Ban and add in a community blocklist of thousands of IPs so that you’re blocking not only IPs that have attacked you, but others as well.

It’s neat because they have a number of collections you can download from the community that include readymade parsers for other kinds of logs, and other attack scenarios you can guard against. For example, if you run Nginx or Caddy as webservers on that machine, you can download associated collections for each that can parse your web access log files and ban IPs based on IPs probing your web server for unprotected admin panels, or abusive AI crawlers.

You can even write your own scenarios. I wrote one that immediately blocks you after just one attempt to log in using an account like root, admin,adm,administrator, etc.

One of the simplest is geoip blocks. Here’s an article using iptables, and there may be a nicer way w/ whatever firewall you’re using.

For reference, here are the areas I see in your logs (using this service):

• 218.92.0.201 - China
• 162.142.125.122 - US (Michigan)
• 45.79.181.223 - US (New Jersey)
• 118.25.174.89 - China
• 92.118.39.73 - Romania
• 98.22.89.155 - US (Nebraska)
• 75.12.134.50 - US (Tennessee)
• 165.140.237.71 - US (Washington)
• 65.49.1.29 - US (California)

If you don’t expect valid users to come from those areas, block them. A lot of those in the US are probably from VPN users, so be careful if people are using a VPN to connect to your services.

If you can do it w/ iptables, it’ll be a lot more efficient than doing it at the application layer. I also recommend using something like fail2ban to block individual IPs within regions you care about to get any stragglers that make it through the first tier of blocks. Since this is a VPS, you can also check what firewall settings your provider has and see if you can configure it there so it doesn’t make it to your instance in the first place.

Do you want to prevent brute forcing or do you want to prevent the attack getting in?

If you want to prevent brute forcing then software like fail2ban helps a little, but this is only a IP based block, so with IPv6 this is not really helpfull against a real attack, since rotating IP addresses is trivial. But still can slow down the attacker. Also limiting the amount of sessions and auth tries does significantly slow down the attacker.

If you just want to not worry about it set strong passwords, and when it is a multi user system where other ppl might access it, configure Public Key Auth so you can be sure the other users have strong passwords (or keys in this case) to authenticate.

With strong passwords or keys it is basically impossible to brute force your way in with ssh.