How to harden against SSH brute-forcing?

[joshcodes@programming.dev]

100% agree, that is a "totally for fun" exercise

[arghblarg@lemmy.ca]

There's a dedicated tool named sshguard which works nicely.

[db0@lemmy.dbzer0.com]

No Port-knocking? Amateurs! /s

[Guest]

Thank for that! You just turned a student onto a new tool to play with.

[Guest]

did you mean crowdsec instead of crowdstrike?

[whyjiffie@sh.itjust.works]

I'm not them, but among other reasons they are looking to build botnets (cryptomining, dosing, mass crawling), and they are searching for hosts with low security (or if you just made a mistake)

[null_dot@lemmy.dbzer0.com]

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.

[kylian0087@lemmy.dbzer0.com]

Configure the firewall with a IP whitelist to only allow connections to ssh be made from your home IP.

Other then that, disable password logon for ssh and setup up key based authentication.

[zr0@lemmy.dbzer0.com]

Fml… yes, I meant CrowdSec. Thanks for the hint

[whodatdair@lemmy.blahaj.zone]

Vietnam stare

[troed@fedia.io]

Still no. Here's the reasoning: A well known SSHd is the most secure codebase you'll find out there. With key-based login only, it's not possible to brute force entry. Thus, changing port or running fail2ban doesn't add anything to the security of your system, it just gets rid of bot login log entries and some - very minimal - resource usage.

If there's a public SSHd exploit out, attackers will portscan and and find your SSHd anyway. If there's a 0-day out it's the same.

(your points 4 and 5 are outside the scope of the SSH discussion)

[structureofchaos@lemmynsfw.com]

Regarding SSH Keys, I was wondering how you keep your key safe and potentially usable from another client?

[Guest]

By all means, I am no expert, but isn't it "just" the fail2ban?

[plz1@lemmy.world]

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?

[bizdelnick@lemmy.ml]

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.

[sntx@lemm.ee]

https://media.ccc.de/v/38c3-attack-mining-how-to-use-distributed-sensors-to-identify-and-take-down-adversaries

[gerowen@lemmy.world]

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. 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.

[dev_null@lemmy.ml]

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.

[callcc@lemmy.world]

Ok, fair point. But why stop at one vpn? I choose to trust OpenSSH, but I agree that adding a secondary layer of security actually helps here. You basically multiply two very low probabilities to get an even lower one. The trade-off is that you add complexity. You now need to keep two services up to date, and correctly configured and access/key material distributed.

I'd only recommend this setup for projects with special security requirements.

[callcc@lemmy.world]

I don't agree about the point concerning cost. You have additional training, update, maintenance and config burden. This on top of the burdon of using the VPN on top of ssh.