Sort out your SSH configs

Secure Server

Not on the List

The next thing I'll discuss is disabling root logins and letting as few users as possible log in remotely over SSH, which is imperative to securing your SSH installation.

A word of warning though: Make sure you have access to whichever less privileged users you have chosen to allow to log in before restarting the server, so you don't lock yourself out.

Disabling root logins can be set in the /etc/sshd_config file by adding

PermitRootLogin no

or by changing yes to no if that line already exists. The next entry likely doesn't exist, so add it to the top of the file to help with troubleshooting in the future; you separate users with spaces. Here, I permit four users to log in over SSH:

AllowUsers steven daniel philippe raheem

Additionally you can control access with AllowGroups, DenyGroups, and DenyUsers. Now if you're sure you can use one of those login accounts, you can reload the daemon as before.

Once I am confident that I can get back into the server remotely, I move the server off the now ill-fated port 22 to something less obvious, such as 2222, which will limit the number of automated port scans testing my security.

This step is simple (but remember which port you choose!) and just needs this change:

Port 2222

Again, simply reload the service and see if you can get back into your server:

ssh -p2222 chrisbinnie@DebianBox.tld

When you are changing SSH configs, you should keep an existing SSH console open. Then, if you make a mistake, you can try to get into your server via the older login session after setting the changes live. It's not infallible, but it works most of the time.

As I wrote in a piece about TCP Wrappers [1], I won't consider running any SSH public-facing instance without TCP Wrappers enabled (even with firewalls), and I ardently recommend you use them.

Versions

OpenSSL, from which OpenSSH receives its clever encryption capabilities, has received inordinate amounts of bad press. In brief, the Internet at large has become to rely on OpenSSL heavily since its predecessor, Telnet, was put in a bad light, but as long as you subscribe to the pertinent security alert mailing lists and patch your servers in a timely manner, you should be out of harm's reach.

That said, many users thought some issues remained unresolved in SSH version 1 (SSH-1); therefore, it is best practice to force your SSH server to insist, without fail, that connecting clients always use at least version 2 (SSH-2) by putting

Protocol 2

in /etc/ssh/sshd_config. It's a simple change and most likely only alienates older clients or those limited by connectivity or hardware.

In almost all cases any public-facing daemons that you run should hide their banners . By that, I mean you need to avoid advertising which server version is being used, in case of exploits specific to that version. Sadly, however, with SSH you need to recompile the OpenSSH package from source to achieve this, which is time consuming.

Thankfully, this threat is removed if TCP Wrappers are enabled, because the public will not even be able to get to the part of the connection that displays a banner; only your explicitly allowed IP addresses present in /etc/hosts.allow can get that far.

Another useful precaution is to kick people off the server who have been idle for 20 minutes (i.e., 1,200 seconds):

ClientAliveInterval 1200
ClientAliveCountMax 0

Also, mistakes happen, so it's important to stop accidental connections:

PermitEmptyPasswords no

This entry can be crucial, and I hope self-evident.

sFTP

Although you probably don't mind letting users upload files to their home directories, how do you keep them off the rest of your filesystem so the server keeps running?

One super-simple OpenSSH config entry fixes this perennial sys admin problem. First, make sure the /home directory is owned by root:

chown root:root /home

At the foot of the /etc/ssh/sshd_config file, then add the following lines (commenting out the other Subsystem entry as you do with a hash symbol):

Subsystem sftp internal-sftp
Match User chrisbinnie
  ChrootDirectory /home
  AllowTCPForwarding no
  X11Forwarding no
  ForceCommand internal-sftp

Because this change is not very strict and is relatively forgiving, I'm slightly reluctant to call it a jail or chroot.

The chroot config shows that any user named chrisbinnie will be dropped to the /home directory at login and only be able to write files to their home directory (i.e., /home/chrisbinnie). The Match User can be changed to Match Group, which might allow any user in a group (e.g., uploaders) to write to their directories, too. To see if the setup works, restart SSH now.

The one downside to this simple chroot config is that users can list the files in other user's home directories. However, you can fix this problem by changing the permissions of each user's home directory with: