Getting a (More) Secure SSH Configuration

Did you ever install an Intrusion Detection System on a public server? Well I did and it was like a wake-up call to me. The server didn’t had anything important running on it, but nevertheless the same notification from my IDS kept popping up: ‘SSH: Multiple failed logins in a small period of time.’ These attacks appeared to come from all over the world: the Netherlands, France, Russia, Japan, South-Korea,…

Most of the people don’t do more than invoking the ‘apt-get install’ command. They stick with the default configuration because … well … it works. With the following few simple configuration changes in the /etc/ssh/sshd_config file you can make your SSH enabled server less open to the outside world:

1. The most basic rule

Do not allow root to login via SSH. Every attacker that attempted to break in, tried the root account. Obviously this is done because of these two reasons:

  1. The attacker is (quite) sure that the account exists.
  2. If you can get in as root, you don’t need an exploit for privilege escalation. You can do anything you want.
PermitRootLogin = no

2. Simple but effective

Change the default SSH port (22). If hackers are scanning for random targets, and at the first glance they see that port 22 is closed, they will hop on to the next IP address.

Port = 6666

3. Permit and restrict access to certain users

If only certain users are allowed access you can use the “AllowUsers” parameter to control it. Do the opposite for “DenyUsers”.

AllowUsers = jeroen jim
DenyUsers = john joe

4. Only allow access from your management LAN

If your system has multiple interfaces and SSH access is only allowed from the internal (management) LAN, let the SSH process only listen on the IP address connected to that LAN:

ListenAddress = 10.0.0.1

5. Deny all host based authentication

This forces users to enter a password when authenticating and not to use .rhost files for example:

IgnoreHosts = yes
HostbasedAuthentiction = no
RhostsAuthentication = no
RhostsRSAAuthentication = no

6. Use the newest SSH protocol

Because SSH 1 is ooold and contains some vulnerabilities.

Protocol = 2

7. Control the maximum simultaneous unauthenticated connections

This can protect you against brute force script that use forking.

MaxStartups 10

 8. Don’t allow empty passwords

I think that’s quite obvious ;) .

PermitEmptyPasswords = no

Or even better: use public/private key pairs. Or how the OpenBSD journal puts it:

The OpenBSD Project is selling SSH Mastery print version as a fund-raiser. If you’ve been waiting for a print copy, this is your chance.

If you don’t need it, you know someone who is still using passwords with SSH. Buy a copy. Slap them soundly with it.

9. Put up a banner

Put up a banner that’s shown at login time, that shows a warning. This is necessary in order to prosecute unauthorized users, if it comes to this.

Banner /etc/issue

An example:

************************************************
NOTICE TO USERS WARNING! The use of this system is restricted
to authorized users, unauthorized access is forbidden and will
be prosecuted by law. All information and communications on
this system are subject to review, monitoring and recording at
any time, without notice or permission. Users should have no 
expectation of privacy. 
*************************************************

To summarize and for the lazy ones:

PermitRootLogin = no
Port = 6666
AllowUsers = jeroen jim
DenyUsers = john joe
ListenAddress = 10.0.0.1
IgnoreHosts = yes
HostbasedAuthentiction = no
RhostsAuthentication = no
RhostsRSAAuthentication = no
Protocol = 2
MaxStartups 10
Banner /etc/issue

And if you can: use key pairs to login!