SSH restriction

Introduction

SSH (OpenSSH) provides a secure encrypted connection to remote hosts. If a user has a valid AIX® account, they then can connect via SSH. However, as with any system regarding security awareness, there maybe a requirement to restrict certain users or hosts from connecting to a designated system via SSH. SSH provides two mechanisms to restrict user access: Deny and Allow attributes. These keywords are based on user and group lists. TCP Wrappers can also be used to block SSH connections from known or unknown hosts. I suggest using TCP Wrappers to block hosts either by host name/domain or IP and use the ss hd_config for user/group based access control.

The configuration files and SSH daemon can be found in two places depending on what variant of SSH you have installed. ForAIX OpenSSH, the configurations files are located in the /etc/ssh file and the SSH (sshd) daemon is in the /usr/sbin/sshdfile.

For other OpenSSH types, typically the configuration files are located in /usr/local/etc and the SSH (sshd) daemon is located in /usr/local/sbin/sshd.

Restricting SSH with TCP Wrappers

TCP Wrappers is used to block or allow TCP-based applications that are started from inetd, like the telnet or FTP services. As a rule, SSH is not started from inetd. If you wish to control SSH access via TCP Wrappers, you will need to copy thelibwrap.a into a directory where your LIBPATH points to (for third party applications, this could be: /usr/local/lib). The TCP Wrappers daemon is tcpd.

Looking through the /var/adm/messages file, there could be occasions where you find SSH attempts to your system. These maybe totally innocent attempts at connecting from a local machine within your network or a brute force attempt from an unknown host. These entries should be further investigated. If one concludes that these are unlawful attempts at access, then these should be blocked. Although one can block hosts using the sshd_config file, I suggest using TCP Wrappers to block hosts, since this is your primary wall of defense for incoming based TCP connections.

TCP Wrappers (tcpd) reads two files to determine if the incoming tcp based connection should be allowed or disallowed. The two files are:

Changes to these files are dynamic. Rules to pattern matching in both these files will control what gets denied or allowed. These rules can be complicated or simple. The hosts.allow is searched first. If a pattern match is found, the connection is let in, or more precisely, tcpd dies and lets the real serving daemon take over. The hosts.deny is then searched for a pattern match. If a match is found, then tcpd will deny access for that connection. Simply put, this means hosts.allow rules are applied first, followed by hosts.deny rules. The overall rule is to first allow hosts you trust then deny everything else.

Now, let's go over some examples of how TCP Wrappers can control access via SSH to a host. Imagine we belong to the domain drwho.com, and we only want to allow users belonging to this domain to SSH in. We could use the following to achieve this:

To further refine the previous example, we could still allow all the drwho.com domain connections in and also allow the following IP address ranges: 172.24.11, 172.24.12. (the dot at the end of the IP addresses means to match anything after the dot). Notice in the following example each pattern is separated by a comma.

Generally, you would want to allow all of the domain in, except certain hosts. This would be the case if it was a production system, and you did not want connection coming from a development system. The following will allow all in the previous example just presented apart from the following hosts: dev01 and dev02.

One can also use the username@hostname format in the hosts.allow or hosts.deny file. For example:

You may have to supply the FQDN (fully qualified domain name). To test this, look at how TCP Wrappers resolves the hostname in the messages file, then amend the hosts.allow file accordingly.

For the username@host format, I prefer to use the sshd_config file to control access. This is because it allows me to use TCP Wrappers to authenticate hosts only for TCP-based services like telnet, FTP and the ssh_config file to authenticate users/groups for SSH only. It makes for easier management of host and user control access from a system administrators point of view.

To log connections via syslog to /var/adm/messages in /etc/syslogd.conf, make sure you have one of the following entries:

Or

Be sure to restart syslogd for the changes to take effect:

A typical entry in the messages file for a successful connection (in this case, user dxtans from the host tardis which belongs to the domain drwho.com) could be:

A blocked attempt by a user from the host dev01, via the rules applied in the hosts.allow file, could be:

Restricting with sshd_config

Located in the sshd_config, there are four entries:

If these keywords are not present, simply create them as required. Be sure you only create the keyword you require to avoid unreliable results from occurring. Each of the Allow or DenyUsers lists are space separated by valid usernames, because the Allow or DenyGroups valid groups can only be present. The pattern match is in the following order:DenyUsers,AllowUsers,DenyGroups,AllowGroups.

Any changes made to the file sshd_config will not take effect until sshd is restarted, like so:

