How to harden against SSH brute-forcing? (sh.itjust.works)

submitted 2 months ago by someacnt@sh.itjust.works to c/selfhosted@lemmy.world

120 comments fedilink hide all child comments

Recently, I discovered that SSH of my VPS server is constantly battered as follows.

Apr 06 11:15:14 abastro-personal-arm sshd[102702]: Unable to negotiate with 218.92.0.201 port 53768: no matching key exchange method found. Their offer: diffie>
Apr 06 11:30:29 abastro-personal-arm sshd[102786]: Unable to negotiate with 218.92.0.207 port 18464: no matching key exchange method found. Their offer: diffie>
Apr 06 11:45:36 abastro-personal-arm sshd[102881]: Unable to negotiate with 218.92.0.209 port 59634: no matching key exchange method found. Their offer: diffie>
Apr 06 12:01:02 abastro-personal-arm sshd[103019]: Unable to negotiate with 218.92.0.203 port 16976: no matching key exchange method found. Their offer: diffie>
Apr 06 12:05:49 abastro-personal-arm sshd[103066]: Unable to negotiate with 218.92.0.212 port 49130: no matching key exchange method found. Their offer: diffie>
Apr 06 12:07:09 abastro-personal-arm sshd[103077]: Connection closed by 162.142.125.122 port 56110 [preauth]
Apr 06 12:12:18 abastro-personal-arm sshd[103154]: Connection closed by 45.79.181.223 port 22064 [preauth]
Apr 06 12:12:19 abastro-personal-arm sshd[103156]: Connection closed by 45.79.181.223 port 22078 [preauth]
Apr 06 12:12:20 abastro-personal-arm sshd[103158]: Connection closed by 45.79.181.223 port 22112 [preauth]
Apr 06 12:21:26 abastro-personal-arm sshd[103253]: Connection closed by 118.25.174.89 port 36334 [preauth]
Apr 06 12:23:39 abastro-personal-arm sshd[103282]: Unable to negotiate with 218.92.0.252 port 59622: no matching key exchange method found. Their offer: diffie>
Apr 06 12:26:38 abastro-personal-arm sshd[103312]: Connection closed by 92.118.39.73 port 44400
Apr 06 12:32:22 abastro-personal-arm sshd[103373]: Unable to negotiate with 218.92.0.203 port 57092: no matching key exchange method found. Their offer: diffie>
Apr 06 12:49:48 abastro-personal-arm sshd[103556]: error: maximum authentication attempts exceeded for root from 98.22.89.155 port 53675 ssh2 [preauth]
Apr 06 12:49:48 abastro-personal-arm sshd[103556]: Disconnecting authenticating user root 98.22.89.155 port 53675: Too many authentication failures [preauth]
Apr 06 12:49:51 abastro-personal-arm sshd[103558]: error: maximum authentication attempts exceeded for root from 98.22.89.155 port 53775 ssh2 [preauth]
Apr 06 12:49:51 abastro-personal-arm sshd[103558]: Disconnecting authenticating user root 98.22.89.155 port 53775: Too many authentication failures [preauth]
Apr 06 12:49:53 abastro-personal-arm sshd[103561]: error: maximum authentication attempts exceeded for root from 98.22.89.155 port 53829 ssh2 [preauth]
Apr 06 12:49:53 abastro-personal-arm sshd[103561]: Disconnecting authenticating user root 98.22.89.155 port 53829: Too many authentication failures [preauth]
Apr 06 12:49:54 abastro-personal-arm sshd[103563]: Connection closed by 98.22.89.155 port 53862 [preauth]
Apr 06 12:50:41 abastro-personal-arm sshd[103576]: Invalid user  from 75.12.134.50 port 36312
Apr 06 12:54:26 abastro-personal-arm sshd[103621]: Connection closed by 165.140.237.71 port 54236
Apr 06 13:01:26 abastro-personal-arm sshd[103702]: Connection closed by 193.32.162.132 port 33380
Apr 06 13:03:40 abastro-personal-arm sshd[103724]: Unable to negotiate with 218.92.0.204 port 60446: no matching key exchange method found. Their offer: diffie>
Apr 06 13:11:49 abastro-personal-arm sshd[103815]: Received disconnect from 165.140.237.71 port 50952:11:  [preauth]
Apr 06 13:11:49 abastro-personal-arm sshd[103815]: Disconnected from authenticating user root 165.140.237.71 port 50952 [preauth]
Apr 06 13:19:08 abastro-personal-arm sshd[103897]: Unable to negotiate with 218.92.0.208 port 59274: no matching key exchange method found. Their offer: diffie>
Apr 06 13:33:36 abastro-personal-arm sshd[104066]: Received disconnect from 165.140.237.71 port 50738:11:  [preauth]
Apr 06 13:33:36 abastro-personal-arm sshd[104066]: Disconnected from authenticating user ubuntu 165.140.237.71 port 50738 [preauth]
Apr 06 13:34:50 abastro-personal-arm sshd[104079]: Unable to negotiate with 218.92.0.204 port 44816: no matching key exchange method found. Their offer: diffie>
Apr 06 13:50:32 abastro-personal-arm sshd[104249]: Unable to negotiate with 218.92.0.206 port 27286: no matching key exchange method found. Their offer: diffie>
Apr 06 13:51:58 abastro-personal-arm sshd[104261]: Received disconnect from 165.140.237.71 port 50528:11:  [preauth]
Apr 06 13:51:58 abastro-personal-arm sshd[104261]: Disconnected from authenticating user root 165.140.237.71 port 50528 [preauth]
Apr 06 14:01:25 abastro-personal-arm sshd[104351]: Invalid user  from 65.49.1.29 port 18519
Apr 06 14:01:28 abastro-personal-arm sshd[104351]: Connection closed by invalid user  65.49.1.29 port 18519 [preauth]

