zlacker

>>websku+(OP)
This posts lists inexpensive home servers, Tailscale and Claude Code as the big unlocks.

I actually think Tailscale may be an even bigger deal here than sysadmin help from Claude Code at al.

The biggest reason I had not to run a home server was security: I'm worried that I might fall behind on updates and end up compromised.

Tailscale dramatically reduces this risk, because I can so easily configure it so my own devices can talk to my home server from anywhere in the world without the risk of exposing any ports on it directly to the internet.

Being able to hit my home server directly from my iPhone via a tailnet no matter where in the world my iPhone might be is really cool.

>>simonw+g6
I'd rather expose a Wireguard port and control my keys than introduce a third party like Tailscale.

I am not sure why people are so afraid of exposing ports. I have dozens of ports open on my server including SMTP, IMAP(S), HTTP(S), various game servers and don't see a problem with that. I can't rule out a vulnerability somewhere but services are containerized and/or run as separate UNIX users. It's the way the Internet is meant to work.

>>drnick+ab
It's the way the internet was meant to work but it doesn't make it any easier. Even when everything is in containers/VMs/users, if you don't put a decent amount of additional effort into automatic updates and keeping that context hardened as you tinker with it it's quite annoying when it gets pwned.

There was a popular post less than a month ago about this recently >>46305585

I agree maintaining wireguard is a good compromise. It may not be "the way the internet was intended to work" but it lets you keep something which feels very close without relying on a 3rd party or exposing everything directly. On top of that, it's really not any more work than Tailscale to maintain.

>>zamada+zo
I just run an SSH server and forward local ports through that as needed. Simple (at least to me).

>>SoftTa+mp
How many random people do you have hitting port 22 on a given day?

>>Rebelg+0V
change port.

>>gsich+8k1
After years of cargo-culting this advice—"run ssh on a nonstandard port"—I gave up and reverted to 22 because ssh being on nonstandard ports didn't change the volume of access attempts in the slightest. It was thousands per day on port 22, and thousands per day on port anything-else-i-changed-it-to.

It's worth an assessment of what you _think_ running ssh on a nonstandard port protects you against, and what it's actually doing. It won't stop anything other than the lightest and most casual script-based shotgun attacks, and it won't help you if someone is attempting to exploit an actual-for-real vuln in the ssh authentication or login process. And although I'm aware the plural of "anecdote" isn't "data," it sure as hell didn't reduce the volume of login attempts.

Public key-only auth + strict allowlists will do a lot more for your security posture. If you feel like ssh is using enough CPU rejecting bad login attempts to actually make you notice, stick it behind wireguard or set up port-knocking.

And sure, put it on a nonstandard port, if it makes you feel better. But it doesn't really do much, and anyone hitting your host up with censys.io or any other assessment tool will see your nonstandard ssh port instantly.

>>lee_ar+2N1
Conversely, what do you gain by using a standard port?

Now, I do agree a non-standard port is not a security tool, but it doesn't hurt running a random high-number port.

>>wasmit+LT1
> Conversely, what do you gain by using a standard port?

One less setup step in the runbook, one less thing to remember. But I agree, it doesn't hurt! It just doesn't really help, either.