Environment
Novell NetWare 6.5 Support Pack 6
Novell NetWare 6.5 Support Pack 7
Novell NetWare 6.5 Support Pack 8
Situation
A key pair is needed so a Windows SFTP client (like putty's psftp.exe, or Filezilla) can use public key authentication to login to a NetWare 6.5 server through SSH.
Resolution
Novell's main TID describing the steps to set up public key authentication with SSH is TID 3297445 - NetWare OpenSSH services - Support for public key authentication. However, that document assumes that the sftp client is a Linux system and its step #1 discusses the Linux method of generating a key pair. This document gives suggestions for Windows sftp clients (but use of the above mentioned TID will still be needed in connection with these efforts).
For best security, end users should create their own key pairs so only they have copies of their private keys. However, that rule of thumb can be difficult to follow if the end user's client does not have a utility to generate keys, or if it generates key pairs in different formats from what OpenSSH expects. (Not all SSH is OpenSSH).
For example, putty (which supplies ssh and sftp clients for windows) has a utility called putty-gen and a key management tool named Pageant, which may be useful for key creation. WinSCP also supplies putty-gen. But these keys are in a *.ppk format and will not import into NetWare's key bag.
Similarly, a private key created by OpenSSH won't import into a client that expects a *.ppk file.
Here are a couple of theoretical approaches that may be useful to get around these concerns. (For discussion of specific client examples, see the "Additional Information" section of this document).
1. NetWare has a "ssh-kgen" utility which can create key pairs. These keys might not be in the format desired by the specific sftp client. If the client accepts the standard OpenSSH format, or can convert it, this approach should work:
a. At the NetWare console, load BASH.
b. At the BASH prompt, execute: ssh-kgen -t rsa -f sys:/etc/ssh/keys/<filename>
Where <filename> is replaced by the base name you desire for your key pair. The username is often a good idea as the filename, so you can keep track of which key pair were created for which users.
The typical reason to use public key authentication is so no user interaction is needed during login. So do not enter a pass phrase when prompted. Just press <enter> instead.
c. There will not be 2 new files in the location specified in item b. If the filename submitted was "bob" the files will be "bob" and "bob.pub". "bob" is the private key, "bob.pub" is the public key. Put a copy of the private key onto the client machine.
d. Follow step 4 of TID 3297445 (linked above) to import the public key into NetWare's SSH.
e. Go to the client sftp software and (through whatever method it provides) specify the location of the private key. If it accepts the key in it's existing format, you should be good to go. If not, it may offer to convert it, which should work as well. The first time you login this way, even after submitting a key, NetWare will prompt for a password. Submit it. NetWare SSHD.NLM will thereby verify your identity against eDirectory and confirm the association of your public key with your eDirectory account.
f. If your sftp client cannot use or convert the private key, then this approach is not for you. You may need to seek advice from the sftp client vendor on how to create RSA key pairs for its use.
2. Just as you might be able to use NetWare's ssh-kgen utility to generate a key pair for a Windows sftp client, you may be able to use other 3rd party utilities as well. For example, you could go to a Linux system and use ssh-keygen to create a pair. (Take care to use a temporary user account, or at least make sure not to overwrite a valid Linux user's key pair with the new pair you are creating). Copy the private key created on Linux to the Windows client, and copy the public key to the NetWare server (i.e. to sys:/etc/ssh/keys/<username>.pub). Then refer to items 1d - 1f above.
Additional Information
Specific Windows Client Examples:
A. OpenSSH for Windows comes with a ssh-keygen utility which creates the right format of keys, for it's use with NetWare.
B. Filezilla, when configured as an SFTP client and using keys, wants a *.ppk style private key, but can convert OpenSSH (ssh-keygen) private keys. To accomplish step '1e' (above) in Filezilla 3.1.3.1, go to the Edit menu -> Settings -> Connections -> SFTP and click "add key file." Point to the private key copied over from NetWare. Filezilla can't use this format but will offer to convert it. Accept the offer, and Filezilla will convert it to a *.ppk file, the same type used by putty.
Then in Filezilla's Site Manager:
- create a site definition for the NetWare SSH server
- for "Logontype" use "Normal"
- for the username, put in the fully qualified NetWare username, case sensitive, in LDAP format. For example: cn=bob,ou=users,o=company
- put the password (for the time being).
- click "Connect".
Filezilla will submit both your private key and your password to NetWare, which should complete the successful login.
Disconnect the session (Filezilla, Server menu --> Disconnect).
Now go back to the site manager again, and remove the password from the site definition. Subsequent attempts to login should be successful even without submitting a password.
To be completely sure public key authentication is working with Filezilla, close Filezilla completely. Then open it back up. Connect to the NetWare site again. You should no longer be prompted for a password, nor should you see any indication in Filezilla's session activity log that it is supplying one for you. I.E. No occurrence of " pass: * " should appear in the session log.
C. WinSCP3: Version 3.8.2 of WinSCP3 tested by Novell did not appear to have a way to save it's own newly created keys in any format other that *.ppk. Also, it did not appear to be able to convert OpenSSH keys to *.ppk format. However, it was able to take a key converted from OpenSSH to *.ppk by the Filezilla process shown above, and use it successfully to log into NetWare OpenSSH.