Difference between revisions of "OpenSSH on NetWare"

From MicroFocusInternationalWiki
Jump to: navigation, search
m
Line 16: Line 16:
 
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:
 
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]<br>
+
::[SYS:ETC\SSHD\SSHD_CONFIG]<br>
eDirNameContext OU=Users.O=You?subtree<br>
+
::eDirNameContext OU=Users.O=You?subtree<br>
eDirNameContext OU=Servers.O=You
+
::eDirNameContext OU=Servers.O=You
  
 
=== Public Key authentication ===
 
=== Public Key authentication ===
Line 28: Line 28:
 
If you set up OpenSSH to dump DEBUG logs you'll see what the problem is. Here is an example:
 
If you set up OpenSSH to dump DEBUG logs you'll see what the problem is. Here is an example:
  
 +
<pre>
 
31 Aug - 10:49:35[0031427875] <137> debug1: userauth-request for user corwin service ssh-connection method publickey<br>
 
31 Aug - 10:49:35[0031427875] <137> debug1: userauth-request for user corwin service ssh-connection method publickey<br>
 
31 Aug - 10:49:35[0031427875] <137> debug1: attempt 1 failures 1<br>
 
31 Aug - 10:49:35[0031427875] <137> debug1: attempt 1 failures 1<br>
Line 34: Line 35:
 
31 Aug - 10:49:35[0031427875] <137> debug1: trying public key file /.ssh/authorized_keys<br>
 
31 Aug - 10:49:35[0031427875] <137> debug1: trying public key file /.ssh/authorized_keys<br>
 
31 Aug - 10:49:35[0031427875] <137> debug1: trying public key file /.ssh/authorized_keys<br>
 
31 Aug - 10:49:35[0031427875] <137> debug1: trying public key file /.ssh/authorized_keys<br>
 +
</pre>
  
Which shows that it is attempting to find the "authorized_keys" file. Unfortunately, at this point in things
+
Which shows that it is attempting to find the <b>authorized_keys</b> file. Unfortunately, at this point in the process,
the SSHD.NLM process doesn't know what context the user belongs in, and hasn't done the HOME_DIRECTORY lookup
+
the SSHD.NLM server doesn't know the context of the user, and hasn't determined the user's <b>HOME_DIRECTORY>/b>.
yet. So it has no way of even getting to the %HOME_DIRECTORY\.ssh\authorized_keys file. So, it fails this
+
It has no way of even finding and opening the <b>%HOME_DIRECTORY\.ssh\authorized_keys,</b> file. So, it fails this,
and we head to keyboard-interactive. It then takes the password and then does the login:
+
and we fall back to keyboard-interactive. SSHD.NLM then takes the credentials it was given and does the login:
  
 +
<pre>
 
31 Aug - 10:49:38[0031427932] <0> debug3: authorize_sftp(corwin) calling create_identity(NULL, 'cn=corwin<context>', <password>, NULL, XPORT_TCP, 71c4940c)<br>
 
31 Aug - 10:49:38[0031427932] <0> debug3: authorize_sftp(corwin) calling create_identity(NULL, 'cn=corwin<context>', <password>, NULL, XPORT_TCP, 71c4940c)<br>
 
31 Aug - 10:49:38[0031427941] <0> debug3: authorize_sftp(corwin) create_identity succeeded identity = 10001.<br>
 
31 Aug - 10:49:38[0031427941] <0> debug3: authorize_sftp(corwin) create_identity succeeded identity = 10001.<br>
Line 45: Line 48:
 
31 Aug - 10:49:39[0031427951] <0> debug3: authorize_sftp(corwin) NXCreatePathContext succeeded.<br>
 
31 Aug - 10:49:39[0031427951] <0> debug3: authorize_sftp(corwin) NXCreatePathContext succeeded.<br>
 
31 Aug - 10:49:39[0031427951] <0> debug3: authorize_sftp() setcwd succeeded for corwin. User authenticated. rc = 0<br>
 
31 Aug - 10:49:39[0031427951] <0> debug3: authorize_sftp() setcwd succeeded for corwin. User authenticated. rc = 0<br>
 +
</pre>
  
 
The function calls "[http://developer.novell.com/ndk/doc/libc/libc_vol2/data/ahizgzk.html create_identity]" and  
 
The function calls "[http://developer.novell.com/ndk/doc/libc/libc_vol2/data/ahizgzk.html create_identity]" and  
 
"[http://developer.novell.com/ndk/doc/libc/libc_vol1/data/ag04dy2.html NXCreatePathContext]" are LibC calls  
 
