The following is a list of things that can, and probably should, be done in order to secure an OpenSSH server. This list isn’t necessarily complete, but what is here can significantly improve the server’s defenses against attackers.
Before changing the OpenSSH configuration file I’ve found it’s a good idea to make a copy of the original (as with just about any configuration file). The examples assume a Debian or Debian based server; and most, if not all, of the following commands will require root privileges.

cp /etc/ssh/sshd_config /etc/ssh/sshd_config.orig

Disallow Root Log in

The first thing that should be done is to disallow remote login as the root user. This is important enough that on many distributions this is restricted by default. Every Unix-like operating system has a root user and that user has full system privileges. A port scan will reveal the OpenSSH server’s open port (by default port 22), and if the root user can login remotely using a password, an attacker would already have one part of the two pieces of information needed to gain full remote access to the system — the user name (root) portion of the user name & password combination.

Depending on the strength of the other piece of information (needed to gain root access to the system), the password, it’s only a matter of time before an attacker has both — assuming a brute-force approach. They would just need to keep trying to log in as root with a different password until they found the correct one.

By default, the server is configured to allow 6 authentication attempts per session ( configurable with the MaxAuthTries configuration directive), which will slow cracking efforts substantially, but it would still be just a matter of time before the entire system is compromised.

To disallow root log in, open the /etc/ssh/sshd_config (or wherever in resides on your system) and set the PermitRootLogin configuration to ‘no’. If the directive isn’t in the configuration file then it’s set to ‘yes’ by default (allowing root log in with a password). Just add it to the configuration file and set it to ‘no’.

Restrict User Access

So now our OpenSSH server is serving connections (at port 22) to any user of the system except root. To tighten this up, we can restrict access to specific users or groups with the AllowUsers and AllowGroups configuration directives. If these directives are set, users and/or groups not specifically listed in these directives will not be granted access to the system.

If these options are not already in the configuration file, one can add them directly to the configuration file (/etc/ssh/sshd_config) specifying a list of users or groups. The following is an example.

AllowUsers [user0] [user1] ...

Use Public Key Cryptography for Authentication

With our SSH server only granting access to specified users or groups, and forbidding remote access to root, we can now strengthen the method used to authenticate users. By default, the authentication mechanism is the system user name and password for the user. Many times, one of these two parts are easily known or guessed, that being the user name. If the user name has been determined, then it would only be a matter of time before the password could be cracked (by brute force, as mentioned above).

To protect against this, OpenSSH enables users to authenticate using Public Key Cryptography. I made this post demonstrating how to set this up and use it. Once you’ve implemented PKI identification and authentication, it’s a good idea to turn off password login. Set the PasswordAuthentication directive to ‘no’.

And More

The steps taken thus far provide for a fairly secure OpenSSH configuration while not introducing too much of an overhead (barriers) for access, yet more can be done to strengthen security. Some administrators have the server listen on a non-standard port by changing the Port 22 configuration directive. This only thwarts the most naive attacks, but does save the server from having to address them.

Another good idea is to install and setup Fail2Ban, which watches log files and “bans IPs that show the malicious signs — too many password failures, seeking for exploits, etc.” Using Public Key Cryptography introduces the need for public/private key management and the ability to use server fingerprinting to protect against against OpenSSH server spoofing attacks.

With the right configuration and by using best practices, the OpenSSH server can provide very secure access without overburdening the users.