Frank,
I don't know if this is the correct list for this question (you are correct,
it is an OS issue, not an ssh one), but just as a quick answer to your
question, you should be able to define the order in /etc/security/user in
the "default" stanza. Look for the value of "SYSTEM". If
you are using
Quest's VAS product, it should say something like "VAS or compat".
This
will normally tell the OS to try the VAS module first, then the compat
module (which is shorthand for "NIS OR files" or "files OR
NIS" I can't
remember the order off the top of my head). You should be able to switch to
"compat OR VAS" if you want local and NIS users to be tried before VAS
users
and vice versa.
Jason Burns
Information Security Technology
Cryptography Services -> Secure Communications and Data Encryption
> -----Original Message-----
>
> I'm trying to get to the bottom of an issue with key
> authentication on AIX and I'm not sure I believe IBM's answer
> so I thought I'd post here to see what answer I'd get from
> the SSH side.
>
> We have three different methods of authentication - local,
> VAS (AD), NIS. On our Linux and Solaris servers it's very
> simple to set the authentication order with nsswitch.conf and
> SSH follows that order on those systems without any issues -
> even with key-authentication. On AIX however if we use
> key-authentication it always hits NIS before VAS. IBM is
> telling us that it is because that's how SSH works and we
> keep trying to tell them that it doesn't work like that
> anywhere else - only on AIX.
> It's my understanding that SHH will authenticate in the order
> established by the OS and not vice-versa - is this thinking correct?
>
> We have workarounds for the issue, but we'd like to have IBM
> own up to what we perceive as a flaw in their authentication
> model instead of blaming it on how SSH works.
>
> Here is the latest from their developers:
>
> "Discussed about the SSH design.
> As we are copying the public key in the /home/(user). So in
> this case authentication is done by the SSH Server. But in
> case of password authenticationNIS server or VAS server is
> doing the authentication.
> Therefore in the password case it is able to differentiate
> between NIS and VAS user.
> But in case of Public Key Authentication it is first taking
> the NIS user and then server is doing the authentication.
> So it is not able to differentiate between the two users in
> case of PUBLIC KEY AUTHENTICATION."
>
> My belief is even with key-authentication SSH still has to
> have the user account validated by the OS and that the order
> in which this validation will occur is determined by the OS
> not the SSH server. At least this is what happens on our
> other operating systems - we can switch the authentication
> order and it will authenticate to which ever option is first.
>
> Thanks,
> Frank LaMon
>
> -----------------------------------------
> This email transmission and any accompanying attachments may
> contain CSX privileged and confidential information intended
> only for the use of the intended addressee. Any
> dissemination, distribution, copying or action taken in
> reliance on the contents of this email by anyone other than
> the intended recipient is strictly prohibited. If you have
> received this email in error please immediately delete it and
> notify sender at the above CSX email address. Sender and
> CSX accept no liability for any damage caused directly or
> indirectly by receipt of this email.
> _______________________________________________
> openssh-unix-dev mailing list
> openssh-unix-dev at mindrot.org
> https://lists.mindrot.org/mailman/listinfo/openssh-unix-dev
>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: smime.p7s
Type: application/x-pkcs7-signature
Size: 5659 bytes
Desc: not available
Url :
http://lists.mindrot.org/pipermail/openssh-unix-dev/attachments/20080725/7a8a2900/attachment-0001.bin