@ed11s8c

On #8, that's more security through obscurity (or by obscurity). It's really simple to do a port scan that will provide an attacker with any/all open ports.

Even if you change the default SSH from port 22 to another, it wouldn't take long for someone to use Kali Linux and locate which port is open (mentioning KL as it's super-easy to setup). If someone has a tool locally, they don't even need KL (KL just provides all the tools in one distro).

My recommendation would be to setup a VPN, white list the VPN IP (since it's static) and only allow SSH connections from that IP (or X number of IP's you require). With this type of setup, connections to the SSH port will be denied if they aren't from the white listed IP(s).

...

While on the topic of SSH, I would recommend either a 4096 or 8192 bit key, if using RSA. Otherwise, use ED25519 keys. Either way, always use a passphrase and make sure you use a decent number of KDF rounds when creating the key.

...

For example, to generate a 4096 bit RSA key, we could use:

ssh-keygen -a 1000 -b 4096 -C "" -o -t rsa

-a specifies # of KDF rounds
-b specifies the bit size for RSA keys
-C removes the common comment at the end of the key
-o specifies that we should use the new format provided by OpenSSH
-t specifies the key type (RSA)

...

For an ED25519 key, we'd use:

ssh-keygen -a 1000 -C "" -o -t ed25519

ED25519 keys don't accept (i.e. they ignore) the bit size, so we don't need to pass that in as we do when generating an RSA key.

...

As for which is more secure -- it all depends. The likelihood of someone breaking a 4096 bit RSA key with a decent passphrase is very very slim. The same for the ED25519 key above.

Just make sure you're not using an insecure passphrase.

...

That said, I wouldn't recommend going much higher than 1000 on the rounds as the above keys will take about 8-12 seconds to generate. The more rounds, the longer it'll take -- 20000 rounds took me about 3-5 minutes.

The time it takes to generate will also be the time it takes for you to login when passing your key to the ssh command. So the more KDF rounds, the longer it'll take for you to authenticate.

...

On #15, unless you're legally required to display some sort of legal message to those accessing your server(s), it does little more than throw a message when someone tries to login.

No attacker is going to read it if they are trying to connect manually -- on remote or automated attacks, they'll never even see it.

...

The rest of it is a pretty standard setup for a base installation. The next steps would be doing what is required for any/all applications that you host on the server.

@ed11s8c

As a continuation of the previous response, there's actually quite a bit more that can be done as far as SSH, such as tuning:

/etc/ssh/ssh_config

and

/etc/ssh/sshd_config

.. beyond disabling password authentication and enforcing SSH Keys.

...

Generally what I recommend only enabling RSA and ED25519 Host Keys. By default, SSH will use all four keys -- RSA, DSA, ED25119, and ECDSA. in sshd_config, you'll see:

HostKey /etc/ssh/ssh_host_rsa_key
HostKey /etc/ssh/ssh_host_dsa_key
HostKey /etc/ssh/ssh_host_ecdsa_key
HostKey /etc/ssh/ssh_host_ed25519_key

I'd recommend stripping away the DSA and ECDSA keys unless you know you'll need them. With the lines removed, we'd only have two HostKey lines, like so:

HostKey /etc/ssh/ssh_host_rsa_key
HostKey /etc/ssh/ssh_host_ed25519_key

Don't restart SSH just yet.

You'd then want to regenerate the keys. In most cases, and I'm not 100% sure if this is the case with DigitalOcean (I've not asked), the same keys are used for every deployment since most cloud providers use the same image and don't run a script to regenerate them. That means you could be using the same keys as another Droplet. Even if you're not, I prefer to regenerate them on my own.

To regenerate, we can do something as simple as first removing the existing keys:

rm -v /etc/ssh/ssh_host_*

That'll give you a verbose output and tell you what files were removed. We're removing them all, and will regenerate them using:

ssh-keygen -q -N "" -C "" -t rsa -b 4096 -f /etc/ssh/ssh_host_rsa_key

and

ssh-keygen -q -N "" -C "" -o -a 20000 -t ed25519 -f /etc/ssh/ssh_host_ed25519_key

Also, within sshd_config, it's generally idea to specify MACs, Ciphers, and Kex algos. They aren't set by default, but we can set them by adding:

KexAlgorithms curve25519-sha256@libssh.org,diffie-hellman-group-exchange-sha256

Ciphers chacha20-poly1305@openssh.com,aes256-gcm@openssh.com,aes128-gcm@openssh.com,aes256-ctr,aes192-ctr,aes128-ctr

MACs hmac-sha2-512-etm@openssh.com,hmac-sha2-256-etm@openssh.com,hmac-ripemd160-etm@openssh.com,umac-128-etm@openssh.com,hmac-sha2-512,hmac-sha2-256,hmac-ripemd160,umac-128@openssh.com

We can also completely disable password authentication using both:

PasswordAuthentication no

and

ChallengeResponseAuthentication no

You can restart SSH now using service ssh restart.

...

Beyond the above, I would recommend looking at Lynis -- an auditing tool. Some things you won't be able to modify with DigitalOcean -- the same or many cloud providers. Others are recommendations, while some are what I would call requirements. It's pretty detailed.

https://cisofy.com/lynis/