this post was submitted on 03 Aug 2025
112 points (88.4% liked)

Selfhosted

50135 readers
478 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
top 24 comments
sorted by: hot top controversial new old
[–] truthfultemporarily@feddit.org 42 points 1 day ago (3 children)

This is mostly nonsense.

  • Why block outgoing? Its just going to cause issues for most people. If you're going to do that, do it centrally (hw firewall)
  • Why allow http and NTP incoming, when there is no http / NTP server running.
  • If there is http server running no mention of https://ssl-config.mozilla.org/ and modsecurity
  • If you're using ufw anyway why not go with applications instead of ports?
  • In a modern distro, the defaults are usually sane (maybe except TCP), most of the stuff in the SSH config is already default.
  • Why change the SSH port of a home server, which most likely is not reachable from the outside anyway?
  • Actually potentially impactful stuff like disabling services you don't need, such as cups, is not mentioned
  • unattended-upgrades not mentioned
  • SELinux / AppArmor not mentioned
  • LKRG not mentioned https://lkrg.org/
  • Fail2ban not mentioned

Don't just copy random config from the internet, as annoying as it is, read the docs.

[–] Mordikan@kbin.earth 4 points 1 day ago

But you need that legal banner in case your spouse acts up and you need to throw their ass in prison.

[–] uranibaba@lemmy.world 3 points 1 day ago (1 children)

Why change the SSH port of a home server, which most likely is not reachable from the outside anyway?

And if it is, why change it on the server and not in the fw?

[–] truthfultemporarily@feddit.org 0 points 1 day ago (1 children)

If you change it, definitely change it on the server so it shows up in netstat and is consistent.

[–] uranibaba@lemmy.world 1 points 23 hours ago (1 children)

I mean keep using port 22 on the server and redirect whatever port you want in your firewall (your router unless you have a dedicted fw) to port 22. Don't change the ssh port on the server at all.

[–] truthfultemporarily@feddit.org 1 points 23 hours ago

I understand this, but this is inconsistent behavior. You now use 22 inside your network and something else outside. Whenever you create inconsistent behavior, everyone using it has to have an awareness of all these inconsistent behaviors.

Also, it is hard to troubleshoot because the tool most admins would want to use (netstat) will not give you useful information to understand the situation.

[–] RubberElectrons@lemmy.world 1 points 1 day ago

Til about lkrg.

[–] tiramichu@sh.itjust.works 22 points 1 day ago* (last edited 1 day ago)

This is a nice list, but for the novices it's obviously meant for, it's a bad learning experience.

Why? Because it doesn't explain any of the reasoning behind what it asks you to do.

Why are we changing the default SSH port, for example? Someone who is seasoned might identify this is a somewhat limited attempt to obscure our attack surface, but to a novice it's inscrutable and meaningless.

More important than telling people what to do is explaining why, because it puts the learning in context and makes it stick by giving a reason to care.

[–] Goodeye8@piefed.social 32 points 2 days ago

Shamelessly plugging https://linuxupskillchallenge.org/ because if you're going to set up an Ubuntu home server you might a well know how to use it.

[–] emhl@feddit.org 17 points 2 days ago (2 children)

Running SSH on a non-provileged port brings new issues. And using 2222 doesn't bring any meaningful security by obscurity advantages.

The rest of the options look nice. It would have if there would be explanations on what the options do in the example configs

[–] Arigion@feddit.org 9 points 2 days ago* (last edited 2 days ago)

Just use wireguard as VPN and bind ssh only to that interface. You loose public access but I couldn't think of a reason why I want other devices than my own to connect anyway. You have to make sure that ssh starts after wireguard though or it can't bind the port.

[–] johannes@lemmy.jhjacobs.nl 9 points 2 days ago (2 children)

Which issues are you referring to?

Using port 2222 may not prevent any real hackers from discovering it, but it sure does prevent a lot of them scripttkiddie attacks that use automated software.

[–] martinb@lemmy.sdf.org 9 points 2 days ago (2 children)

Passwordless login only. No root login. Fail2ban. Add ufw to stop accidental open port shenanigans, and you are locked down enough

[–] Botzo@lemmy.world 3 points 1 day ago* (last edited 1 day ago) (1 children)

We can go harder: port knock to open the port to a cert-only VPN (on top of all that)

https://wiki.archlinux.org/title/Port_knocking

[–] martinb@lemmy.sdf.org 3 points 1 day ago (1 children)

Felt a bit like a faff to me, so I never bothered. Does depend upon your threat model though

[–] Botzo@lemmy.world 1 points 1 day ago

Totally.

Port knocking is one of those "of course someone did that" things to me too. A replay attack is enough to make it security theater.

An IP allowlist is a more useful addon.

[–] StrixUralensis@tarte.nuage-libre.fr 1 points 1 day ago* (last edited 1 day ago) (4 children)

Passwordless login only

Never understood this

I don't think that anyone or anything, computer or mentalist, will guess my 40+ characters long password

[–] non_burglar@lemmy.world 8 points 1 day ago (1 children)

With ssh, over 90% of the vulnerabilities are abusing the password mechanism. If you setup pre-shared keys, you are preventing the most common abuses, including in the realm of zero days.

[–] etchinghillside@reddthat.com 3 points 1 day ago

Are you setting and managing other’s passwords?

The idea behind keys is always, that keys can be rotated. Vast majority of websites to that, you send the password once, then you get a rotating token for auth.

Most people don't do that, but you can sign ssh keys with pki and use that as auth.

Cryptographically speaking, getting your PW onto a system means you have to copy the hash over. Hashing is not encryption. With keys, you are copying over the public key, which is not secret. Especially managing many SSH keys, you can just store them in a repo no problem, really shouldn't do that with password hashes.

[–] surph_ninja@lemmy.world 1 points 1 day ago

Especially paired with Fail2Ban preventing any brute force attempts.

But with a WireGuard setup, you need not have the port exposed at all.

[–] emhl@feddit.org 4 points 1 day ago* (last edited 1 day ago) (1 children)

Privileged ports can be used by processes that are running without root permissions. So if the sshd process would crash or stop for some other reason, any malicious user process could pretend to be the real ssh server without privilege escalation. To be fair this isn't really a concern for single user systems. But setting up fail2ban or only making ssh accessible from a local network or VPN would probably be a more helpful hardenening step

And regarding port 2222 it is the most popular non-provileged port used for SSH according to shodan.io So you ain't gaining much obscurity

[–] Laser@feddit.org 3 points 1 day ago

Privileged ports can be used by processes that are running without root permissions.

I guess you mean unprivileged ports?

So if the sshd process would crash or stop for some other reason, any malicious user process could pretend to be the real ssh server without privilege escalation.

Not really, except on the very first connection because you need access to the root-owned and otherwise inaccessible SSH host key, otherwise you'll get the message a lot of people have probably seen after they reinstalled a system (something like "SOMEONE MIGHT BE DOING SOMETHING VERY NASTY!").