How to harden against SSH brute-forcing?

[jubilantjaguar@lemmy.world]

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.

[xanza@lemm.ee]

1. Disable passwordless login.
2. Disable password login.
3. Require SSH keys
4. Move SSH port to non-standard port
5. Reject connections to port 22
6. Install and enable fail2ban

About the best you can do.

[markstos@lemmy.world]

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.

[cmnybo@discuss.tchncs.de]

It gets rid of most of the login attempts for me. I don't use a popular port though. Pick a 5 digit port so they have to put in some effort to find it.

[friend_of_satan@lemmy.world]

My experience running several ssh servers on uncommon nonstandard ports for over 10 years has been that it has eliminated all ssh brute forcing. I don't even bother with fail2ban. I probably should though, just in case.

Also, PSA: if you use fail2ban, don't try tab completing rsync commands without using controlmaster or you will lock yourself out.

[irmadlad@lemmy.world]

My two cents: Using a nonstandard ssh port is good for dumping bots. True, you can easily do a port scan against a server and easily find all open ports nbd. But most off-the-shelf bots are looking for standard ports to penetrate. I know that when I format and reinstall the test server, as soon as I change the ssh port, bot noise goes down significantly. So, for a simple config edit and about 2 minutes of time, it seems worth the effort. It's just one layer tho. And yes, it goes without saying to pick a port other than 22, 222, 2222, etc.

[irmadlad@lemmy.world]

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.

[irmadlad@lemmy.world]

+1 for Crowdsec

[voroxpete@sh.itjust.works]

And mine. Clearly one of us is better at it.

[voroxpete@sh.itjust.works]

A lot of things are "fine", but the cost of adding Netbird to your VPS is effectively zero, whether counted in dollars, time, or convenience.

Given the massive security benefits of using a VPN, and the lack of any meaningful downside to doing so, you'd be an idiot not to.

[bigbananas@feddit.nl]

Also, add 2FA

[30p87@feddit.org]

Tbh, I myself still have SSH on port 22. Firstly, because I'm lazy, and secondly ... yeah that's it. I'm honestly just lazy. But spam bots trying office/cookie123 are not a real threat, and anyone trying to actually target me will either have somehow acquired my key + password, use one of the probably many security issues that exist in the dozen services I selfhost, social engineer me into doing something (not saying I've given out my (old) KeePass password once, but it could be, as love makes blind (I still love her)), or just smash my kneecaps until I give out everything.

[30p87@feddit.org]

But remember, on a third device. Not the one where your KeePass DB is one fingerprint away, and your private SSH key too.

[phoenixz@lemmy.ca]

Move the ssh port to higher ranges, 30-60000. That alone will stop 99% of the attacks

Disable root logins, now usernames must be guessed too which will make success even lower

Then require SSH keys

At that point it's like being in a nuclear fallout nshelter behind a 3 meter thick steel door and you can hear some zombies scratching on the outside... I'm not worried about any of that shit

[callcc@lemmy.world]

And why exactly is that more secure?

[semperverus@lemmy.world]

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

[moonpiedumplings@programming.dev]

This is moving the goal posts. You went from "ssh is not fine to expose" to "VPN's add security". While the second is true, it's not what was being argued.

Never expose your SSH port on the public web,

Linux was designed as a multi user system. My college, Cal State Northridge, has an ssh server you can connect to, and put your site up. Many colleges continue to have a similar setup, and by putting stuff in your homedir you can have a website at no cost.

There are plenty of usecases which involve exposing ssh to the public internet.

And when it comes to raw vulnerabilities, ssh has had vastly less than stuff like apache httpd, which powers wordpress sites everywhere but has had so many path traversal and RCE vulns over the years.

[sugar_in_your_tea@sh.itjust.works]

honeypot

That's a lot more work.

[zr0@lemmy.dbzer0.com]

• harden sshd
• use fail2ban or even better CrowdStrike
• use a tool like the following to have a next-gen security solution: https://github.com/mrash/fwknop

[suicidaleggroll@lemm.ee]

Some people move the port to a nonstandard one, but that only helps with automated scanners not determined attackers.

While true, cleaning up your logs such that you can actually see a determined attacker rather than it just getting buried in the noise is still worthwhile.