OpenSSH (8)

My first step to setting up most Internet servers is to shut down every listening service except for sshd.

The second step is to lock down sshd.

Preparation

1. You will want a public-private keypair. I currently use 4096-bit keys and require them for my users, but may move to 8192-bits. This may seem excessive, but the resources involved are trivial. Regardless, you should have this beforehand. See Generating an RSA Key Pair for instructions.
2. Shut every listening service down, save for ssh if you are talking over it.
3. Make sure your chosen administrative/wheel user is has your public key in their ~/.ssh/authorized_keys
4. Make sure the address you are binding ssh to is bound in /etc/network/interfaces
5. If you don't have some sort of remote kvm access to your server, chances are you will want to make a watchdog script relatively soon.

#!/bin/sh
run=`ps x | grep "/usr/sbin/sshd" | grep -v grep | cut -c1-5 | paste -s -` 
if [ "$run" ];
  then
    continue
  else
    /usr/bin/systemctl start ssh
fi

And add:

*/2  *       *       *       *       root       /root/watchdog.ssh.sh

to a file in /etc/cron.d/ (I use /etc/cron.d/watchdog for my watchdog crons).

You will especially want this sort of watchdog if you are binding to a specific port as specific ips can take time to bind.

If you are one of those people who insists on using ifconfig, and your server has a lot of ips assigned, this step may be mandatory if interfaces take their sweet time getting up.

/etc/ssh/sshd_config

1. Choose a non-standard port. I recommend using the same number for all of your servers. This is less for security, per se, but rather to help keep log clutter down as brute force attacks pollute your auth logs. If you use the same number often enough, you will eventually memorize it.
2. Listen to only a single IP address. If you have true IPv6 connectivity, consider only talking only through IPv6.
3. PermitRootLogin no
4. PubkeyAuthentication yes
5. PasswordAuthentication no
   1. Leaving this on until you copy your key over is generally fine. Unless you are horrible at picking passwords.
6. X11Forwarding no
   1. None of my servers run X. If yours does (and you want it to), go ahead.
7. UsePAM no
   1. Just vanilla ssh, please.
8. AllowGroups adminuser backupuser website
   1. Restrict ssh logins by group
9. If you are going to have other people signing in, you may want to give them chrooted sftp access only. You can do this by placing blocks at the end of this file, a la

Match Group backupuser 
       ChrootDirectory /path/to/backupdir
       X11Forwarding no
       AllowTcpForwarding no
       PermitTTY no
       ForceCommand internal-sftp
Match Group website
       ChrootDirectory %h
       X11Forwarding no
       AllowTcpForwarding no
       PermitTTY no
       ForceCommand internal-sftp

To keep them from snooping, or somehow making a mess. It's also just good policy for any account that doesn't need it.

For this you will of course want a dedicated website group:

addgroup --gid 74 website

Debian Buster

Initial: Designing a Server - IPMI Installation - Second Steps

---

Core: Network - OpenSSH - Packages - sysctl.conf - Iptables - Security - User Management

---

Stack: Unbound - MariaDB - Nginx - PHP (7)

---

Mail

Mail Setup - Mail Tables - OpenDKIM - Mail and DNS - Spamassassin - ClamAV - Postfix - Dovecot - Reputation Management

---

Logs and Security: RKHunter - Logging - Logcheck - Backups - AppArmor