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!

  • CondorWonder@lemmy.caEnglish
    371·
    10 days ago

    We can’t ever stop this kind of stuff, but with something like fail2ban you can set it up to block on too many failures.

    Really though - ensuring your system is kept up to date and uses strong passwords or use a SSH keys is the best defence. Blocking doesn’t prevent them from trying a few times. Moving SSH to a non standard port will stop most of the automated attacks but it won’t stop someone who is dedicated.

    • Lucy :3@feddit.orgEnglish
      191·
      10 days ago

      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.

      • cron@feddit.orgEnglish
        8·
        10 days ago

        Nice list of suggestions, but implementing all of them feels a little over-the-top.

        • Lucy :3@feddit.orgEnglish
          6·
          10 days ago

          Tbh, I myself still have SSH on port 22. Firstly, because I’m lazy, and secondly … yeah that’s it. I’m honestly just lazy. But spam bots trying office/cookie123 are not a real threat, and anyone trying to actually target me will either have somehow acquired my key + password, use one of the probably many security issues that exist in the dozen services I selfhost, social engineer me into doing something (not saying I’ve given out my (old) KeePass password once, but it could be, as love makes blind (I still love her)), or just smash my kneecaps until I give out everything.

    • someacnt@sh.itjust.worksOPEnglish
      1·
      10 days ago

      Thanks, I will try fail2ban. I am using ED25519 for ssh keys, it seems like it’s the best defense on the ssh side. Do you happen to know why this kind of attack is so prevalent?

      • WhyJiffie@sh.itjust.worksEnglish
        2·
        10 days ago

        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)

  • Phoenixz@lemmy.caEnglish
    294·
    10 days ago

    Move the ssh port to higher ranges, 30-60000. That alone will stop 99% of the attacks

    Disable root logins, now usernames must be guessed too which will make success even lower

    Then require SSH keys

    At that point it’s like being in a nuclear fallout nshelter behind a 3 meter thick steel door and you can hear some zombies scratching on the outside… I’m not worried about any of that shit

    • Possibly linux@lemmy.zipEnglish
      0·
      9 days ago

      Changing the port is a total waste of time

      Changing the port is just like putting a picture of a window on your door. Harden SSH properly and don’t waste time with security via obscurity

  • BrianTheeBiscuiteer@lemmy.worldEnglish
    17·
    10 days ago

    In addition to other advice you could also use SSH over Wireguard. Wireguard basically makes the open port invisible. If you don’t provide the proper key upfront you get no response. To an attacker the port might as well be closed.

    Here’s at least one article on the subject: https://rair.dev/wireguard-ssh/

  • Gerowen@lemmy.worldEnglish
    15·
    9 days ago

    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. Just change “permit root login” from “no password” to just “no”. 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.
    • k_rol@lemmy.caEnglish
      21·
      9 days ago

      I vote for wireguard here, I don’t expose anything other than game servers to the internet

  • bizdelnick@lemmy.mlEnglish
    14·
    9 days ago

    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.

  • irmadlad@lemmy.worldEnglish
    13·
    10 days ago

    OP, here is what I do. It might seem overboard, and my way doesn’t make it the best, or the most right, but it seems to work for me:

    • Fail2ban
    • UFW
    • Reverse Proxy
    • IPtraf (monitor)
    • Lynis (Audit)
    • OpenVas (Audit)
    • Nessus (Audit)
    • Non standard SSH port
    • CrowdSec + Appsec
    • No root logins
    • SSH keys
    • Tailscale
    • RKHunter

    The auditing packages, like Lynis, will scour your server, and make suggestions as to how to further harden your server. Crowdsec is very handy in that it covers a lot of ‘stuff’. It’s not the only WAF around. There is Wazuh, Bunkerweb, etc. Lots of other great comments here with great suggestions. I tend to go overboard on security because I do not like mopping up the mess after a breach.

    ETA: just looked up one of your attackers:

    218.92.0.201 was found in our database! This IP was reported 64,044 times. Confidence of Abuse is 100%: ISP CHINANET jiangsu province network Usage Type Fixed Line ISP ASN AS4134 Domain Name chinatelecom.cn Country China City Shanghai, Shanghai

    busy little cunts.

    • sugar_in_your_tea@sh.itjust.worksEnglish
      1·
      9 days ago

      It’s absolutely overboard, and you can get 99% of the way there with this:

      1. WireGuard config (Tailscale in your case)
      2. Bind SSH to WireGuard IP only (so no public SSH port)
      3. SSH keys only, and disable root login over SSH

      That will require breaking WireGuard and openSSH’s key-based authentication, which just isn’t happening. The rest looks like mostly auditing. Even a firewall isn’t necessary if no ports are accessible anyway (i.e. everything only accessible over Tailscale), and you can just configure iptables to block everything on the WAN IP and call it a day.

      • irmadlad@lemmy.worldEnglish
        2·
        9 days ago

        sugar_in_your_tea @sh.itjust.works

        It’s nice to be commented by someone famous.

        Open up the window, let some air into this room I think I’m almost chokin’ from the smell of stale perfume And that cigarette you’re smokin’ 'bout scare me half to death Open up the window, sucker, let me catch my breath

        • sugar_in_your_tea@sh.itjust.worksEnglish
          1·
          9 days ago

          Mama told me not to come.

          Fun fact, my usernames on Reddit (I would cycle them every couple of years) were all Three Dog Night lyrics, so I continued the theme on Lemmy.

          Thanks for noticing. 😀

  • tomsh@lemmy.worldEnglish
    101·
    9 days ago

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

  • hemmes@lemmy.worldEnglish
    51·
    10 days 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.worksEnglish
      42·
      10 days 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).

  • plz1@lemmy.worldEnglish
    4·
    9 days ago

    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?

  • cecilkorik@lemmy.caEnglish
    41·
    10 days 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.orgEnglish
      2·
      10 days 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.

      • sugar_in_your_tea@sh.itjust.worksEnglish
        3·
        10 days ago

        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.