12.4 SSH Services on OES 2

This section documents the following topics:

12.4.1 Overview

SSH services on SLES 10 are provided by OpenSSH, a free version of SSH connectivity tools developed by the OpenBSD Project.

Linux administrators often use SSH to remotely access a server for management purposes, such as executing shell commands, transferring files, etc. Because many OES 2 services can be managed at a command prompt via an SSH session, it is important to understand how SSH access is controlled in OES 2.

This section discusses the following topics:

When Is SSH Access Required?

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 2 server has NSS volumes, eDirectory contains an object named nssvolumes that 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, providing that 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.

How SSH Access for eDirectory Users Works

For eDirectory users, the following work together to control SSH access:

  • Firewall: As mentioned, the default firewall configuration on an OES 2 server doesn’t 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 service: In OES 2, 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 on each server.

  • LUM-enabling: After SSH is included as a LUM-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.

  • The Samba connection: Users who are enabled for Samba (CIFS) file services are added by default to an OES-created Samba group that:

    • Is LUM-enabled.

    • Doesn’t specify SSH as an allowed service.

    Therefore, because SSH access requires that all of a user’s groups must all allow access, Samba users are denied SSH access unless

    • The user is removed from the Samba group.

      or

    • The Samba group is modified to allow SSH access for all Samba users.

SSH Security Considerations

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 anyone.

12.4.2 Setting Up SSH Access for LUM-enabled eDirectory 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.

Allowing SSH Access Through the Firewall

  1. On the OES 2 server you are granting access to, open the YaST Control Center and click Security and Users > Firewall.

  2. In the left navigation frame, click Allowed Services.

  3. In the Allowed Services drop-down list, select SSH.

  4. Click Add > Next > Accept.

    The firewall is now configured to allow SSH connections with the server.

Adding SSH as an Allowed Service in LUM

  1. If SSH is already an allowed service for Linux User Management on the server, skip to Enabling Users for LUM.

    or

    If SSH is not an allowed service for Linux User Management on the server, continue with Step 2.

  2. On the OES 2 server, open the YaST Control Center; then, in the Open Enterprise Server group, click OES Install and Configuration.

  3. Click Accept.

  4. When the Novell Open Enterprise Server Configuration screen has loaded, click the Disabled link under Linux User Management.

    The option changes to Enabled and the configuration settings appear.

  5. Click Linux User Management.

  6. Type the eDirectory Admin password in the appropriate field, then click OK > Next.

  7. In the list of allowed services, click sshd.

  8. Click Next > Next > Finish.

    Each LUM-enabled group in eDirectory, except the system-created Samba group, now shows SSH as an allowed service. The Samba group shows the service as not allowed (or literally speaking, sshd is not checked).

Enabling Users for LUM

There are numerous ways to enable users for LUM.

For example, in iManager > Linux User Management there are options for enabling users (and choosing a Group in the process) or enabling groups (and enabling users in the process). Linux enabling is part of the process required for Samba access. And finally, there are also command line options.

For specific instructions, refer to Managing User and Group Objects in eDirectory in the OES 2 SP3: Novell 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, if those same users are not also enabled for Samba on the server, they now have SSH access to the server.

On the other hand, if you have installed Samba on the server, or if you install Samba in the future, the users who are configured for Samba access will have SSH access disabled.

To restore access for users impacted by Samba, see Providing SSH Access for Samba Users.

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.

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.

  1. Open iManager in a browser using its access URL:

    http://IP_Address/iManager.html

    where IP_Address is the IP address of an OES 2 server with iManager 2.7 installed.

  2. In the Roles and Tasks list, click Groups > Create Group.

  3. 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 OK.

  4. In the Roles and Tasks list, click Directory Administration > Modify Object.

  5. Browse to the group you just created and click OK.

  6. Click the Linux Profile tab.

  7. Select the Enable Linux Profile option.

  8. 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 OK > OK.

  9. Click Apply > OK.

  10. In the Roles and Tasks list, click Modify Object, browse to the group again, then click OK.

  11. Click the Other sub-tab.

  12. In the Unvalued Attributes list, select uamPosixPAMServiceExcludeList, then click the left‑arrow to move the attribute to the Valued Attributes list.

  13. In the Add Attribute dialog box, click the plus sign (+) next to the empty drop-down list.

  14. In the Add item field, type sshd, then click OK > OK.

  15. Click the Members tab.

  16. Browse to and select the User objects that shouldn’t have SSH access, then click OK.

  17. Click Apply > OK.

Providing SSH Access for Samba Users

There are two options for providing SSH access to users who have been enabled for Samba access:

  • You can remove the user from the server_name-W-SambaUserGroup.

    IMPORTANT:This presupposes that the user is a member of a different LUM-enabled group that also provides access to the server. If the user was enabled for LUM only as part of a Samba configuration, then removing the user from the Samba group breaks access to Samba and the user does not have SSH access.

  • You can change access for the entire Samba group by moving the uamPosicPAMServiceExcludeList attribute from the Valued Attributes list to the Unvalued Attributes list, using the instructions in Restricting SSH Access to Only Certain LUM-Enabled Users as a general guide.

    NOTE:Although the option to disable SSH access through the Modify Group iManager plug-in is much more simple and straightforward, that option is not working as of this writing. Although the plug-in appears to deselect sshd as an allowed service, the service is still selected when group information is reloaded. Novell plans to address this issue in the near future.