As you can see, it is happening quite frequently, and I am worried one might break in at some point. Since SSH access guards users with root-access, it can be quite serious once penetrated. How do I harden against these kind of attacks? Because this is VPS, disabling SSH is a no-go (SSH is my only entry of access). Are there ways to stop some of these attackers?

As always, thanks in advance!

(page 2) 50 comments

sorted by: hot top controversial new old

[-] Appoxo@lemmy.dbzer0.com 3 points 2 months ago

You could limit the firewall to IP range(s) of your domestic (and other places of interest like work) connection.
This way they won't come even close to even logging in.
And then you could do the other hardening on top.

[-] boblemmy@lemmy.world 3 points 2 months ago* (last edited 2 months ago)

change port + fail2ban + totp (google-authenticator)

[-] Dima@feddit.uk 3 points 2 months ago* (last edited 2 months ago)

For security disable password authentication - use public key instead, disable root login via ssh - use sudo or su from another user.

To reduce the number of attempts of others trying to get in change the ssh port and/or set-up fail2ban.

You could also set a firewall rule to only allow ssh from your IP address, if you have a static address at home and only need access from there, or have a way to VPN into your home network. Make sure you have a static address if you do this though, you don't want your IP to change and be left locked out of your server.

[-] sugar_in_your_tea@sh.itjust.works 1 points 2 months ago

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

[-] 7toed@midwest.social 1 points 2 months ago* (last edited 2 months ago)

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

[-] sugar_in_your_tea@sh.itjust.works 0 points 2 months ago* (last edited 2 months ago)

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. You only really need to whitelist a handful of IP ranges to get most of the benefit of IP-based blocking and most of the convenience of not having a block.

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.

I use my ISP's firewall rule to whitelist regions I'm interested in, such as:

data centers where I have services
my town and my friends' and families' towns
the town near where I work

I have different rules by port, so SSH is a lot more restricted than HTTP(s).

[-] Realitaetsverlust@lemmy.zip 3 points 2 months ago

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.

[-] suicidaleggroll@lemm.ee 2 points 2 months ago* (last edited 2 months ago)

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.

