loading...

Ubuntu Server 18.04 – Securing OpenSSH

How to Change the server name on Windows Server 2019

OpenSSH is a very useful utility, it allows us to configure our servers from a remote location as if we were sitting in front of the console. In the case of cloud resources, it’s typically the only way to access our servers. Considering the nature of OpenSSH itself (remote administration), it’s a very tempting target for miscreants who are looking to cause trouble. If we simply leave OpenSSH unsecured, this useful utility may be our worst nightmare.

Thankfully, configuring OpenSSH itself is very easy. However, the large number of configuration options may be intimidating to someone who doesn’t have much experience tuning it. While it’s a good idea to peruse the documentation for OpenSSH, in this section, we’ll take a look at the common configuration options you’ll want to focus your attention on first. The configuration file for OpenSSH itself is located at /etc/ssh/sshd_config, and we touched on it in Chapter 4, Connecting to Networks. This is the file we’re going to focus on in this section, as the configuration options I’m going to give you are to be placed in that file.

With each of the tweaks in this section, make sure you first look through the file in order to see whether the setting is already there, and change it accordingly. If the setting is not present in the file, add it. After you make your changes, it’s important to restart the OpenSSH daemon:

sudo systemctl restart ssh

Go ahead and open this file in your editor, and we’ll go through some tweaks.

One really easy tweak is to change the port number that OpenSSH listens on, which defaults to port 22. Since this is the first port that hackers will attempt, it makes sense to change it, and it’s a very easy change to make. However, I don’t want you to think that just because you change the port for OpenSSH, that it’s magically hidden and cannot be detected. A persistent hacker will still be able to find the port by running a port scan against your server. However, with the change being so easy to tweak, why not do it? To change it, simply look for the port number in the /etc/ssh/sshd_config file and change it from its default of 22:

Port 65332

The only downsides I can think of in regards to changing the SSH port are that you’ll have to remember to specify the port number when using SSH, and you’ll have to communicate the change to anyone that uses the server. To specify the port, we use the -p option with the ssh command:

ssh -p 65332 myhost

If you’re using scp, you’ll need to use an uppercase P instead:

scp -P 65332 myfile myserver:/path/to/dir

Even though changing the port number won’t make your server bulletproof, we shouldn’t underestimate the value. In a hypothetical example where an attacker is scanning servers on the internet for an open port 22, they’ll probably skip your server and move on to the next. Only determined attackers that specifically want to break into your server will scan other ports looking for it. This also keeps your log file clean; you’ll see intrusion attempts only from miscreants doing aggressive port scans, rather than random bots looking for open ports. If your server is internet-facing, this will result in far fewer entries in the logs! OpenSSH logs connection attempts in the authorization log, located at /var/log/auth.log. Feel free to check out that log file to see what typical logging looks like.

Another change that’s worth mentioning is which protocol OpenSSH listens for. Most versions of OpenSSH available in repositories today default to Protocol 2. This is what you want. Protocol 2 is much more secure than Protocol 1. You should never allow Protocol 1 in production under any circumstances. Chances are you’re probably already using the default of Protocol 2 on your server, unless you changed it for some reason. I mention it here, just in case you have older servers still in production that are defaulting to the older protocol. Nowadays, OpenSSH is always on Protocol 2 in any modern release of a Linux distribution.

Next, I’ll give you two tweaks for the price of one. There are two settings that deal with which users and groups are allowed to log in via SSH, AllowUsers, and AllowGroups, respectively. By default, every user you create is allowed to log in to your server via SSH. With regards to root, that’s actually not allowed by default (more on that later). But each user you create is allowed in. Only users that must have access should be allowed in. There are two ways to accomplish this.

One option is to use AllowUsers. With the AllowUsers option, you can specifically set which users can log in to your server. With AllowUsers present (which is not found in the config file by default), your server will not allow anyone to use SSH that you don’t specifically call out with that option. You can separate each user with a space:

AllowUsers larry moe curly  

Personally, I find AllowGroups easier to manage. It works pretty much the same as AllowUsers, but with groups. If present, it will restrict OpenSSH connections to users who are a member of this group. To use it, you’ll first create the group in question (you can name it whatever makes sense to you):

sudo groupadd sshusers

Then, you’ll make one or more users a member of that group:

sudo usermod -aG sshusers myuser

Once you have added the group and made a user or two a member of that group, add the following to your /etc/ssh/sshd_config file, replacing the sample groups with yours. It’s fine to use only one group. Just make sure you add yourself to the group before you log out, otherwise you’ll lock yourself out:

AllowGroups admins sshusers gremlins

I recommend you use only one or the other. I think that it’s much easier to use AllowGroups, since you’ll never need to touch the sshd_config file again, you’ll simply add or remove user accounts to and from the group to control access. Just so you’re aware, AllowUsers overrides AllowGroups.

Another important option is PermitRootLogin, which controls whether or not the root user account is able to make SSH connections. This should always be set to no. By default, this is usually set to prohibit-password, which means key authentication is allowed for root while passwords for root aren’t accepted. I don’t see any reason for this either. In my opinion, turn this off. Having root being able to log in to your server over a network connection is never a good idea. This is always the first user account attackers will try to use:

PermitRootLogin no

There is one exception to the no-root rule with SSH. Some providers of cloud servers, such as DigitalOcean, may have you log in as root by default. This isn’t really typical, but some providers are set up that way. In such a case, I recommend creating a regular user with sudo access, and then disallowing root login.

My next suggestion is by no means easy to set up, but it’s worth it. By default, OpenSSH allows users to authenticate via passwords. This is one of the first things I disable on all my servers. Allowing users to enter passwords to establish a connection means that attackers will also be able to brute-force your server. If passwords aren’t allowed, then they can’t do that. What’s tricky is that before you can disable password authentication for SSH, you’ll first need to configure and test an alternate means of authenticating, which will usually be public key authentication. This is something we’ve gone over in Chapter 4, Connecting to Networks. Basically, you can generate an SSH key pair on your local workstation, and then add that key to the authorized_keys file on the server, which will allow you in without a password. Again, refer to Chapter 4, Connecting to Networks if you haven’t played around with this yet.

If you disable password authentication for OpenSSH, then public key authentication will be the only way in. If someone tries to connect to your server and they don’t have the appropriate key, the server will deny their access immediately. If password authentication is enabled and you have a key relationship, then the server will ask the user for their password if their key isn’t installed. In my view, after you set up access via public key cryptography, you should disable password authentication. Just make sure you test it first:

PasswordAuthentication no

There you are, those are my most recommended tweaks for securing OpenSSH. There’s certainly more where that came from, but those are the settings you’ll benefit from the most. In the next section, we’ll add an additional layer, in the form of Fail2ban. With Fail2ban protecting OpenSSH and coupled with the tweaks I mentioned in this section, attackers will have a tough time trying to break into your server. For your convenience, here are all the OpenSSH configuration options I’ve covered in this section:

Port 65332 
Protocol 2 
AllowUsers larry moe curly 
AllowGroups admins sshusers gremlins 
PermitRootLogin no 
PasswordAuthentication no 

Comments are closed.

loading...