If you populate the AllowUsers list with user ids, then only those users can SSH in. The same principal applies to the DenyUsers list, only those users contained in the deny list are denied access. This same rules applies to the group lists. This can become very confusing when you mix some of these rules up, so don't. Just have one list, either an allow list or deny list depending on what your security requirements are.

Users that have an account on that system, but do not have their user ID present in the AllowUsers list, will be denied entry. The same rule applies for the DenyUsers list. Let's now look at that with an example, suppose our AllowUsers list contained the following:

If user alpha tries to SSH in then that user will be denied access, as the user name is not present in the AllowUsers list.

Looking at the /var/adm/messages file confirms this, informing the administrators that user alpha is not listed in the AllowUsers list.

Now looking at the DenyUsers list, suppose our list contained the following:

Now all users whom have an account on the system who are not listed in the deny user list can SSH in.

If user alpha tries to SSH in, then that user will be allowed access as his user name is not contained in the DenyUsers list. This can be verified by viewing the messages file:

However, if user bravo who is on the DenyUsers list tries to SSH in, he will be denied access:

Again, the reason for denial can be verified by viewing the messages file:

Because of pattern matching order, we can now state that no users contained in the DenyUsers list will be granted access, only the user alpha will be granted access. In that case, I suggest just having the AllowUsers list only. If the user ID is not listed in the allow list, then you are not connecting, no matter what is contained in the deny list.

The same principle applies to the groups. Suppose we had the following entry:

The members of the group water are:

Now, if the user dxtans (a member of groups staff and admin)

tries to connect, the user dxtans will fail with the following entry in /var/adm/messages

because dxtans is not in the allow list nor in the deny list.

It maybe advantageous to create a group that contains users that you do not want to allow to SSH in, as this will require least maintenance, and then create a group of users that are allowed to SSH in. For example, suppose we had a group called nossh, containing users not allowed to SSH in:

In the sshd_config file, we had the following entry:

Now any user belonging to the group nossh would be denied access, as can be viewed in the messages file when user golf, whom belongs to the group nossh, tries to SSH in:

Using the group list, rather than the user list, can seem more favorable when you have a large number of users on the system.

Control root access

When dealing with direct root SSH access from remote hosts, I suggest it is best to limit which hosts can SSH in as user root. This approach allows administrators to keep control of where user root can SSH to, thus keeping control on root remote connections.

To control access by user and host via the sshd_conf file, you can use the following formats: root@<hostname> orroot@<hostname.domain>.

You will need to see what format SSH reports in the /var/adm/messages file, whether the host is resolved as a short or long hostname. Once this has been identified, simply insert the corresponding entry into the AllowUsers list. If you are not sure whether it is a short or long name, as this can be dependent on different operating systems from the originating SSH connection, it is best to include both the short and long name.

For example, to allow only root access from the host tardis (which belongs to the drwho domain) we could have the following:

The AllowUsers list in the sshd_config file is then extracted and compared with the newly generated user list. If there are changes, the sshd_config file is updated. Notice the short and long name of the root@tardis is included. As discussed previously, this means only root from the host tardis can SSH in; this provides control as only root from the hosts tardis can SSH in. If there are any changes in the sshd_config, then the SSH service is restarted, and an email is sent out to administrators informing them of the change to sshd_config AllowUsers list.

The script assumes that there is already an entry for the AllowUsers list, and that the list contains at least an entry for the deployment server, like so:

Debugging

To enable debugging, where the messages file just does not display enough information. From the client side, use the verbose (v) where more v's means more verbose option when connecting via SSH:

From the server side, stop the sshd service and start it up with the debug option. The debug (d) means more verbose. When a connection is made, sshd will then terminate. You will then need to either restart it in debug mode again (if you require further testing) or normally via the startsrc command. To start in debug mode use:

If you do find issues when trying to connect via SSH, and the issue is not immediately obvious, then I recommend using both the client and server debug methods together to diagnose issues.

Typical output of starting sshd in debug mode could be:

If sshd is started in debug mode, any errors found in sshd_conf by sshd will be reported to standard ouput. If sshd is started by the startsrc command any errors found in the sshd_conf file will be displayed in the /var/adm/messages file. You can also use the following method by checking the last exist status (you can determine if you have issues with the configuration):

Using the debug method, however, should be first when diagnosing SSH related issues.

Conclusion

Using SSH allows for secure encrypted connections to remote hosts. However, as with any incoming connection, these need to be policed. The use of TCP Wrappers and the Allow/Deny lists in sshd_config can put you on a proactive stance regarding security.

About the author