How to harden against SSH brute-forcing?

[voroxpete@sh.itjust.works]

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

[peregus@lemmy.world]

Exactly, this I what alI do!

[Guest]

Is this an alternative/replacement to fail2ban or something you would use along with f2b?

[shortn0te@lemmy.ml]

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.

[sugar_in_your_tea@sh.itjust.works]

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

[surph_ninja@lemmy.world]

Does it need to be exposed to the internet? Putting it behind a vpn would be best.

Besides that, just make sure only the users you need to have access to ssh logins, and use keys for extra hardening. Keep your system updated. Limit that system’s access to other systems on your network, so if it is compromised, they can’t use it as a pivot point for the rest of your setup.

[causticflames@sopuli.xyz]

You could technically still use it alongside f2b, but in my experience Crowd-Sec seems to do a better job and can do the same things.

[bla_bla_bla@feddit.org]

Change the default port and 99% of the bots will be gone

[realitaetsverlust@lemmy.zip]

You don't. This is normal. Ensure key-only auth, ensure you do not login directly as root, maybe install fail2ban and you're good. Some people move the port to a nonstandard one, but that only helps with automated scanners not determined attackers.

You could look into port-knocking if you want it really safe.

[enkers@sh.itjust.works]

I think VPN is the proper way to go about this, but another method is to do port knocking with fkwnop so your SSH port won't respond until the host receives a magic packet.

[sugar_in_your_tea@sh.itjust.works]

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.

[7toed@midwest.social]

No if you're doing that, use a VPN through your firewall. Local traffic is a fair exception as this can only ever be a device on your network, but that depends on your threat model (as those local devices could be compromised). Opening to "your region's" IP range opens you to a lot more than LAN access..

[csm10495@sh.itjust.works]

Bad security advice: use an alternative ssh port. Lots of actors try port 22 and other common alternatives. Much fewer will do a full port scan looking for an ssh server then try brute forcing.

[troed@fedia.io]

A few replies here give the correct advice. Others are just way off.

To those of you who wrote anything else than "disable passwords, use key based login only and you're good" - please spend more time learning the subject before offering up advice to others.

(fail2ban is nice to run in addition, I do so myself, but it's more for to stop wasting resources than having to do with security since no one is bruteforcing keys)

[troed@fedia.io]

This is not "the correct answer". There's absolutely nothing wrong with "exposing" SSH.

[sugar_in_your_tea@sh.itjust.works]

Sure. I'm just assuming that you'd want to access it from areas in your region, like at a friend or family member's house, work, coffee shop, etc. This is especially true if you or one of them has DHCP from their ISP.

If you only ever truly need it at home, then sure, do that. In fact, for something like SSH, you could probably create a Wireguard endpoint that's accessible almost anywhere and connect to that before logging in via SSH.

My point is to not make it more restrictive than you need, otherwise it'll just be frustrating and you'll end up disabling whatever protections you have. You can get a lot of value with a broad ban on troublesome areas (e.g. I don't visit most of the places OP has in their logs, so those would be banned), and then fine-tune the rest w/ something like fail2ban.

[earmaster@lemmy.world]

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

[neidu3@sh.itjust.works]

I use fail2ban and a non-standard SSH port. 99% of this junk disappears if you run sshd on port 9.

Also, disable password for login - Only use keys.

[demesisx@infosec.pub]

If you can use another method, disabling SSH entirely would do it.

This is how Talos Linux achieves best-in-class security properties.

[30p87@feddit.org]

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.