How to harden against SSH brute-forcing?

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

[sugar_in_your_tea@sh.itjust.works]

Fail2ban blocks IPs that fail to connect repeatedly. A honeypot pretends fails worked and gives them a worthless environment to try to exploit. The purpose of fail2ban is to block attacks, the purpose of a honeypot is amusement and to waste attackers' time.

[callcc@lemmy.world]

Be sure to use a passphrase

[Guest]

I understood the comment as "leave the port open to ssh, to easily allow fail2ban to hit the ip's before they get through your full port range." But thanks for the elaborate answer

I agree, what you described is much more work

[sugar_in_your_tea@sh.itjust.works]

It's also one of the biggest targets for attack. Here's a somewhat recent CVE and here is another. Staying on top of security patches is absolutely critical, and many don't do that.

The best security practice is to layer your protections.

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

They're not about SSH, sure, but they are relevant to securing a system to remote access. Always assume your security infra will be compromised and plan accordingly. Generally speaking, the more layers, the better.

[a_postmodern_hat@lemmy.world]

You could get a hardware key (like a Yubikey) and authenticate with PIV or GPG.

[tomsh@lemmy.world]

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

[voroxpete@sh.itjust.works]

This is the selfhosted community; Who are you training? In most cases there's literally only one person who would ever need SSH access to this server. Maybe two or three in a tiny handful of cases, but anyone who can't figure out Netbird in 30 seconds absolutely should not be accessing anything via SSH.

And you've clearly never used Netbird, Tailscale, or any similar service, if you think that update, maintenance and config constitute any kind of meaningful burden, especially for something as simple as remote access to a VPS.

[sugar_in_your_tea@sh.itjust.works]

why stop at one vpn

Because an additional one adds a different type of security unrelated to securing your server, it's about securing data en route to your server (e.g. hiding that you're accessing it at all from wherever you are. Maybe you want that, but it's irrelevant to securing your server.

But on the larger topic of diminishing returns, yeah, maybe you don't need it.

However, I would never feel comfortable with just one line of defense, regardless of how good that product is. I trust openSSH, which is why I have it running, but all software has bugs and I want more than domino that needs to fall before I get pwned. If there's a successful attack on openSSH, you can bet the script kiddies will exploit it before you get around to patching your server, especially in a homelab setup.

This setup isn't particularly crazy, and I'd recommend a lot more of someone has special requirements. Setting up WireGuard is like 20 lines of config, it's baked into the kernel (except wg-quick, the frontend), and the project is super stable (no major changes in years). Pretty much everything has great support for it (built-in to Android, Linux DEs, etc), and you really don't need to touch it unless you need to set up a new machine.

But if you don't want a VPN for whatever reason, there are other options for additional security:

• geoip blocking - allow only those regions that you expect to connect from (different rules for each port, so SSH can be special)
• fail2ban - block IPs if they fail to authenticate after a few attempts

But please do more than just securing openSSH, because all software has bugs and an extra layer isn't that much more work.