[-] EncryptKeeper@lemmy.world 2 points 2 months ago

https://www.crowdsec.net/

Take the concept of Fail2Ban and add in a community blocklist of thousands of IPs so that you’re blocking not only IPs that have attacked you, but others as well.

It’s neat because they have a number of collections you can download from the community that include readymade parsers for other kinds of logs, and other attack scenarios you can guard against. For example, if you run Nginx or Caddy as webservers on that machine, you can download associated collections for each that can parse your web access log files and ban IPs based on IPs probing your web server for unprotected admin panels, or abusive AI crawlers.

You can even write your own scenarios. I wrote one that immediately blocks you after just one attempt to log in using an account like root, admin,adm,administrator, etc.

[-] irmadlad@lemmy.world 2 points 2 months ago

+1 for Crowdsec

[-] Waryle@jlai.lu 2 points 2 months ago* (last edited 2 months ago)

You can look up for:

Setting up max authentication attemps per connection -> slows up a lot brute force attacks. If your password is strong enough, that's already a big step to secure your server.
Generate SSH Keys and disable password authentication -> do this only if you're connecting through the same devices, because you won't be able to connect from any device that has not being set up. Personally I don't use this because I want to be able to access my server even if I'm not home and without my laptop
Set up Crowdsec -> it's a local service which scans logs and will block access to any suspicious IPs. It also relies on a crowdsourced list of IPs that are identified as threat and will preventively block them

[-] LlilL@lemm.ee 1 points 2 months ago

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

[-] CausticFlames@sopuli.xyz 1 points 2 months ago

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.

[-] LlilL@lemm.ee 2 points 2 months ago

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

[-] AceSLS@ani.social 1 points 2 months ago* (last edited 2 months ago)

Like others said, disable password auth and setup auth keys instead.

Bonus points for moving the ssh port, using fail2ban and also setting up a tarpit with something like endlessh.

If you wanna go extreme use Wireguard to connect to your server and only allow ssh over wireguard in your firewall.

[-] sntx@lemm.ee 1 points 2 months ago

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

[-] Treczoks@lemmy.world 1 points 2 months ago

Move away from port 22, and 90% vanishes. Move it up to a port in the five digit range, and you will rarely see them.

[-] sugar_in_your_tea@sh.itjust.works 1 points 2 months ago* (last edited 2 months ago)

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. Since this is a VPS, you can also check what firewall settings your provider has and see if you can configure it there so it doesn't make it to your instance in the first place.

[-] hemmes@lemmy.world 0 points 2 months ago

What VPS are you using?

You should be able to setup a firewall, blocking all access to the SSH port. Then setup a VPN so that only you can access via SSH after making your VPN connection.

If you connect via a static IP, you can also create an ACL for the VPN connection just in case. You can set an ACL for the SSH port forward rule directly as well, but I don’t like that personally. I prefer keeping things behind the VPN.

load more comments (16 replies)

load more comments

this post was submitted on 06 Apr 2025

97 points (99.0% liked)

Selfhosted

48278 readers

192 users here now

A place to share alternatives to popular online services that can be self-hosted without giving up privacy or locking you into a service you don't control.

Rules:

Be civil: we're here to support and learn from one another. Insults won't be tolerated. Flame wars are frowned upon.
No spam posting.
Posts have to be centered around self-hosting. There are other communities for discussing hardware or home computing. If it's not obvious why your post topic revolves around selfhosting, please include details to make it clear.
Don't duplicate the full text of your blog or github here. Just post the link for folks to click.
Submission headline should match the article title (don’t cherry-pick information from the title to fit your agenda).
No trolling.

Resources:

selfh.st Newsletter and index of selfhosted software and apps
awesome-selfhosted software
awesome-sysadmin resources
Self-Hosted Podcast from Jupiter Broadcasting

Any issues on the community? Report it using the report flag.

Questions? DM the mods!

founded 2 years ago

MODERATORS

HybridSarcasm@lemmy.world

HybridSarcasm@lemmy.hybridsarcasm.xyz