133

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
[-] troed@fedia.io 13 points 1 day ago

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)

[-] nekusoul@lemmy.nekusoul.de 6 points 1 day ago

Eh, while I agree that some recommendations are dodgy at best, I'll argue that Wireguard is not only adding to security, it also makes Fail2Ban obsolete. Due to the way it works, you'll completely hide the fact that you're even running a SSH server at all, and this includes even Wireguard itself. More importantly though, it's pretty much impossible to set up Wireguard in an insecure way, whereas SSH provides you with plenty of footguns. You're not risking locking yourself out either.

Also, security comes in layers.

You’re not risking locking yourself out either.

In a VPS, you should always be able to fall back to the web console. So locking yourself out shouldn't be a major concern.

There's more to it than that.

I recommend geoip blocking anything outside of your expected operating regions in addition to using key-based logins. iptables operates at a lower level in the network stack than SSH, so the vulnerability surface is a lot lower, and blocking before something actually looks at the packets cleans up the logs. This is huge because it makes it a lot more obvious when there's a legitimate attack.

Cover yourself with layers:

  1. block obviously bad packets at the firewall level
  2. eliminate insecure modes of login (only allow key-based login)
  3. something like fail2ban to ban the few who make it through 1 & 2
  4. use a secure root password so if someone does get in, they're less likely to get root access
  5. have your services run as non-privileged users to limit issues if something gets compromised

If you only do one thing, it should be only allowing key-based logins. If you do two, run SSH on a non-standard port or set up geoip blocking (second is more work, but a lot more effective).

load more comments (2 replies)
[-] Waryle@jlai.lu 13 points 1 day ago* (last edited 1 day 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
load more comments (3 replies)
[-] EarMaster@lemmy.world 8 points 1 day ago* (last edited 1 day ago)

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

[-] hemmes@lemmy.world 9 points 1 day 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.

[-] Voroxpete@sh.itjust.works 7 points 1 day ago

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

[-] troed@fedia.io 7 points 1 day ago

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

[-] Voroxpete@sh.itjust.works 2 points 1 day ago

You seem like a fan of the "pull out" method.

[-] callcc@lemmy.world 5 points 1 day ago

Public ssh is completely fine as long as you use key based auth only and keep your sshd up to date. Stop spreading bullshit.

load more comments (11 replies)
[-] troed@fedia.io 4 points 1 day ago

Feel free to argue with facts. Hardening systems is my job.

[-] Voroxpete@sh.itjust.works 2 points 1 day ago

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

[-] peregus@lemmy.world 3 points 1 day ago

Exactly, this I what alI do!

[-] cecilkorik@lemmy.ca 8 points 1 day ago

fail2ban is mandatory equipment for any ssh server accessible to the public especially on its default port. It's highly configurable, but the default settings will do fine at making it statistically impossible for any user or password to be brute forced.

[-] cron@feddit.org 4 points 1 day ago

I don’t really get the love for fail2ban. Sure, it helps keep your logs clean, but with a solid SSH setup (root disabled, SSH keys enforced), I’m not bothered by the login attempts.

You should be. Most of it's noise, but if there's a serious attack, you'll appreciate clean logs.

I think fail2ban is nice as like a third or fourth layer of defense. In order of my priorities:

  1. key-only login, root login completely disabled
  2. solid root password, and user privilege separation (have each service use its own user)
  3. geoip bans - if you never plan to support clients in a given region, block it at the firewall level (or better yet, whitelist the handful of regions you care about); I do this by port, so SSH gets a much more restricted set of allowed regions than HTTPS
  4. fail2ban - especially if you have a relatively large whitelist
  5. only access SSH over a Wireguard VPN - Wireguard doesn't show up in port scans, and SSH can bind to the VPN host instead of 0.0.0.0, so the ability to login via SSH will be completely hidden

If you're not going to do 3-5, at least change the default SSH port to cut down on log noise.

[-] AceSLS@ani.social 6 points 1 day ago* (last edited 1 day 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.

[-] EncryptKeeper@lemmy.world 4 points 1 day 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 3 points 1 day ago

+1 for Crowdsec

[-] demesisx@infosec.pub 4 points 1 day ago* (last edited 1 day ago)

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

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

https://www.siderolabs.com/blog/how-to-ssh-into-talos-linux/

[-] callcc@lemmy.world 3 points 1 day ago

Welcome to the internet! Your system will get probed. Make sure you run as little as possible services on open ports and only high quality ones such as OpenSSH. Don't freak out because of your logs. You're fine as long as your system is up to date and password login disabled! Don't listen to the fail2ban or VPN crowd. Those are only snake oil.

A VPN is probably just as (in)secure as OpenSSH. There is no gain in complicating things. OpenSSH is probably one of the most well tested code for security around.

[-] sugar_in_your_tea@sh.itjust.works 3 points 1 day ago* (last edited 1 day 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.

[-] someacnt@sh.itjust.works 1 points 1 day ago

Thanks a lot! Geoblocking makes a lot of sense, will try!

I highly recommend using key-based SSH authentication exclusively for all users on your server, and disallow root login as well.

Geoblocking mostly cuts down on the spam, but also constrains where an actual attack can come from. If there's some kind of zero-day attack on SSH, this will dramatically reduce the risk you're hit.

[-] someacnt@sh.itjust.works 2 points 1 day ago

Fortunately my VPS (oracle) has set SSH authentication to be default. Disallowing root login sounds good, gotta try that as well.

[-] slazer2au@lemmy.world 3 points 1 day ago

I assume you have root login denied in your ssh config, other things would be having fail2ban and some geofencing (blocking IPs from countries you know you are never going to log in from).

[-] unlogic@lemmy.zip 2 points 1 day ago* (last edited 1 day ago)

If you can, employ tailscale ssh and prevent ssh from outside tailscale network. Tailscale have a good guide for this

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

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.

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

~~Bad~~ eh 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.

[-] Enkers@sh.itjust.works 2 points 1 day ago

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.

load more comments
view more: ‹ prev next ›
this post was submitted on 06 Apr 2025
133 points (100.0% liked)

Selfhosted

45541 readers
1104 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:

  1. Be civil: we're here to support and learn from one another. Insults won't be tolerated. Flame wars are frowned upon.

  2. No spam posting.

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

  4. Don't duplicate the full text of your blog or github here. Just post the link for folks to click.

  5. Submission headline should match the article title (don’t cherry-pick information from the title to fit your agenda).

  6. No trolling.

Resources:

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

Questions? DM the mods!

founded 2 years ago
MODERATORS