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?
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.
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.
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.
If connecting via the same network or IPs, restrict the SSH open port to only the IPs you trust.
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.
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.
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
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.
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)
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
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.
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.
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.
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.
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.
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).
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.
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.
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.
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.
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.