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!

  • Phoenixz@lemmy.caEnglish
    0·
    12 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

    • null_dot@lemmy.dbzer0.comEnglish
      0·
      12 days ago

      This is what I do. Changing the port to a higher number will prevent almost all bots.

      I understand that obscurity is not security but not getting probed is nice.

      Also ssh keys are a must.

      I do log in as root though.

      However, I block all IPs other than mine from connecting to this port in my host’s firewall. I only need to log in from home, or my office, and in a crisis I can just log in to OVH and add whitelist my IP.

      • sugar_in_your_tea@sh.itjust.worksEnglish
        0·
        11 days ago

        I do log in as root though.

        Don’t do that. You’re one local piece of malware away from getting your server pwned. Logging in as an unprivileged user at least requires another exploit on the server to get root permissions.

    • Possibly linux@lemmy.zipEnglish
      0·
      11 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

      • sugar_in_your_tea@sh.itjust.worksEnglish
        0·
        11 days ago

        That’s not true.

        Security through obscurity isn’t real security, sure, but it does a lot to reduce the noise in the logs so you can see the more real attacks. Hardening SSH properly is certainly more important, but changing the port also has value.

      • AustralianSimon@lemmy.worldEnglish
        0·
        11 days ago

        I think the point behind it is to waste the sniffers time sniffing for ports that it could be using to be making attempts.

        Its not a security thing, it’s just increasing the cost to snoop.

  • sugar_in_your_tea@sh.itjust.worksEnglish
    0·
    12 days 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.

      • sugar_in_your_tea@sh.itjust.worksEnglish
        0·
        12 days ago

        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.worksOPEnglish
          0·
          12 days ago

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

  • csm10495@sh.itjust.worksEnglish
    0·
    12 days 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.worksEnglish
    0·
    13 days 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.

  • callcc@lemmy.worldEnglish
    0·
    12 days 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.

  • Xanza@lemm.eeEnglish
    0·
    12 days ago
    1. Disable passwordless login.
    2. Disable password login.
    3. Require SSH keys
    4. Move SSH port to non-standard port
    5. Reject connections to port 22
    6. Install and enable fail2ban

    About the best you can do.

    • markstos@lemmy.worldEnglish
      0·
      12 days ago

      Using a nonstandard port doesn’t get you much, especially popular nonstandard ports like 2222.

      I used that port once and just as much junk traffic and ultimately regretted bothering.

      • Xanza@lemm.eeEnglish
        0·
        9 days ago

        Using a nonstandard port doesn’t get you much

        Uhh… It gets you a lot. Specifically, unless you know the port you can’t connect… So hey, there’s that…

        This community really says shit sometimes that makes me go cross-eyed…

        • markstos@lemmy.worldEnglish
          0·
          8 days ago

          The top-rated answer to this question on the Security StackExhange is “not really”. https://security.stackexchange.com/questions/189726/does-it-improve-security-to-use-obscure-port-numbers

          On Serverfault, the top answer is that random SSH ports provide “no serious defense” https://serverfault.com/questions/316516/does-changing-default-port-number-actually-increase-security

          Or the answer here, highlighting that scanners check a whole range ports and all the pitfalls of changing the port. Concluding: “Often times it is simply easier to just configure your firewall to only allow access to 22 from specific hosts, as opposed to the whole Internet.” https://security.stackexchange.com/questions/32308/should-i-change-the-default-ssh-port-on-linux-servers

          • Xanza@lemm.eeEnglish
            0·
            8 days ago

            And I’m a CEHv7. A literal security professional–and I say that an overwhelming vast majority of attacks against servers using SSH are going to come over the default port. Quite literally 99%. This means that you can lower your attack surface by exactly 99% by simply changing the default SSH port…

            Those posts provide no meaningful insight and what they say is by the very technical of all interpretations is correct, I absolutely disagree with these statements. What they mean to say is that simply changing the default SSH port isn’t alone I means of strictly protecting yourself. Meaning you shouldn’t change the default SSH port and think that your server is secured because it’s not.

            Quite the different interpretation than me saying it should be mandatorily a part of your security strategy.

            In protecting yourself against port scanning is trivial.

            Anyone underestimating the power of changing The default SSH port is someone who’s opinion I can safely disregard.

      • irmadlad@lemmy.worldEnglish
        0·
        12 days ago

        My two cents: Using a nonstandard ssh port is good for dumping bots. True, you can easily do a port scan against a server and easily find all open ports nbd. But most off-the-shelf bots are looking for standard ports to penetrate. I know that when I format and reinstall the test server, as soon as I change the ssh port, bot noise goes down significantly. So, for a simple config edit and about 2 minutes of time, it seems worth the effort. It’s just one layer tho. And yes, it goes without saying to pick a port other than 22, 222, 2222, etc.

          • sugar_in_your_tea@sh.itjust.worksEnglish
            0·
            11 days ago

            Oh, that one’s fine. Everyone knows that 5-digit ports add extra security, which is why WireGuard runs on port 51820 by default. You can verify this by checking the max port number, which is also 5-digits, computers just aren’t powerful enough to crack 6-digit port numbers, so Linux hasn’t bothered increasing it. /s

      • cmnybo@discuss.tchncs.deEnglish
        0·
        12 days ago

        It gets rid of most of the login attempts for me. I don’t use a popular port though. Pick a 5 digit port so they have to put in some effort to find it.

      • friend_of_satan@lemmy.worldEnglish
        0·
        12 days ago

        My experience running several ssh servers on uncommon nonstandard ports for over 10 years has been that it has eliminated all ssh brute forcing. I don’t even bother with fail2ban. I probably should though, just in case.

        Also, PSA: if you use fail2ban, don’t try tab completing rsync commands without using controlmaster or you will lock yourself out.

          • sugar_in_your_tea@sh.itjust.worksEnglish
            0·
            12 days ago

            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.

            • ILaughBecauseFunny@feddit.dkEnglish
              0·
              12 days ago

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

  • surph_ninja@lemmy.worldEnglish
    0·
    12 days ago

    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.

    The other commenter’s suggestion of fail2ban is also solid.