The Secure Shell (SSH) is a popular way for administrators to securely connect to IBM i, but it’s likely you don’t want just anyone using SSH. Carol discusses how you can control which users are allowed to use SSH.

SSH clients are readily available from the Internet, so unless you’re controlling what can be installed on your users’ desktops, an SSH client such as PuTTY can be download, installed, and in use in just minutes. One of the popular features of most SSH clients is the file transfer capability. The secure connection capabilities of SSH clients provide an alternative to unencrypted FTP connections. This feature may not seem like a security exposure and shouldn’t be if you’ve implemented object-level security. But if you’re like many IBM i organizations that haven’t taken this step or rely on exit point technologies to secure your critical files, you’ve got an issue. (Note: IBM has not provided an exit point for the SSH daemon, and attempting to control access via the Sockets exit is tenuous at best.)

If you’ve read previous articles, you know that I’m all about implementing multiple layers of defense—in other words, using more than one technology to secure data. That way, if one technology is misconfigured or breached, there’s at least one other technology in place to protect your data. Steve Pitcher previously wrote about several issues associated with SSH, and I highly recommend you read these warnings.

In addition to taking the actions Steve lists, I also recommend that you consider limiting the profiles allowed to use SSH. In most organizations, system administrators are the only individuals who need to use SSH, so why allow all other profiles access? Controlling access can be done by adding one or more directives to the configuration file associated with the SSH daemon. It can be found at this path:

/QOpenSys/QIBM/UserData/SC1/OpenSSH/etc/sshd_config

The directives available for controlling access are DenyUsers, AllowUsers, DenyGroups, and AllowGroups. Regardless of the order in which they’re defined in the config file, they are evaluated in the order I’ve listed. Despite what you might think, you don’t have to specify values for all of these directives. If you only want the members of one group— e.g., GRPSSH—to be able to use SSH, you only need to specify AllowGroups grpssh.

Everyone who is not a member of GRPSSH is denied access. In my case, I’ve created a group just to control access to SSH. But perhaps you have a group called SYSADMS and everyone in that group should be able to use SSH except for two or three members. In this case, you’d add the DenyUsers directive and specify the names of the profiles that shouldn’t be allowed to use SSH. See Figure 1. Now, only members of the GRPSSH and SYSADMS groups will be allowed use of SSH, except for John, Joe, and Sam. Everyone else will be denied just like John, Joe, and Sam are.

Figure 1: Allow or deny SSH access to groups or individuals.

You’ll want to take note of these items:

• The profile and group names must be specified in lowercase! The directive itself is not case-sensitive, but the values are and, counter to what one might think, it’s expecting the values to be in lowercase.
• When specifying multiple profiles (or groups), separate each with a blank.
• You must end and restart the server to have your configuration changes take effect.

Summary

While SSH is a handy way to access the system, especially when your organization has disallowed FTP, you’ll want to consider the security implications of starting the *SSHD TCP/IP server. Unless you have adequately secured the files containing data that is sensitive or critical to your organization, you’ll want to consider limiting who is allowed to use SSH. Even if you have secured your data, you may want to allow SSH access to only those users with a business need to use it. This is an example of implementing a “least-privilege access” model, an approach that I highly recommend.