One of the servers I am going to spend a bit of time on is Secure Shell (SSH) because it’s become widely used and SSH clients are readily available. If you’re not 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.) SSH is a secure tunnel over which several different types of processes can flow. The fact that it’s multi-featured is one reason why I believe that IBM hasn’t provided an exit point specifically for SSH and why it’s often difficult to know how to block it, even at the firewall level.
If you’re not using SSH in your organization, make sure the autostart value is *NO. If you are using SSH, follow the instructions below to limit who can use it and the directories in which users can operate.
When you think about who should be able to use SSH, it’s typically limited to a handful of people, often just administrators. Controlling which profiles are allowed to connect via SSH is actually quite simple. It can be accomplished by adding one or more directives to the configuration file associated with the SSH daemon. The configuration file can be found at this path:
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. You don’t have to specify values for all of these directives. (In fact, it doesn’t work if you do!) 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.
What seems to work well for my clients is to create a group specifically for SSH use. If a user needs to use SSH, put them in this group. The group can be specified as either their Group profile or as one of their Supplement group profiles. Do not overload this group—that is, do not use it for any purpose other than to control SSH. That way, there’s much less chance that you’ll have to exclude users in the configuration file—in other words, use the DenyUsers directive.
If you happen to have the situation where you have a group in which some but not all members of the group need SSH access, you can then go ahead and use the DenyUsers directive, specifying the names of the profiles that shouldn’t be allowed to use SSH. See Figure 12.3. Now, only members of the GRPSSH and SYSADMS groups will be allowed use of SSH, except for John, Joe, and Sam. All other users are also denied, just like John, Joe, and Sam are.
Figure 12.3: Allow or deny SSH access to groups or individuals.
You’ll want to take note of these items:
- Do not use both AllowUsers and AllowGroups. You can use one or the other but not both.
- 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.