Environment
Novell NetWare 6.5 SP7
Novell NetWare 6.5 SP6
Novell NetWare 6.5 SP5
Novell Open Enterprise Server (OES) NetWare
OpenSSH SSH SSHD.NLM SFTP SFTP-SVR.NLM SCP
Novell Open Enterprise Server (OES) NetWare
OpenSSH SSH SSHD.NLM SFTP SFTP-SVR.NLM SCP
Situation
NetWare OpenSSH services - Support for public key authentication.
Resolution
NOTE: This document is occasionally updated; the latest version should always be read fully and followed carefully. NetWare's SSH public key authentication method is strict and any variance from this document can result in failures.
Support for public key authentication has been added to NetWare OpenSSH services. If you are using NetWare 6.5 SP6 or later, the necessary updates are already present.
Prerequisite:
Before proceeding to step 1, verify that NetWare SSH is working successfully for your users by have them login without public key authentication. For example, for eDir user .bob.users.company, verify he can login successfully without specifying a context, using:
sftp bob@servername
If the user cannot login this way, then other things need to be corrected before public key authentication can be set up for that user. For example, a successful login will prove that SSHD.NLM is talking to your LDAP service and finding the right user object, which will allow other steps to be successful later.
Note: For the remainder of this document, every time a user name is specified by the steps below, it should be a fully-distinguished name specified in LDAP format.
- do not use any leading dot
- use commas to separate objects, rather than periods
- i.e. cn=username,ou=orgunit,o=organization
1. At the client, while acting as the user whose key you want to generate, generate a RSA key pair. Types other than RSA are not supported.
For example, on Linux, 'su' to the user in question or verify your current identity with 'id'. Then generate the key with:
ssh-keygen -t rsa
Using a pass phrase is optional. If you do not want to enter in a pass phrase every time you use the keys to authenticate, then do not set a pass phrase during key generation. Use of pass phrases may also require additional set up steps on the Linux side to fully implement.
The above command will, by default, put a key pair under the user's home, within a .ssh subdirectory. The public key file is id_rsa.pub, and the private key file is id_rsa.
NOTE: For tips on generating key pairs for Windows clients, see TID 7001519 - NetWare SFTP and public key authentication from Windows Clients.
2. Put a copy of the public key somewhere where the server can access it. For example, call it sys:/etc/ssh/keys/username.pub
Where "username" is replaced with the NetWare user's name.
ssh-pubuadd -n cn=netware_username,ou=orgunit,o=org -k sys:/etc/ssh/keys/username.pub -a cn=admin,o=org
where:
-n specifies the *case-sensitive*, fully distinguished name of the user in LDAP format.
"netware_username" is the NetWare username of the user.
-k specifies the path to the user's public key file, with forward slashes instead of backslashes.
-a is the LDAP FDN of the admin user.
This adds the user and key to SSHD's secret store.
Additional Notes:
(a) The -n user must be within a context specified by a eDirNameContext line in the sys:etc\ssh\sshd_config file. Alternatively, the user can be within the subtree of one of the listed contexts, if ?scope=subtree is included on that eDirNameContext line. For example, both of the following can find users within ou=unit.o=org:
eDirNameContext ou=unit.o=org
or
eDirNameContext o=org?scope=subtree
This parameter can be used repeatedly in order to specify multiple contexts. Also note that besides contexts for the users, contexts for the server and volume objects must also be included.
If the sshd_config file is changed, unload and reload SSHD.NLM to put it into effect.
(b) A proxy user must be set for SSHD to use, instead of using anonymous LDAP bind. The -a in the above example specifies the proxy user, and you will be prompted for that *proxy user's password* upon executing the command. The proxy user should be able to browse eDir to confirm the existence of the user being added. Alternatively, instead of using the -a, a proxy user and password can be set in sys:etc/ssh/sshd_config following the example syntax below. (If the sshd_config file is changed, unload and reload SSHD.NLM to put it into effect.)
# Proxy user and password for ldap searches, useful when
# anon binds are disabled. Name must be fully qualified
ProxyName cn=admin,o=novell
ProxyPassword novpass
# anon binds are disabled. Name must be fully qualified
ProxyName cn=admin,o=novell
ProxyPassword novpass
#(putting the appropriate user in place of "cn=admin,o=novell" and the correct password in place of "novpass".)
sftp cn=netware_username,ou=orgunit,o=org@servername
Note this requires the *case-sensitive*, fully distinguished name (FDN) of the user. The above command will assume it can find the private key file within the .ssh directory, under your current user's home directory. If you are not currently acting as that same user as you did when you generated the key pair, you will need to specify the location of the local private key. The command on Linux is usually in the format:
sftp -oIdentityFile=/home/linux_username/.ssh/id_rsa cn=netware_username,ou=orgunit,o=org@servername
The first time a user connects to NetWare with a key, he or she will still be prompted for the password, so SSHD can add it to the secret store. The second time and beyond, it will no longer prompt for a password, if the above steps have been followed correctly. FYI, if the FDN name with correct case is not used in the client command, public key authentication won't work, and the user will get prompted for the password instead.
If this isn't working and any steps are redone to correct the situation, remember that the next login attempt might still prompt for a password, to finally get the password correctly added to the secret store. After any step is taken to correct an issue, 2 login attempts should be made before concluding that it is still failing.
Additional Information
Additional Troubleshooting tips:
If public key authentication continues to fail despite following the above steps carefully, it is possible that the sys:\etc\ssh\sshd.bag file is corrupt. The file can be deleted and will be recreated when another key is imported with ssh-pubuadd. Keep in mind, however, that deleting this file means all previously imported keys are deleted. All keys will need to be added to the bag again, and then the first subsequent login attempt from any and all of the accounts will require the eDir password be successfully submitted.
Formerly known as TID# 10099625