2.1 Setting Up SSH on a Server

As a prerequisite, it is recommended that you install the Apache Administration server if it wasn’t installed by default. The Apache Administration server is normally installed by default unless you installed a special-purpose server that didn’t require it, such as iLogin, DNS/DHCP, Pre-migration NetWare®, Virtual Office, or Novell® Branch Office.

You can install OpenSSH on a server either as an optional component during the NetWare custom installation or after installing NetWare using the following procedure:

  1. Insert the NetWare 6.5 Operating System CD into the CD-ROM drive of the server where you want to install OpenSSH.

  2. Start the NetWare GUI by entering startx at the system console prompt.

  3. Click Novell > Install > Add.

  4. In the Source Path dialog box, type the path or browse to the CD.

  5. Select the postinst.ni response file, then click OK.

  6. On the Install Components page, select Secure Shell from the products list.

  7. Click Next.

  8. When prompted, enter the administrator username, password, and context.

  9. Follow the remaining prompts.

  10. Click OK.

IMPORTANT:After upgrading from a NetWare 5.1 server with eDirectory™ 7.x to a NetWare 6.5 server (which upgrades eDirectory to version 8.7), User objects don’t have a uniqueid attribute, which is used by sshd for authentication. As a result, sshd falls back to the CN attribute, which is no longer public after the upgrade. The admin user must then make the CN attribute public in ConsoleOne® or iManager.

2.1.1 Completing Post-Installation Configuration

After the installation, you need to complete some additional configuration before you or your users can access files on the server.

  1. Load the sshd.nlm file at the server.

  2. (Optional) Edit the sys:etc\ssh\sshd_config file to change any settings from the default.

  3. (Optional) Add users and public keys into sshd.bag.

IMPORTANT:OpenSSH often reports an error trying to configure the product during a remote upgrade. To fix the configuration problems, edit sys:\etc\ssh\sshd_config and update the default <Your-Context> tag with the admin user’s context. You must also ensure that admin users have the Supervisor trustee right to the NCP™ Server object for each server in the tree that they administer. A local post-install of the OpenSSH product (from the GUI on the server) also corrects the configuration issues.

Understanding the Components

After you set up OpenSSH on your NetWare server, it should contain the components listed in Table 2-1 in the indicated locations.

Table 2-1 OpenSSH Component Locations






OpenSSH version 3.6p1 ported to NetWare 6.5

This is the daemon for the SSH program. It provides secure encrypted communications between two untrusted hosts over an insecure network

This daemon listens for the connections from clients



System-wide configuration file for the SSH daemon. The daemon reads the configuration file and executes the commands it receives based on the file's settings

You can edit this file manually or through the Web administration utility. For more information, see Editing the Configuration File



Private host key used to authenticate the server for the SSH protocol versions 1.3 and 1.5



Private host key used to authenticate the server for the SSH protocol version 2.0 using RSA encryption



Private host key used to authenticate the server for the SSH protocol version 2.0 using DSA encryption



Secure Shell JNI Web support



Secure Shell log daemon that generates the sshd.log file, which contains all errors sent from all ssh-type NLM™ programs such as sshd, ssh, sftp, and scp

This NLM is not a standard ssh file. This ssh module only exists on the NetWare platform



Adds a user plus the user’s public key to the local secret store bag



Deletes a user from the local secret store bag



Lists users in the local secret store bag

Editing the Configuration File

The sshd_config file is located in sys\etc\ssh\. You can edit this file manually with any text editor. If your server has been set up with a DNS name, you can make changes to the file using the OpenSSH Admin utility.

We recommend making changes to the configuration using the OpenSSH Manager (OpenSSH Admin) utility because it eliminates syntax errors that you might make editing the file manually. If you manage OpenSSH on multiple servers, we recommend using this utility to import the configuration file to the eDirectory 8.7.3 mode and then also managing the configuration with the utility.

IMPORTANT:The Apache Admin utility must be installed and set up in order to use the OpenSSH Admin utility.

To access this utility from a browser (Netscape* 6.x or later or IE 5.5 or later):

  1. Enter https://ip_address or server_dns_name:2200, then click the SSHD Admin link under the OpenSSH Server heading.

  2. Type the password information.

  3. Ensure the information automatically inserted into the following fields is applicable to the user and server that you want to log in to:

    • User Name

    • LDAP Provider Domain Name

    • Port Number 636 (or whatever it has been changed to)

    • The Use SSL Connection check box (checked)

      If this check box is not checked, your password to log in to sshd will be exposed in clear text.

    • The initial LDAP context

Changing the Options

The following table shows the options that you can change in the sshd_config file and the links that you can use for them in the OpenSSH Admin utility. All keyword purposes and options are specified in the sshd_config man pages unless they are specific to a NetWare implementation.

Table 2-2 sshd_config Options



Link in Admin Utility


Specifies whether or not sshd should allow SSH console session access.

The default is Yes.



Path to the file that contains the authorized keys.

The default is .ssh\authorized _keys.



Challenges the user to supply authentication credentials. If the user responds with correct credentials, authentication is allowed. This is currently the only way to authenticate to a NetWare server with OpenSSH.

The default is Yes.



Number of client alive messages that can be sent without sshd requiring any messages back from the client. If this threshold is reached while client alive messages are being sent, sshd disconnects the client, terminating the session.

This is very different from KeepAlive. The client alive messages are sent through the encrypted channel and, therefore, are not spoofable. Messages sent by KeepAlive are spoofable.

The client alive mechanism is valuable when the client or server depends on knowing when a connection has become inactive.

If ClientAliveCountMax is set to 2, unresponsive SSH clients are disconnected after approximately 30 seconds.

If ClientAliveInterval is set to 15, and ClientAliveCountMax is left at the default, unresponsive SSH clients are disconnected after approximately 45 seconds.

