OpenSSH on NetWare

From MicroFocusInternationalWiki
Revision as of 18:15, 8 November 2005 by Gracal (Talk | contribs) (Original entry, feel free to spell and grammar check it.)

(diff) ← Older revision | Latest revision (diff) | Newer revision → (diff)
Jump to: navigation, search

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.

Public Key authentication

Public Key authentication does not work in NetWare, and may very well not ever work. This has to do with 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[0031427875] <137> debug1: userauth-request for user corwin service ssh-connection method publickey
31 Aug - 10:49:35[0031427875] <137> debug1: attempt 1 failures 1
31 Aug - 10:49:35[0031427875] <137> debug2: input_userauth_request: try method publickey
31 Aug - 10:49:35[0031427875] <137> debug1: test whether pkalg/pkblob are acceptable
31 Aug - 10:49:35[0031427875] <137> debug1: trying public key file /.ssh/authorized_keys
31 Aug - 10:49:35[0031427875] <137> debug1: trying public key file /.ssh/authorized_keys

Which shows that it is attempting to find the "authorized_keys" file. Unfortunately, at this point in things the SSHD.NLM process doesn't know what context the user belongs in, and hasn't done the HOME_DIRECTORY lookup yet. So it has no way of even getting to the %HOME_DIRECTORY\.ssh\authorized_keys file. So, it fails this and we head to keyboard-interactive. It then takes the password and then does the login:

31 Aug - 10:49:38[0031427932] <0> debug3: authorize_sftp(corwin) calling create_identity(NULL, 'cn=corwin<context>', <password>, NULL, XPORT_TCP, 71c4940c)
31 Aug - 10:49:38[0031427941] <0> debug3: authorize_sftp(corwin) create_identity succeeded identity = 10001.
31 Aug - 10:49:38[0031427941] <0> debug3: authorize_sftp(corwin) calling NXCreatePathContext(NULL, '<homedir>', NX_PNF_NKS, 10001, 71c49410)
31 Aug - 10:49:39[0031427951] <0> debug3: authorize_sftp(corwin) NXCreatePathContext succeeded.
31 Aug - 10:49:39[0031427951] <0> debug3: authorize_sftp() setcwd succeeded for corwin. User authenticated. rc = 0

The function calls "create_identity" and "NXCreatePathContext" are LibC calls that perform the connection to the %HOME_DIRECTORY% volume. 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 it already has a login and password. Therefore, it can not look up a %HOME_DIRECTORY%\.ssh\authorized_keys file until it already has a username and password. Therefore, public-key does not, and probably will never, work.

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 user with READ rights to all possible %HOME_DIRECTORY%\.ssh\authorized_keys locations
    • This username and password will most likely reside in plain-text in the SYS:ETC\SSH\SSHD_CONFIG file
  • Perform the %HOME_DIRECTORY% lookup earlier
  • Create an NMAS module to permit logins with SSH-generated RSA keys
  • Create a way to make a new SFTP-SRVR.NLM thread that runs under the permissions of the user logging in, not under the permissions of SSHD.NLM which are broad

This is a pretty major rewrite, and there is no word on if it is ever going to be undertaken.