This section documents the following topics:
Linux administrators often use SSH to remotely access a server for management purposes, such as executing shell commands, transferring files and so on. Because many OES services can be managed at a command prompt via an SSH session, it is important to understand how SSH access is controlled in OES.
This section discusses the following topics:
SSH access is required for the following:
SSH administration access for eDirectory users: For eDirectory users to manage the server through an SSH connection, they must have SSH access as LUM-enabled users (eDirectory users configured for access to Linux services).
NOTE:The standard Linux root user is a local user, not an eDirectory user. The root user always has SSH access as long as the firewall allows it.
Access to NSS Volume Management in NetStorage: When an OES server has NSS volumes, eDirectory contains an object namedthat provides management access to the volumes through the File Access (NetStorage) iManager plug-in. Using the plug-in to manage NSS volumes, assign trustee rights, salvage and purge files, etc. requires SSH access to the server.
Although eDirectory administrators can create Storage Location Objects to the NSS volumes without SSH access if they know the path to the volume on the POSIX file system and other volume information, having SSH access makes administering NSS volumes in NetStorage much easier.
Access to any NetStorage Storage Location Objects based on SSH: The NetStorage server provides Web access to directories and files on other servers (or on itself).
Typically, either an NCP or a CIFS connection is used for connecting the NetStorage server with storage targets. However, an SSH connection can also be used, and if it is, the users accessing data through the connection must have SSH access to the data on the target servers.
For eDirectory users, the following work together to control SSH access:
Firewall: As mentioned, the default firewall configuration on an OES server does not allow SSH connections with the server. This restricts the root user as well. Therefore, the first requirement for SSH access is configuring the firewall to allow SSH services.
Linux User Management (LUM) must allow SSH as a PAM-enabled service: Access to SSH and other Linux services is controlled through Linux User Management (LUM), and each service must be explicitly included in the LUM configuration as a PAM-enabled service on each server.
PAM-enabling: After SSH is included as a PAM-enabled service on a server, at least one group and its users must be enabled for LUM. Only LUM-enabled eDirectory users can have SSH access.
All eDirectory Groups must allow access: SSH access is inherited from the LUM-enabled groups that a user belongs to, and access is only granted when all of the groups to which a user belongs allow it.
Remember that SSH access lets users browse and view most directories and files on a Linux server. Even though users might be prevented from modifying settings or effecting other changes, there are serious security and confidentiality issues to consider before granting SSH access to a group of users.
If you need to grant SSH access to an eDirectory user, complete the instructions in the following sections in order, as they apply to your situation.
NOTE:This section assumes you are allowing SSH access on an installed server.
SSH can also be enabled during an OES installation by clicking thebutton on the Firewall screen.
On the OES server you are granting access to, open the YaST Control Center and click> .
In the left navigation frame, click.
In thedrop-down list, select .
Click> > .
The firewall is now configured to allow SSH connections with the server.
If SSH is already an allowed (PAM-enabled) service for Linux User Management on the server, skip to Enabling Users for LUM.
If SSH is not an allowed (PAM-enabled) service for Linux User Management on the server, continue with Step 2.
On the OES server, open the YaST Control Center; then in thegroup, click .
When the Micro Focus Open Enterprise Server Configuration screen has finished loading, click thelink under .
The option changes toand the configuration settings appear.
Type the eDirectory Admin password in the appropriate field, then click> .
In the list of allowed services, click.
Click> > .
Each LUM-enabled group in eDirectory now shows SSH as an allowed service.
There are numerous ways to enable users for LUM.
For example, in iManager >there are options for enabling users (and choosing a Group in the process) or enabling groups (and enabling users in the process). And finally, there are also command line options.
For specific instructions, refer to OES 2018 SP2: Linux User Management Administration Guide.
After you configure the server’s firewall to allow SSH, add SSH as an allowed service, and LUM-enable the eDirectory users you want to have SSH access.
Of course, many network administrators limit SSH access to only those who have administrative responsibilities. They don’t want every LUM-enabled user to have SSH access to the server.
If you need to limit SSH access to only certain LUM-enabled users, continue with Restricting SSH Access to Only Certain LUM-Enabled Users.
SSH Access is easily restricted for one or more users by making them members of a LUM-enabled group and then disabling SSH access for that group. All other groups assignments that enable SSH access are then overridden.
Open iManager in a browser using its access URL:
where IP_Address is the IP address of an OES server with iManager installed.
In thelist, click > .
Type a group name, for example NoSSHGroup, and select a context, such as the container where your other Group and User objects are located. Then click.
In thelist, click > .
Browse to the group you just created and click.
In the Add UNIX Workstation dialog box, browse to and select the UNIX Workstation objects for the servers you are restricting SSH access to, then click> .
In the Roles and Tasks list, click, browse to the group again, then click .
In thelist, select , then click the left‑arrow to move the attribute to the list.
In the Add Attribute dialog box, click the plus sign (+) next to the empty drop-down list.
In the sshd, then click > .field, type
Browse to and select the User objects that shouldn’t have SSH access, then click.