SSH is one of the most common services you will find running on a Unix-based server. Here are some thoughts on directives you can use to harden the service from external attacks.
Disclaimer: The first step to securing any service is to firewall it down to only trusted sources or networks.
Hardening login attempts
This directive defines how long the SSH server will wait for a user to successfully authenticate after connecting. The default is 120 seconds, which I find to be a little long. I usually pare this down to 15 or 30 seconds. For most purposes, 30 seconds should be more than long enough for a user to type their password and login.
MaxAuthTries – Lies!
According to the man page, MaxAuthTries “specifies the maximum number of authentication attempts permitted per connection.” One may interpret this to mean “maximum password tries”, but unfortunately that is not the case.
When your SSH client connects to a server, it can try several different authentication methods such as pubkey, GSSAPI, and password. Each of those method attempts counts against the MaxAuthTries. If you set your MaxAuthTries to 1, and your SSH client tries pubkey and fails, you get immediately rejected. Not exactly what most people are looking for.
Unfortunately, this directive has very limited use. If you want to reject connections on password failure more quickly, I’d recommend looking into some PAM rules.
MaxStartups defines how many unauthenticated (pre-login) SSH sessions can exist and any one time. Set at its default of 10, if there are 10 sessions trying to authenticate, it will reject any new connections.
Tweaking this setting can lead to unexpected results. For example, if you lower this down to 2 and your SSH service is under brute-force attack, you probably won’t be able to login the server yourself to deal with it. How you should adjust this setting all depends on the context of your service. If your service is accepting connections from the public internet, I’d recommend lowering this setting down to 2 or 3 to limit brute-force attack speed, and implementing a network-layer DDoS prevention system to prevent losing access to the service.
This directive defines how root may be allowed to authenticate to SSH. You should never, ever set this to “yes”. Doing so opens up a vector to brute force root’s password. There are several alternatives which will allow you to perform remote actions as root without using password authentication.
A more secure option would be to use “without-password”, which allows root to authenticate with a non-password method such as pubkey, preventing a brute force attack. Even more secure would be “force-commands-only”, which works the same way as “without-password”, but only permits the login if the SSH client has specified a command to run.
Bottom line, you should always try avoid doing anything as root over a network connection.
When this directive is enabled, sshd will create an unprivileged child process to handle each incoming SSH connection. Enabling this helps limit the damage that could be done if a remote exploit is used on SSH. As such, it should always be enabled.