Selfhosted
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:
-
Be civil.
-
No spam.
-
Posts are to be related to self-hosting.
-
Don't duplicate the full text of your blog or readme if you're providing a link.
-
Submission headline should match the article title.
-
No trolling.
-
Promotion posts require active participation, with an account that is at least 30 days old. F/LOSS without a paywall has exceptions, with requirements. See the rules link for details. Tags [CBH] or [AIP] are required, see the links in Rule 8 for details.
-
AI-related discussions and AI-involved promotional posts have additional requirements for tagging, as noted in Rule 7 and the AI & Promotional Post Expanded Rules post, and find example disclosures here.
Resources:
- selfh.st Newsletter and index of selfhosted software and apps
- awesome-selfhosted software
- awesome-sysadmin resources
- Self-Hosted Podcast from Jupiter Broadcasting
Any issues on the community? Report it using the report flag.
Questions? DM the mods!
view the rest of the comments
why don't you want to open an ssh port? what's wrong with that?
just disable password authentication, and maybe get fail2ban. am i missing something?
Optional extra, which I do: Change the SSH port to something non-standard. It's not more secure, but it does cut down on the logspam.
I'd argue it's even more secure, as it reduces the amount of attacks you are exposed to. For targeted attacks it changes absolutely nothing. But it keeps you our of a few DBs and spares some brute force attacks.
Essentially, log spam… But also an irrational fear of a security breach.
IMO ssh is the tool you're describing. My ssh server is exposed to the WAN and is configured like this:
PasswordAuthentication noPermitRootLogin nowhy no root login? how do you become root if you need it?
rootis a user account that has all privileges and is what bots are programmed to probe, so exposing it introduces unnecessary risk. IMO there's no reason to permit root login via ssh in any circumstance, ever, in all cases, absolutely.For all the people thinking, "well the world doesn't work in absolutes, there's always a special case!" There isn't.
If a user needs to use elevated permissions, there are many ways to do that without exposing root. sudo(8) is one way to do that.
Thanks for the great explanation! Seems like because logging in as root is never necessary and indeed never done; people confuse sudoer for root login.
do you use sudo with a password? this and the unknown username is what get as additional security then?
Without root user login, the attacker would have to guess not only the password to the user but also the username (hopefully it's not something simple like admin), and once you are logged in you can use sudo -i to chage into root, which will require a password, therefore, we also disable password login so if someone does manage to somehow compromise the SSH user, they'd still need the password to become root.
what password? shouldn't we all use ssh-keys by now?
Did you read it to the end?
sudo -iis what I would do orsu rootif your other user is not a superuser.You could spin a publicly exposed WireGuard daemon firewalled to allow peers access to the non-public SSH port only, which would result in double encryption, but would give you the peace of mind that an attacker would have to compromise both at the same time, which is very unlikely. Plus, WireGuard is very cheap to deploy and produces no logs. We use that model in my office to access our server.
Edit: Otherwise, as others mentioned, you'd move the SSH daemon to a random port, disable password login and weaker keys and cyphers, setup Fail2ban, and optionally setup GeoIP blocking (only allow IPs from your region to connect).