With the amount of SSH brute force attacks, securing SSH is more important than ever.

Here are a few methods you can consider to further harden your SSH installation.

Default Settings
First of all, we look att the default settings as these apply to many (most?) distributions.

• Allows Legacy SSH protocol version 1  (has known security issues)
• Allows direct access to root via password authentication
• Uses low key strength to secure sessions
• Allows SSH access to all users

Four minor items that should be changed at first boot of the server.

Harden SSH

Disable SSH Protocol 1
SSH has two protocols, 1 and 2. Protocol 1 has a number of known flaws and should no longer be used.
Diisable Protocol 1 by editing /etc/ssh/sshd_config

Restrict Root Login
There are two options in restricting access to root logins. You can either disable root logins completly or you can force it to use SSH keys.

Setting the option to  “no” disables all direct root logins. If you rather only disable password logins, change the setting to “without-password”.

My preference is to set this option to “no”, but the important thing is to be consistent. If you on some servers allows direct root logins with or without passwords, you are only going to be confused on which ones are enabled and which ones who are not.

Reduce Grace Time
The default grace time for authenticating a user is 2 minutes. This is only necessary if you are on a very slow connection but often it will only result in holding unathenticated connections open for a very long time. You can, and should reduce this to somewhere around 30 seconds, that is most likely enough time for everyone to login.

Default Port
When reading forums all over the Internet, you will find recommendations on changing the default port of SSH. ‘Very often the person recommending this will use this as an example.

The vast majority of SSH attacks are directed by compromised zombie machines against SSH servers listening on the default port of “22”. By changing this port to something else you greatly reduce the risk of an automated break-in.

This is usually called security by obscurity and is in a way, giving you a false feeling of security. If you on the other hand see the changing of port as your number one security setting, you most likely have other security issues that should worry you.

While you may reduce the number of attacks from “blind” zombies (or bots), it only takes a simple port-scanning of your server to identify what port you are using for SSH.

There is nothing wrong in changing the SSH port. The main thing, as already been pointed out: Be consistent!

If you for every server randomly selects a port, you will have a hard time to keep track of the ports yourself.

Not to mention that if you by accident (or willingly) changes the port to something that are often used by other applications, you might be flagged as a “suspect” by some security scanners.

Protect SSH with a Firewall
One of the best measures you can apply. Use your firewall to block access to SSH from unauthorized IP addresses. This provides a very secure, first layer of security. If you are not lucky enough to have a hardware firewall, you can use IPTables to limit SSH access.

Restrict Users
Configure SSH to permit only certain users to log in. By default all users can access SSH. Start using the “AllowUsers” directive and restrict access to only certain users. This also adds another layer of security. As an alternative there is also the “AllowGroup” directive.
You can then add/remove users from this group and by that add/remove SSH access.

Or

Do not Use Passwords
If you use keys as authentication, disable password-based logins completly.

If you disable password-logins, it doesn’t matter if the person knows it. They won’t be able to login. When enabling this, be sure to test it more then once, you must be certain that your keys configured properly. Otherwise you will be locked out from oyur server. Do you often use SFTP/SCP to send/get files from your server? Many clients can also use keys, so there is no excuse not to use it. Search for your favourite SSH client and keys. You will find many guides on howto set it up.

To disable password authentication completly, set this directive:

Increase Key Strength

Current recommendations are for 1024 or 2048 bit strength but by default, a key strength of 768 bits is used.

This is also not expected to be an issue, If you decide to change it, you will need to delete your current host keys so that  SSH can regenerate them again when it restarts.

Check the Defaults
There are several more settings which by default are secure but you may want to review them. You will find more details on these in the SSH documentation. Here are something to get you started:

And the list goes on  ….
If you look around I am sure you will find more settings and/or tweaks that can increase the security.

The steps above are only the first, but effective steps hardening SSH. Add rate-limiting SSH access with IPtables to the list and you got a good foundation for your security setup.