OpenSSH on NetWare
OpenSSH on NetWare -- Gotchas
OpenSSH on NetWare works, but it has a few issues that can trip up the unwary.
'CN' and uniqueness
OpenSSH looks up incoming userID's by querying for the "CN" value. This value is not unique by default, and this can cause problems. OpenSSH will stop searching for users at the first returned match. So if you have multiple "SmithR" users in various contexts, only one will ever be able to use OpenSSH on NetWare.
Unable to see anything once logged in
This is typically caused by the OpenSSH server not being included in an 'eDirNameContext' entry in the sshd_config file. The cause of this is not clear, but the symptoms are pretty clear:
- You can log in, but you can't list any files
- You can log in, but you can't change directory anywhere. Even to places you know you have rights.
Happily, the fix is very simple. Just add another 'eDirNameContext' line to your SYS:ETC\SSHD\SSHD_CONFIG file to include the contect your server-object is in:
- eDirNameContext OU=Users.O=You?subtree
- eDirNameContext OU=Servers.O=You
Public Key authentication
Public Key authentication does not work in NetWare, and may very well not ever work as a supported access method. This issue is how the SSHD.NLM process is loaded and how it handles the connection to the user's home directory.
If you set up OpenSSH to dump DEBUG logs you'll see what the problem is. Here is an example:
31 Aug - 10:49:35 <137> debug1: userauth-request for user corwin service ssh-connection method publickey<br> 31 Aug - 10:49:35 <137> debug1: attempt 1 failures 1<br> 31 Aug - 10:49:35 <137> debug2: input_userauth_request: try method publickey<br> 31 Aug - 10:49:35 <137> debug1: test whether pkalg/pkblob are acceptable<br> 31 Aug - 10:49:35 <137> debug1: trying public key file /.ssh/authorized_keys<br> 31 Aug - 10:49:35 <137> debug1: trying public key file /.ssh/authorized_keys<br>
Which shows that it is attempting to find the authorized_keys file. Unfortunately, at this point in the process, the SSHD.NLM server doesn't know the context of the user, and hasn't determined the user's HOME_DIRECTORY. It has no way of even finding and opening the %HOME_DIRECTORY\.ssh\authorized_keys, file. So, it fails this, and we fall back to keyboard-interactive. SSHD.NLM then takes the credentials it was given and does the login:
31 Aug - 10:49:38 <0> debug3: authorize_sftp(corwin) calling create_identity(NULL, 'cn=corwin<context>', <password>, NULL, XPORT_TCP, 71c4940c)<br> 31 Aug - 10:49:38 <0> debug3: authorize_sftp(corwin) create_identity succeeded identity = 10001.<br> 31 Aug - 10:49:38 <0> debug3: authorize_sftp(corwin) calling NXCreatePathContext(NULL, '<homedir>', NX_PNF_NKS, 10001, 71c49410)<br> 31 Aug - 10:49:39 <0> debug3: authorize_sftp(corwin) NXCreatePathContext succeeded.<br> 31 Aug - 10:49:39 <0> debug3: authorize_sftp() setcwd succeeded for corwin. User authenticated. rc = 0<br>
The function calls "create_identity" and "NXCreatePathContext" are LibC calls that perform the connection to Volume specified in the %HOME_DIRECTORY% Property of the User Object. If this part fails, the keyboard-interactive login fails and prompts for another password. In the above this works.
Note the timing by looking at the seconds in the log-snips. It creates the connection to the destination home-directory only after authentication credetials (login ID and password) have been provided. Therefore, the SSH server cannot look in a %HOME_DIRECTORY%\.ssh\authorized_keys file until it already has a username and password. The bottom line is that public-key authentication does not, and probably will never, work in the stock OpenSSH port on NetWare (OES-Linux and SLES/SUSE are not affected).
In order to make it work, Novell has to rebuild OpenSSH on NetWare to handle permissions quite differently.
- SSHD.NLM will have to run as a specific user ID:
- This user ID would need READ filesystem rights to all possible %HOME_DIRECTORY%\.ssh\authorized_keys locations
- The credentials for this ID would need to be accessible to SSHD.NLM, perhaps embedded in SYS:ETC\SSH\SSHD_CONFIG (a la the Remote Console password in LDRCONAG.NCF)
- The determination of %HOME_DIRECTORY% would have to be done earlier in the authentication process
- An NMAS module would be needed to permit logins with SSH-generated RSA keys
- The new SFTP-SRVR.NLM thread must be able to switch authentication context to thart of the user logging in, and not remain authenticated with the permissions of SSHD.NLM (which are too broad)
A new version of OpenSSH for NetWare was posted to the forge as of Feb 18, 2006. This version is the very first to support Public Key authentication, but not in the form recognized by most people. It is a hack, but at least it permits it. From the Readme:
These limitations are:
- Public keys are placed in the local secret store, sshd.bag
- The AuthorizedKeysFile configuration file setting is not used.
- User's home directory authorized_keys file will not be supported.
- User's credentials, user name, password and public key must be in the local secret store bag.
- Remote login must use full DN
- sshd.bag can only be read by the server it was created on, it cannot be moved to another server
- ProxyUser must be specified in sshd_config
While the challenges of implementing this for all end-users are non-trivial, it can be used for system processes such as moving data to/from NetWare securely.
Note: the LDAP name matching when using the ssh-pubuadd tool in this new version is case-sensitive, so if LDAP reports your user as cn=Admin,o=Novell, it will not match cn=admin,o=novell on the command-line. You can use the -d switch with ssh-pubuadd to see the LDAP queries.