"[http://developer.novell.com/ndk/doc/libc/libc_vol1/data/ag04dy2.html NXCreatePathContext]" are LibC calls  
that perform the connection to the %HOME_DIRECTORY% volume. If this part fails, the keyboard-interactive
+
that perform the connection to Volume specified in the <b>%HOME_DIRECTORY%</b> Property of the User Object.  
login fails and prompts for another password. In the above this works.
+
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
 
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,
+
home-directory only <u>after</u>  authentication credetials (login ID and password) have been provided.  
it can not look up a %HOME_DIRECTORY%\.ssh\authorized_keys file until it
+
Therefore, the SSH server cannot look in a <b>%HOME_DIRECTORY%\.ssh\authorized_keys</b> file until it
already has a username and password. Therefore, public-key does not, and
+
already has a username and password. Therefore, public-key authentication does not, and
probably will never, work.
+
probably will never, work in the <u>stock</u> 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
+
In order to make it work, Novell has to rebuild OpenSSH on NetWare to
 
handle permissions quite differently.
 
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
+
* SSHD.NLM will have to run as a specific user
** This username and password will most likely reside in plain-text in the SYS:ETC\SSH\SSHD_CONFIG file
+
** This user ID would need READ filesystem rights to all possible <b>%HOME_DIRECTORY%\.ssh\authorized_keys</b> locations
* Perform the %HOME_DIRECTORY% lookup earlier
+
** The credentials for this ID would need to be accessible to SSHD.NLM, perhaps embedded in <b>SYS:ETC\SSH\SSHD_CONFIG</b>
* Create an NMAS module to permit logins with SSH-generated RSA keys
+
* The <b>%HOME_DIRECTORY%</b> would have to be done earlier in the authentication process
* 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
+
* An NMAS module would be needed to permit logins with SSH-generated RSA keys
 +
* The a 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)
  
 
==== Recent changes ====
 
==== Recent changes ====
A new version of OpenSSH for NetWare was posted to the [http://forge.novell.com/modules/xfmod/project/?openssh 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:
+
A new version of OpenSSH for NetWare was posted to the [http://forge.novell.com/modules/xfmod/project/?openssh 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:
<pre>These limitations are:
+
 
1. Public keys are placed in the local secret store, sshd.bag.  
+
These limitations are:
2. The AuthorizedKeysFile configuration file setting is not used.   
+
 
3. Users home directory authorized_keys file will not be supported.
+
# Public keys are placed in the local secret store, '''sshd.bag'''  
4. Users credentials, user name, password and public key must be in the  
+
# The <b>AuthorizedKeysFile</b> configuration file setting is not used.   
    local secret store bag.
+
# User's home directory <b>authorized_keys</b> file will not be supported.
5. Remote login must use full DN
+
# User's credentials, user name, password and public key must be in the local secret store bag.
6. sshd.bag can only be read by the server it was created on, it can not be  
+
# Remote login must use full DN
    moved to another server
+
# <b>sshd.bag</b> can only be read by the server it was created on, it cannot be moved to another server
7. ProxyUser must be specified in sshd_config</pre>
+
# <b>ProxyUser</b> must be specified in <b>sshd_config</b>
 +
 
 
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.
  
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.
+
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.
  
 
[[Category:NetWare]]
 
[[Category:NetWare]]

Revision as of 15:34, 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<br>
31 Aug - 10:49:35[0031427875] <137> debug1: attempt 1 failures 1<br>
31 Aug - 10:49:35[0031427875] <137> debug2: input_userauth_request: try method publickey<br>
31 Aug - 10:49:35[0031427875] <137> debug1: test whether pkalg/pkblob are acceptable<br>
31 Aug - 10:49:35[0031427875] <137> debug1: trying public key file /.ssh/authorized_keys<br>
31 Aug - 10:49:35[0031427875] <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>/b>. It has no way of even finding and opening the <b>%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[0031427932] <0> debug3: authorize_sftp(corwin) calling create_identity(NULL, 'cn=corwin<context>', <password>, NULL, XPORT_TCP, 71c4940c)<br>
31 Aug - 10:49:38[0031427941] <0> debug3: authorize_sftp(corwin) create_identity succeeded identity = 10001.<br>
31 Aug - 10:49:38[0031427941] <0> debug3: authorize_sftp(corwin) calling NXCreatePathContext(NULL, '<homedir>', NX_PNF_NKS, 10001, 71c49410)<br>
31 Aug - 10:49:39[0031427951] <0> debug3: authorize_sftp(corwin) NXCreatePathContext succeeded.<br>
31 Aug - 10:49:39[0031427951] <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. Therefore, 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
    • 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
  • The %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 a 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)

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 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:

  1. Public keys are placed in the local secret store, sshd.bag
  2. The AuthorizedKeysFile configuration file setting is not used.
  3. User's home directory authorized_keys file will not be supported.
  4. User's 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 cannot 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.