this post was submitted on 06 Apr 2025
125 points (98.4% liked)

Selfhosted

45553 readers
1122 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
 

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 are viewing a single comment's thread
view the rest of the comments
[–] troed@fedia.io 5 points 1 day ago (1 children)

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

[–] Voroxpete@sh.itjust.works -5 points 1 day ago (2 children)

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

[–] callcc@lemmy.world 4 points 1 day ago (1 children)

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

[–] Voroxpete@sh.itjust.works -2 points 1 day ago (3 children)

A lot of things are "fine", but the cost of adding Netbird to your VPS is effectively zero, whether counted in dollars, time, or convenience.

Given the massive security benefits of using a VPN, and the lack of any meaningful downside to doing so, you'd be an idiot not to.

[–] callcc@lemmy.world 1 points 11 hours ago (1 children)

I don't agree about the point concerning cost. You have additional training, update, maintenance and config burden. This on top of the burdon of using the VPN on top of ssh.

[–] Voroxpete@sh.itjust.works 1 points 9 hours ago

This is the selfhosted community; Who are you training? In most cases there's literally only one person who would ever need SSH access to this server. Maybe two or three in a tiny handful of cases, but anyone who can't figure out Netbird in 30 seconds absolutely should not be accessing anything via SSH.

And you've clearly never used Netbird, Tailscale, or any similar service, if you think that update, maintenance and config constitute any kind of meaningful burden, especially for something as simple as remote access to a VPS.

[–] moonpiedumplings@programming.dev 3 points 1 day ago (1 children)

This is moving the goal posts. You went from "ssh is not fine to expose" to "VPN's add security". While the second is true, it's not what was being argued.

Never expose your SSH port on the public web,

Linux was designed as a multi user system. My college, Cal State Northridge, has an ssh server you can connect to, and put your site up. Many colleges continue to have a similar setup, and by putting stuff in your homedir you can have a website at no cost.

There are plenty of usecases which involve exposing ssh to the public internet.

And when it comes to raw vulnerabilities, ssh has had vastly less than stuff like apache httpd, which powers wordpress sites everywhere but has had so many path traversal and RCE vulns over the years.

[–] Voroxpete@sh.itjust.works 0 points 1 day ago (1 children)

We're in selfhosted. If you have to bring up use cases that are in no way relevant to 99% of self hosters to justify your argument, you don't have an argument.

[–] moonpiedumplings@programming.dev 3 points 1 day ago* (last edited 1 day ago)

Again, this is distracting from the original argument to make some kind of tertiary argument unrelated to the original one: Is ssh secure to expose to the internet?

You said no. That is the argument being contested.

[–] callcc@lemmy.world 1 points 1 day ago (2 children)

And why exactly is that more secure?

[–] suicidaleggroll@lemm.ee 5 points 1 day ago* (last edited 1 day ago)

Main reason is that if you don't already have the right key, VPN doesn't even respond, it's just a black hole where all packets get dropped. SSH on the other hand will respond whether or not you have a password or a key, which lets the attacker know that there's something there listening.

That's not to say SSH is insecure, I think it's fine to expose once you take some basic steps to lock it down, just answering the question.

[–] sugar_in_your_tea@sh.itjust.works 4 points 1 day ago (1 children)

I don't know about Netbird specifically, but adding a VPN does a few things:

  • a port scan of your VPS/router won't show an SSH or VPN port active - Wireguard only acknowledges packets if your key is valid (massively more useful than just changing the port)
  • compromising both a VPN and SSH is difficult, you'd have to chain exploits together
  • if your VPN is hosted by a separate service (e.g. something like Tailscale), it will be very unlikely to share vulnerabilities with your hosted SSH server
[–] callcc@lemmy.world 1 points 11 hours ago (1 children)

Ok, fair point. But why stop at one vpn? I choose to trust OpenSSH, but I agree that adding a secondary layer of security actually helps here. You basically multiply two very low probabilities to get an even lower one. The trade-off is that you add complexity. You now need to keep two services up to date, and correctly configured and access/key material distributed.

I'd only recommend this setup for projects with special security requirements.

why stop at one vpn

Because an additional one adds a different type of security unrelated to securing your server, it's about securing data en route to your server (e.g. hiding that you're accessing it at all from wherever you are. Maybe you want that, but it's irrelevant to securing your server.

But on the larger topic of diminishing returns, yeah, maybe you don't need it.

However, I would never feel comfortable with just one line of defense, regardless of how good that product is. I trust openSSH, which is why I have it running, but all software has bugs and I want more than domino that needs to fall before I get pwned. If there's a successful attack on openSSH, you can bet the script kiddies will exploit it before you get around to patching your server, especially in a homelab setup.

This setup isn't particularly crazy, and I'd recommend a lot more of someone has special requirements. Setting up WireGuard is like 20 lines of config, it's baked into the kernel (except wg-quick, the frontend), and the project is super stable (no major changes in years). Pretty much everything has great support for it (built-in to Android, Linux DEs, etc), and you really don't need to touch it unless you need to set up a new machine.

But if you don't want a VPN for whatever reason, there are other options for additional security:

  • geoip blocking - allow only those regions that you expect to connect from (different rules for each port, so SSH can be special)
  • fail2ban - block IPs if they fail to authenticate after a few attempts

But please do more than just securing openSSH, because all software has bugs and an extra layer isn't that much more work.

[–] troed@fedia.io 2 points 1 day ago (1 children)

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

[–] Voroxpete@sh.itjust.works 0 points 1 day ago

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