The default is 3.



Timeout interval (in seconds) after which, if no data has been received from the client, sshd sends a message through the encrypted channel to request a response from the client.

The default is 0 (no messages sent).

This option applies to protocol version 2 only.



Enables or disables compression, which reduces traffic on a low-bandwidth connection.

The default is Yes (enabled).



Enables or disables multi-server navigation.

If set to Yes, a server name is added to the path, as in /servername/volume/dir_path.

If set to No, the path is /volume/dir_path.

The default is Yes (enabled).

File System


Search context. Use this to expand or limit access to the tree.

To enable users in this context only to authenticate to sshd: o=org

To allow users in this context and all subcontexts to authenticate to sshd: o=org?scope=subtree

To search for a user in multiple contexts: context context?scope=subtree

This setting is unique to a NetWare implementation.



These keys are generated during the OpenSSH installation on NetWare:




Host Keys


Specifies whether sshd should ignore the user’s home directory unless on the destination server.

The default is No.

File System


Specifies whether sshd should ignore the user’s $home/.ssh/known_hosts file during RhostsRSAAuthentication or HostbasedAuthentication.

This file contains a copy of the key that the host sent the last time a connection was made. If the file is not ignored, the server prompts the user every time that user attempts to connect, asking whether the key should be accepted.

The default is No.



Specifies whether the system should send TCP keepalive messages to the other side. If they are sent, events such as the termination of the connection or the crash of one of the machines are noticed. However, this means that connections terminate if the route is down temporarily. The client detects whether the network goes down or the remote host crashes.

The default is Yes.



Time (in seconds) between regeneration of keys. This prevents decrypting captured sessions by later breaking into the machine and stealing the keys. The key is never stored anywhere. If the value is 0, the key is never regenerated.

The default is 3600.



Address for the SSH client to listen on.

The default is

Listen Address


Path to a file that contains a greeting or specific banner text that displays when the user logs in to the server using an SSH client.

Recommended path: sys:\etc\ssh

The default is None.



Time interval (in seconds) before the server disconnects if the user has not successfully logged in. If the value is set to 0, there is no time limit.

The default is 600.



Verbosity level that is used when logging messages from sshd.

The default is Info.

Log Preferences


Size (in MB) for the log files.

The default is 4.

This setting is unique to a NetWare implementation.

Log Preferences


Maximum time (in hours) for logging to occur in one file if the default size is not reached.

The default is 7.

This setting is unique to a NetWare implementation.

Log Preferences


Path to the log file. The recommended location is sys:\etc\ssh\logs.

This setting is unique to a NetWare implementation.

Log Preferences


Maximum time (in hours) for logging to occur in one file if the default size is not reached.

The default is 24.

This setting is unique to a NetWare implementation.

Log Preferences


Uses a username and password to verify a user’s identity. This is currently the only way to authenticate to a NetWare server with OpenSSH. Even if you do not select Yes to enable Password Authentication, Password Authentication is still used for NetWare servers.

The default is Yes.



Port for SSH to listen on.

The default is Port 22.

Listen Ports


Versions of the SSH protocol that are supported.


ProxyName username ProxyPassword password

Specifies the proxy user and password for LDAP searches. This is useful when anonymous binds are disabled. The username must be in fully-qualified LDAP format; for example, cn=admin,o=novell.



Uses cryptographic keys to verify a user’s identity. A public key is stored on the server. When a user attempts to authenticate, that user’s private key is verified against the public key to authenticate the user. This is currently the only way to authenticate to a NetWare server with OpenSSH.

The default is Yes.



Allows/disables authentication using identity keys encoded with the Rivest-Shamir-Adleman (RSA) algorithm. This is currently the only way to authenticate to a NetWare server with OpenSSH.

The default is Yes.

This option applies to protocol version 1 only.



Number of bits in the ephemeral protocol version 1 server key. The larger the number of bits, the more secure the key is. If the server detects a change in this number, there could possibly be a security breech.

The default is 768.



Specifies whether sshd should try to verify the remote hostname and whether the authentication request is coming from the IP address it claims to be coming from.

The default is No.


2.1.2 Public/Private Key Security Risks

Supporting public/private key authentication in OpenSSH introduces some security issues that you need to be aware of.

One User Can Masquerade as Another

A user could use SSH to send his key with the Fully Distinguished Name (FDN) of another user to gain access to the system as the other user.

For example, say you are user Sally on Linux system Foo and you want to ssh into NetWare system Bar with the intent of gaining admin permissions. On Foo, you generate ssh keys as Sally. On Bar, you add those keys into the local secret store with the Admin user’s FDN using the following command:

ssh-pubuadd -n cn=admin,o=novell -k ./sally.pub

This example assumes that the administrator of Bar has previously added Admin into the secure bag and that the password was set in a previous session.

Now, on Foo, you can enter the following command to gain the eDirectory permissions of the Admin user:

sftp cn=admin,o=novell@bar

To counter this threat, NetWare administrators must do the following:

  • Verify that the user’s FDN matches the name of the user before adding the FDN and key into the secure bag.

  • Secure the console so that commands such as ssh-pubuadd can not be run by unauthorized users.

Secure Bag Maintenance

The ssh daemon secure bag, sshd.bag, can not be copied to another server. It is good practice to save a copy of the sshd.bag file for migration to other servers or in the unlikely case of bag file corruption.

  • To export the secure bag information to a backup text file, enter the following command:

    ssh-pubulist -b > sshd-bag.bak

    The resulting text file does not contain passwords. They will have to be re-entered in another interactive session.

  • To import entries from the backup file into a new secure bag, enter the following command:

    ssh-pubuadd -b ./sshd-bag.bak