Difference between revisions of "OpenSSH on NetWare"

From MicroFocusInternationalWiki
Jump to: navigation, search
m (Recent changes)
m
Line 77: Line 77:
 
  6. sshd.bag can only be read by the server it was created on, it can not be  
 
  6. sshd.bag can only be read by the server it was created on, it can not be  
 
     moved to another server
 
     moved to another server
  7. ProxyUser must be sepcified in sshd_config</pre>
+
  7. ProxyUser must be specified in sshd_config</pre>
 
While the challenges of implimenting this for all end-users are non-trivial, it can be used for system processes such as moving data to/from NetWare securely.
 
While the challenges of implimenting this for all end-users are non-trivial, it can be used for system processes such as moving data to/from NetWare securely.
  

Revision as of 14:59, 14 June 2006

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:

[SYS:ETC\SSHD\SSHD_CONFIG]
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. 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

Recent changes

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 encryption, 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:
 1. Public keys are placed in the local secret store, sshd.bag.  
 2. The AuthorizedKeysFile configuration file setting is not used.  
 3. Users home directory authorized_keys file will not be supported.
 4. Users credentials, user name, password and public key  must be in the 
    local secret store bag.
 5. Remote login must use full DN.  
 6. sshd.bag can only be read by the server it was created on, it can not be 
    moved to another server
 7. ProxyUser must be specified in sshd_config

While the challenges of implimenting 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.