This section documents the following topics:
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:
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 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.
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.
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.
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.
On the OES 2 server you are granting access to, open the YaST Control Center and click > .
In the left navigation frame, click .
In the drop-down list, select .
Click > > .
The firewall is now configured to allow SSH connections with the server.
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.
On the OES 2 server, open the YaST Control Center; then, in the group, click .
Click .
When the Novell Open Enterprise Server Configuration screen has loaded, click the link under .
The option changes to and the configuration settings appear.
Click .
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, 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, is not checked).
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). 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.
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:
http://IP_Address/iManager.html
where IP_Address is the IP address of an OES 2 server with iManager 2.7 installed.
In the list, 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 the list, click > .
Browse to the group you just created and click .
Click the tab.
Select the option.
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 > .
Click > .
In the Roles and Tasks list, click , browse to the group again, then click .
Click the sub-tab.
In the list, 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 field, type sshd, then click > .
Click the tab.
Browse to and select the User objects that shouldn’t have SSH access, then click .
Click > .
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 list to the 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 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 as an allowed service, the service is still selected when group information is reloaded. Novell plans to address this issue in the near future.