Especially when writing a tutorial for beginners - please use the long-form flags (e.g. sudo usermod --append --groups sudo newuser) instead of short-form flags (e.g. sudo usermod -aG sudo newuser). Short-form flags make commands look like arcane voodoo magic. They make sense only to help you save time entering commands if you know them by heart already. Tutorials are read by beginners who are not necessarily familiar with the commands in the first place - long-form flags help communicate what these commands are actually doing and thus make for a more effective tutorial.
I recommend checking out Caddy <<a href="https://caddyserver.com/" rel="nofollow">https://caddyserver.com/</a>>, which replaces both Nginx and Certbot in this setup.<p>Tailscale <<a href="https://tailscale.com/" rel="nofollow">https://tailscale.com/</a>> can remove the need to open port 22 to the world, but I wouldn't rely on it unless your VPS provider has a way to access the server console in case of configuration mistakes.
I'd switch to Userify if you have a team to distribute keys for, because it's ultra-lightweight and also keeps you from messing up permissions on the ssh key/directory, which I've done too many times! (also it does sudo which is quite nice)<p>Also, restarting ssh will not boot you out of the session (your session has already been forked as a different process), so leave your terminal window open (to fix any screwups) and then log in on a separate window on the new port and just make sure you can get in.<p>For backups, don't set up logins from your main server(s) to your backup server; log in from your backup server to your main server. That way, if someone breaks into your main server, they can't get into your backup server.
You may want to update this post to disable password authentication, and thus you'll no longer need to install fail2ban. An important goal is to tighten your attack surface, not expand it. At this point you will still have an exposed SSHd server, so I'd recommend throwing the server under tailscale. You can setup the SSHd listener to use your tailscale IP or setup tailscale for SSH via ACLs (<a href="https://tailscale.com/tailscale-ssh" rel="nofollow">https://tailscale.com/tailscale-ssh</a>).<p>Additionally you can further tighten controls of incoming logins with the use of AllowGroups to tighten your controls on which groups can log into the system. This would mitigate a scenario where an adversary is able to escalate enough privileges to write an .authorized_keys file to a non-privileged user which may have a shell still configured.<p>Finally, unless you're treating this server as a bastion host of sorts, you probably should disable forwarding for agents or X11 etc. We've seen a lot of adversaries move laterally due to this agent forwarding.
At the end of the article, there's a link to a script[1] that does the steps covered in the article.<p>That got me thinking: how do other self-hosters/homelabbers here go about automating their server setups? None/purely manual? One big shell script? Multiple scripts wrapped in a Makefile (or justfile, or other command runner)? More enterprisey provisioning/automation tools like Ansible, Puppet, etc.?<p>[1] <a href="https://git.sovbit.dev/Enki/sovran-scripts" rel="nofollow">https://git.sovbit.dev/Enki/sovran-scripts</a>
> Differential backups back up all the changes since the last full backup (...) An incremental backup backs up data that was changed since the last backup<p>I'm not sure I understand the distinction?
So... about docker, did they backtrack on their licensing landgrab?<p>About a year ago I swear everyone was going to podman, but in the last few months I see nothing but docker references.<p>Podman is supposed to be drop-in. Well, it was advertised. I haven't touched anything in six months.
> You want to use SSH (Secure Shell) and make sure that SSH is the only way to log in.<p>Some distributions (like openSuSE) also enable KbdInteractiveAuthentication by default so just disabling PasswordAuthentication won't work.
And for those of you that don't have an external IP, you can use services that provide egress for you like IPv6.rs. [1]<p>[1] I'm DevOps there! ;)
Here are some "First Things on a Server" Notes.
<a href="https://gist.github.com/klaushardt/07f5e3068355aafc2dce660a54be1ea7" rel="nofollow">https://gist.github.com/klaushardt/07f5e3068355aafc2dce660a5...</a><p>Ansible/Puppet or NixOS would be better, but this is what works in Self Hosting.
Hey I just want to say thank you for the write up. I just got into the hobby of self hosting my own applications and it's quite a bit. I appreciated your sections about logging and user management.
While these seems to be secure... tampering with default settings always cause PITA; especially during automated upgrades. In addition, ssh port changes are all security thru obscurity.
Why the `sudo ufw allow outgoing`? Wouldn't it be worth to deny all to prevent extrusion and only open ports for services that need to communicate externally?
A monitoring setup with for instance Prometheus+Grafana would be a great addition to this.<p>And then maybe automating all of it with something like Ansible.
With SSH Keys, do you have to just carry around your private key everywhere on a usb or something if you want to connect from multiple locations? Sometimes I find myself somewhere I've never been and I want to connect to my server. With a password that's easy, I just type it in, but I can't exactly create a new private key to access the server when I don't have access to the server in the first place
Qq, do people doing their own server setup like this use containerization at all?<p>When I looked at it, it was like “yeah you can run Docker or k3s,” and I think Hashicorp had their own version, but it seemed like folks didn't really bother? Also like setting up virtual networks among VPSes seemed like it required advanced wizardry.