Mozilla has some guidelines for SSH which I use: https://infosec.mozilla.org/guidelines/openssh
Only thing I do differently is I use ed25519 instead of RSA.
ssh-keygen -t ed25519 -a 100
this post was submitted on 19 Oct 2023
2 points (100.0% liked)
Self-Hosted Main
502 readers
1 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.
For Example
- Service: Dropbox - Alternative: Nextcloud
- Service: Google Reader - Alternative: Tiny Tiny RSS
- Service: Blogger - Alternative: WordPress
We welcome posts that include suggestions for good self-hosted alternatives to popular online services, how they are better, or how they give back control of your data. Also include hints and tips for less technical readers.
Useful Lists
- Awesome-Selfhosted List of Software
- Awesome-Sysadmin List of Software
founded 1 year ago
MODERATORS
Thanks!
I saw the ed25519 keys sometime ago, but haven’t had time to understand it.
Will look into it and the link!
Same protections as RSA but more efficient cause same strength of security but with shorter length making it fast.
There is Edsa too but since it was developed by NSA, people are skeptic it may have a back door…
Great guide. Agree with disable IPv6, extra unnecessary exposure and firewall effort. Consider Automatic updates, review ports/disable unwanted services.
Automated security updates (unattended updates), netstat -ap --numeric-ports (for process review)
Also consider that debian is the downstream distribution of ubuntu, its usually older but more stable. More stable => less bugs => more secure
Nice work!
Some small pieces of feedback:
- You can disable the root user during installation, by leaving the root password blank. The installer explains this in the text at the top of the page. If you do this, root will be disabled and
sudowill be installed automatically - If you really want to control which users can SSH in, it's recommended to create a group and use
AllowGroups, rather than allowing individual users viaAllowUsers. Note that once you disablePasswordAuthentication, the only users that can SSH in are users that have keys inauthorized_keys, so you don't really need to useAllowUsersorAllowGroups. - Disabling IPv6 is unnecessary. If you don't want to use it, then just... don't use it? You should ideally always have IPv6 enabled for connections to the internet though. It's generally faster due to better routing (see Google's latency impact data: https://www.google.com/intl/en/ipv6/statistics.html#tab=per-country-ipv6-adoption), and more future-proof.
- You may want to consider CrowdSec instead of fail2ban. It's more efficient and they have a shared list of known bad IPs that you can use.
You may want to consider CrowdSec instead of fail2ban. It's more efficient and they have a shared list of known bad IPs that you can use.
interesting, I'll have to check out Crowdsec
Hi Daniel15. Is it recommended to disable the root user for a server during installation as you suggested? Are there never any tasks which must (or should) be executed as root for server setup or maintenance? I just built my first (Debian) server, so quite new to it all. Thanks.
You can do almost everything with sudo. Some thing are easier when done as the root user (such as setting cron jobs that need root permissions), but it should never be a necessity.
If you really do need root user, you can still enable root temporarily and disable it again.
Anything that you absolutely must do as root can be done using sudo -i which will give you a root shell.
Another great article! I'm curious about the reasoning for using Debian on a Pi vs the Pi OS which is based off Debian?
Full disk encryption is my reason. Super easy to do when installing debian from scratch. Big pain in the ass to do with Pi OS (last I googled).
For Raspberry Pi's I prefer DietPi which is Debian based but not full of unnecessary stuff for servers like Pi OS is.
I only use Alpine on Pis so I'm interested to hear why any Debian at all?
Just because I know it and I wanted something with as little bloat as possible.
Tried alpine once, could not get it running.
load more comments
(5 replies)
Nice work!
Some small pieces of feedback:
- use fedora
- or any other rhel derivate
Not helpful... If that is your opinion, then at least put some reasoning behind it...
i'm sorry.
i personnally think, that debian is in a dying state.
your article is very good and helpful. but just things like installing sudo is not very comfortable. any other linux os has it installed from the start.
also your security tips are helpful for any linux os.
How is Debian in a dying state?
Debian just hit 30 years and is still one of the most used Linux distros. It's not.
Fanboism. There are entire data centers (like linode) running Debian under the hood. It's stable and consistent.
Thinks it's in dying state and the guy recommends the distro that's doing it's best to kill itself. What's next, "Why don't you use SCO linux?"
That's not reasoning, that's still just your opinion. Note, if you follow up with a straight up claim that "debian is in a dying state" I'm going to expect evidence to back it up. So keep that in mind should you choose to continue dying on this hill.
Whith the way rhel is l taking. Home use in production is terrible idea
Hm good guide but some things like UFW are totally unnecessary for most users. See https://youtu.be/fKuqYQdqRIs?feature=shared&t=798
Personally I disagree. You might be running internal services you do not want to expose. It also is an active step to expose something. This way you are in control what is exposed and what isn’t.
Yeah until you realize that e.g. docker compose doesn’t care about ufw rules and expose defined ports anyway (yes, through the firewall) and now you can argue that an inexperienced user doesn’t know this and thinks that the ufw will protect him and give him a false sense of security. You should always make sure to bind internal services to 127.0.0.1 only period. Anyway that doesn’t mean ufw is useless, but that it should only be used for filtering more than the default port allow rules because like this you have no security advantage (e.g. I use ufw on my Proxmox servers to block outgoing connection to the lan by default and then explicitly allow connection to server x if needed )
PermitRootLogin I would set to yes.
sudo systemctl restart ssh will only restart your ssh client and not the ssh server you try to restart. Use sshd insted.
I personally find it easier to use no root during setup and import my ssh keys from github using ssh-import-id.
UFW doesn't harm, but if the host is on your Proxmox Hypervisor, it is probably behind a deny all incoming firewall anyway. That is also why I would leave IPv6 on.
Like other have noted, Crowdsec is a little bit more complex to setup but also offers more features. As a side note, Fail2ban is unfortunatly not IPv6 ready.
Thanks for the advice!
Why would you leave PermitRootLogin to yes? Doesn’t really matter, if root ca nit login anyways?!
You are right on restarting sshd. That’s a typo…
An other user also mentioned to not fill out the root password and it will disable root + install sudo. Guess I didn’t read the instructions properly. Will definable be adopted.
I agree on importing from Github, but I am unsure how many people have their keys there…
UFW on a virtual machine might not be needed, but also not really harmful. I do like having in on every machine for piece of mind. Also this guide can be used for bare metal installs.
Crowdsec is on the todo list!
Thanks again. I will keep updating my article 😊
Why would you leave PermitRootLogin to yes? Doesn’t really matter, if root ca nit login anyways?!
Just like you don't really need UFW, not really harmful and for piece of mind :)
But to be honest, I am no expert either. I look at your config and think, just leave everything at default besides these twos:
PubkeyAuthentication yes PasswordAuthentication no
Things like
MaxAuthTries 3
don't matter for public key auth.
Yeah and I went through it with thinking, let’s make it as secure as possible without 100% knowing the effect…
You need password auth for copying your key, don’t you. Unless you import it during the install…
i might format my raspberry pi with the new raspbian OS. will definetly try this one out thanks
Installing fail2ban and not configuring it is as good as not installing the program in the first place.
Include unattended-upgrades with configuration for security updates. This is essential to any actively accessible server.
This is fire, love it!
u/KillerTic thanks for continuing to provide great write-ups.
view more: next ›