All new Registrations are manually reviewed and approved, so a short delay after registration may occur before your account becomes active.
Steps to setup new server to feel ok leaving it always on?
user3028938
Member
I have a debian server and followed most of what is written in this article.
I also did the usual ufw allow ssh and default deny as per the archwiki basic setup recommendation.
Is that enough?
I have been shy to leave it on all the time when not in use and find myself switching it off between sessions.
It is not hosting anything always on so there is no cause to have it on all the time except for convenience to not have to go through all the steps to boot it via the customer dashboard each time.
With the above in mind is it possible to just have a bash script to boot the server each time I want to use it? I am guessing unless the specific seller has an api then that would not be possible since you only get access via the command line through ssh right and so no ssh if the server isn't on! The seller is a small company so I guess they wouldn't have such special functionality. I sent a ticket asking about that but got no reply.
Is it an x-y issue? Please give your thoughts.
It does seem wasteful to have it in an always on state if I am not using it or running any automated scripts while it is unattended. So booting just for the session does seem more economical that way and circumvents unnecessary security concerns whether salient or not.
Comments
Assuming you're using SSH keys, (not passwords), and you've disabled the root user login you should be mostly good.
It's usually a good idea to use a non-standard SSH port, (i.e. not 22 or 2222), to reduce the number of scanning bots interfering with your server, but they're looking for soft targets and usually quit when password authentication is disabled.
You should probably also install CrowdSec, which will identify and block SSH brute force attempts, but usually exposed SSH ports aren't something to worry about: https://docs.crowdsec.net/docs/intro/
Thanks, was just checking there weren't any glaring holes.
i don't think openssh advertises which auth methods are enabled, just gives a generic authentication failed error. in my experience bots don't quit even if password auth is disabled, not like any of them will go through though, and a few kbps of unwanted traffic is not a big deal
I'd go with openbsd, linux is ... let's say - very targeted.
What other services are running ?
My noob practice on this, just sharing and welcome feedback:
Are there any advantages to use crowdsec instead of fail2ban? I'm currently had fail2ban protecting my VPS. It's my first time tht I heard of crowdsec.
Sir, I'm telling perplexity to do the comparison, will get back to you with the result lol
Edit: this is what Perplexity said: https://www.perplexity.ai/search/what-s-different-between-crowd-NOwKsHtuRgqIOpQBDGFbZg#0
Yello,
Security wise, you're pretty much mostly covered if you disabled root login, setup ssh key auth, changed the SSH port, and used UFW for basic firewall rules, then running unattended-upgrades or the equivalent to that.
I would suggest adding fail2ban or crowdsec, crowdsec as someone else suggested, has a broader community based blocklist, but its a bit more complex if you're just starting out.
For monitoring, netdata, or uptime-kuma are very helpful so you can track analytics and the usage.
If your provider's not responsive and you're stuck toggling power manually, it may be worth switching to one that offers API or hardware-based remote reboot. That's exactly what we offer our clients at ServerCrate to avoid that kind of friction between boots.
End of the day, don't stress about leaving the server running. With proper hardening and monitoring, always-on isn't risky. It's just about whether the uptime is worth the power/cost for your case.
I buy and not even login to virtfusion to build the os.
I mean, there's a little chance of someone hack it, but ... like @raindog308 once said in his over 20-years, hasn't been a little incident ever, me either. Hasn't been compromised ever since, with either plain text root pw and/or SSH keys.