Move SSH to non-standard port, make endlessh use the default port. Only use SSH keys. Only allow correct users (so eg. your user and git/forgejo). Use fail2ban to aggressively ban (redirect to default port, so 22) and report to abuseipdb everything that fails to authenticate first try (wrong user, password instead of key), has non-compatible ciphers (generally, only allow TLS1.3 etc.), or fails in any other way. Just be sure that if you accidentally get banned yourself (eg. Ctrl+C-ing during authentication), you can use another IP (eg. force v4) for connecting.

Thanks, I will try fail2ban. I am using ED25519 for ssh keys, it seems like it’s the best defense on the ssh side. Do you happen to know why this kind of attack is so prevalent?

Don’t reject connections to port 22, honeypot it and ban on connection attempt.

Using a nonstandard port doesn’t get you much, especially popular nonstandard ports like 2222.

I used that port once and just as much junk traffic and ultimately regretted bothering.

For added funs run an SSH tarpit to fuck with the attackers, something like endlessh.

This is what I do. Changing the port to a higher number will prevent almost all bots.

I understand that obscurity is not security but not getting probed is nice.

Also ssh keys are a must.

I do log in as root though.

However, I block all IPs other than mine from connecting to this port in my host’s firewall. I only need to log in from home, or my office, and in a crisis I can just log in to OVH and add whitelist my IP.

You could also set a firewall rule to only allow ssh from your IP address

You can also broaden this to a region. You may still want to access SSH from various places around your country (e.g. when visiting family or friends), but likely won’t ever need to from most of the rest of the world, so block everything except IPs from your region (or regions you care about, e.g. any VPSs you have).

I vote for wireguard here, I don’t expose anything other than game servers to the internet

This is the only answer you need to read. It’s a non-problem if you just do this, and there’s no reason not to do it.

No Port-knocking? Amateurs! /s

It’s absolutely overboard, and you can get 99% of the way there with this:

1. WireGuard config (Tailscale in your case)
2. Bind SSH to WireGuard IP only (so no public SSH port)
3. SSH keys only, and disable root login over SSH

That will require breaking WireGuard and openSSH’s key-based authentication, which just isn’t happening. The rest looks like mostly auditing. Even a firewall isn’t necessary if no ports are accessible anyway (i.e. everything only accessible over Tailscale), and you can just configure iptables to block everything on the WAN IP and call it a day.

did you mean crowdsec instead of crowdstrike?

harden sshd

More details:

• require keys to login
• don’t allow login as root

That should be plenty, but you could go a bit further and restrict the types of algorithms allowed (e.g. disallow RSA if you’re worried about quantum attacks). For this, I recommend a subtractive config (e.g. HostbasedAcceptedAlgorithms=-rsa-*). This is way over the top since an attacker is unlikely to attack the cipher directly, but it could be part of an attack.

Your answer to “how to harden SSH?” is “harden SSH”?

I know your two other points gave concrete suggestions, but it’s pretty funny you suggested to “harden sshd” when that is what OP is asking how to do.

Agreed, but be careful about the whitelist. If your home IP changes, you’ll be locked out until you update it, so you should consider an IP range if that’s a possibility for you. Likewise, if you’ll be accessing it from multiple locations (say, a family member’s house), then make sure to add those as well.

That’s genius. I’ll do the same from now on.

Exactly, this I what alI do!

This is the correct answer. Never expose your SSH port on the public web, always use a VPN. Tailscale, Netmaker or Netbird make it piss easy to connect to your VPS securely, and because they all use NAT traversal you don’t have to open any ports in your firewall.

Combine this with configuring UFW on the server (in addition to the firewall from the VPS provider - layered defence is king) and Fail2Ban. SSH keys are also a good idea. And of course disable root SSH just in case.

With a multi-layered defence like this you will be functionally impervious to brute force attacks. And while each layer of protection may have an undiscovered exploit, it will be unlikely that there are exploits to bypass every layer simultaneously (Note for the pendants; I said “unlikely”, not “impossible”. No defence is perfect).

There’s more to it than that.

I recommend geoip blocking anything outside of your expected operating regions in addition to using key-based logins. iptables operates at a lower level in the network stack than SSH, so the vulnerability surface is a lot lower, and blocking before something actually looks at the packets cleans up the logs. This is huge because it makes it a lot more obvious when there’s a legitimate attack.

Cover yourself with layers:

1. block obviously bad packets at the firewall level
2. eliminate insecure modes of login (only allow key-based login)
3. something like fail2ban to ban the few who make it through 1 & 2
4. use a secure root password so if someone does get in, they’re less likely to get root access
5. have your services run as non-privileged users to limit issues if something gets compromised

If you only do one thing, it should be only allowing key-based logins. If you do two, run SSH on a non-standard port or set up geoip blocking (second is more work, but a lot more effective).