It doesn't look like OpenSSH on NetWare can do key-exchange authentication! Looking at the debug files, I'm not sure it knows where to find 'authorized_keys' in userland at that point in the checking. It does the lookup for the end-users environment after authentication is completed and it is setting up the environment. There are log-lines that point to checking...
31 Aug - 10:49:35[0031427875] <137> debug1: userauth-request for user riedesg 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
But it doesn't seem to find it. Later on in the log-files, you get this:
31 Aug - 10:49:38[0031427932] <0> debug3: authorize_sftp(riedesg) calling create_identity(NULL, 'cn=riedesg<context>', <password>, NULL, XPORT_TCP, 71c4940c)
31 Aug - 10:49:38[0031427941] <0> debug3: authorize_sftp(riedesg) create_identity succeeded identity = 10001.
31 Aug - 10:49:38[0031427941] <0> debug3: authorize_sftp(riedesg) calling NXCreatePathContext(NULL, '<homedir>', NX_PNF_NKS, 10001, 71c49410)
31 Aug - 10:49:39[0031427951] <0> debug3: authorize_sftp(riedesg) NXCreatePathContext succeeded.
31 Aug - 10:49:39[0031427951] <0> debug3: authorize_sftp() setcwd succeeded for riedesg. User authenticated. rc = 0
Which is the point where it actually creates a connection to the home-directory with intent to access files. Since this step happens AFTER authentication, I must presume that it can't access said home-directory before auth. It clearly connects to the remote resource with the user's credentials, and those don't exist before authentication.
So it looks like key-exchange can't be done with netware. At least, with end-user supplied keys. It may be possible with system-configed keys, but my ssh-fu is too weak to try that out right now.
31 Aug - 10:49:35[0031427875] <137> debug1: userauth-request for user riedesg 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
But it doesn't seem to find it. Later on in the log-files, you get this:
31 Aug - 10:49:38[0031427932] <0> debug3: authorize_sftp(riedesg) calling create_identity(NULL, 'cn=riedesg<context>', <password>, NULL, XPORT_TCP, 71c4940c)
31 Aug - 10:49:38[0031427941] <0> debug3: authorize_sftp(riedesg) create_identity succeeded identity = 10001.
31 Aug - 10:49:38[0031427941] <0> debug3: authorize_sftp(riedesg) calling NXCreatePathContext(NULL, '<homedir>', NX_PNF_NKS, 10001, 71c49410)
31 Aug - 10:49:39[0031427951] <0> debug3: authorize_sftp(riedesg) NXCreatePathContext succeeded.
31 Aug - 10:49:39[0031427951] <0> debug3: authorize_sftp() setcwd succeeded for riedesg. User authenticated. rc = 0
Which is the point where it actually creates a connection to the home-directory with intent to access files. Since this step happens AFTER authentication, I must presume that it can't access said home-directory before auth. It clearly connects to the remote resource with the user's credentials, and those don't exist before authentication.
So it looks like key-exchange can't be done with netware. At least, with end-user supplied keys. It may be possible with system-configed keys, but my ssh-fu is too weak to try that out right now.