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!
You must log in or register to comment.
There’s a dedicated tool named sshguard which works nicely.
I generally do a few things to protect SSH:
- Disable password login and use keys only
- Install and configure Fail2Ban
- 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.
I vote for wireguard here, I don’t expose anything other than game servers to the internet
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?
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
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.
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.
Regarding SSH Keys, I was wondering how you keep your key safe and potentially usable from another client?
Generate a unique key for each client or device. SSH keys identify devices, not people, so I do not recommend sharing the same key between two different devices.
Well, you might have only 1 main client, but if that hardware fails and need to connect from a temporary client or after a fresh install you’re out of your own server…
You could get a hardware key (like a Yubikey) and authenticate with PIV or GPG.
Be sure to use a passphrase
Or very strong password
For added funs run an SSH tarpit to fuck with the attackers, something like endlessh.
Well yeah, sure, but that doesn’t really add to your security and it only costs you work and resources
100% agree, that is a “totally for fun” exercise
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
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.
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.
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.
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:
- key-only login, root login completely disabled
- solid root password, and user privilege separation (have each service use its own user)
- 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
- fail2ban - especially if you have a relatively large whitelist
- 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.
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.
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.
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)
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.
iptablesoperates 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:
- block obviously bad packets at the firewall level
- eliminate insecure modes of login (only allow key-based login)
- something like fail2ban to ban the few who make it through 1 & 2
- use a secure root password so if someone does get in, they’re less likely to get root access
- 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).
Still no. Here’s the reasoning: A well known SSHd is the most secure codebase you’ll find out there. With key-based login only, it’s not possible to brute force entry. Thus, changing port or running fail2ban doesn’t add anything to the security of your system, it just gets rid of bot login log entries and some - very minimal - resource usage.
If there’s a public SSHd exploit out, attackers will portscan and and find your SSHd anyway. If there’s a 0-day out it’s the same.
(your points 4 and 5 are outside the scope of the SSH discussion)
It’s also one of the biggest targets for attack. Here’s a somewhat recent CVE and here is another. Staying on top of security patches is absolutely critical, and many don’t do that.
The best security practice is to layer your protections.
your points 4 and 5 are outside the scope of the SSH discussion
They’re not about SSH, sure, but they are relevant to securing a system to remote access. Always assume your security infra will be compromised and plan accordingly. Generally speaking, the more layers, the better.
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.
Configure the firewall with a IP whitelist to only allow connections to ssh be made from your home IP.
Other then that, disable password logon for ssh and setup up key based authentication.
Agreed, but be careful about the whitelist. If your home IP changes, you’ll be locked out until you update it, so you should consider an IP range if that’s a possibility for you. Likewise, if you’ll be accessing it from multiple locations (say, a family member’s house), then make sure to add those as well.
- harden sshd
- use fail2ban or even better
CrowdStrikeCrowdSec - use a tool like the following to have a next-gen security solution: https://github.com/mrash/fwknop
Your answer to “how to harden SSH?” is “harden SSH”?
I know your two other points gave concrete suggestions, but it’s pretty funny you suggested to “harden sshd” when that is what OP is asking how to do.
Yeah, I see your point. No use to repeat the same you can read in other comments or in those 274772 guides online. I was trying to imply to just generally harden ssh because then brute-force attempts should be no issue, unless you log everything and the disk space gets maxed out :D
harden sshd
More details:
- require keys to login
- don’t allow login as root
That should be plenty, but you could go a bit further and restrict the types of algorithms allowed (e.g. disallow RSA if you’re worried about quantum attacks). For this, I recommend a subtractive config (e.g.
HostbasedAcceptedAlgorithms=-rsa-*). This is way over the top since an attacker is unlikely to attack the cipher directly, but it could be part of an attack.did you mean crowdsec instead of crowdstrike?
Fml… yes, I meant CrowdSec. Thanks for the hint
Vietnam stare
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.
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.
Fortunately my VPS (oracle) has set SSH authentication to be default. Disallowing root login sounds good, gotta try that as well.
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/
Exactly. No root login and no password login will do just fine as basic measures, but after that Wireguard is perfect tool for this, no weird rituals required and also quite useful for any other services you don’t want and/or need to expose to the internet as well.
Just remember that you’ll only be able to SSH in w/ a device that’s already configured for WireGuard. So if you’re at a friend’s house and haven’t set up your phone to do it yet, you’ll be forced to use the VPS console to get in. Make sure this is what you want before you do it.
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…
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.
