ssh publickey auth w/ kerb

[Whitehead, Brian]

I'm thinking of the server being ssh'd to ask a kerberos client, because
it is authenticating the user against the AD server using kerberos.  

This morning the other admin believes he has discovered the problem with
the ssh keys being ignored.  He looked at the pam_unix_account source
code and found that the behavior for locked accounts has changed.  He
had been using *LK* in the password field of local accounts on the
Solaris 8 servers and it worked fine.  Apparently with Solaris 10, the
behavior changed and changing to use *NP* or anything other than *LK*
resolved the problem.  

Thanks for responding.  If you do know of any step-by-step instructions
on setting this up on both the AD and Solaris 10 side, please let me
know.

Regards,
Brian

> -----Original Message-----
> From: Douglas E. Engert [mailto:deengert at anl.gov] 
> Sent: Monday, June 02, 2008 11:13 AM
> To: Whitehead, Brian
> Cc: kerberos at mit.edu
> Subject: Re: ssh publickey auth w/ kerb
> 
> 
> 
> Brian Whitehead wrote:
> > Using ssh -vvv shows that the public key is working, but no matter 
> > what I'm prompted for a  password.
> > 
> > Also, is a keytab file from the AD server with the client principal 
> > absolutely necessary?
> 
> With the client? No. Keytab normally have service principals, 
> used by server applicaiton to accept requests. Users normally 
> don't store long term secrets in keytabs, but use a password 
> to get tickets.
> 
> > We have several Solaris 8 clients that work without a keytab.  The 
> > Solaris 10 clients authenticate fine and accept the 
> password, but the 
> > verbose authentication output always complains about the 
> "Server not 
> > found in kerberos database".
> 
> That sounds line the ssh client sees that the user has 
> Kerberos tickets, and is trying to use GSSAPI which would not 
> require the password to be entered again. Coiuld also be user 
> did not give a FQDN, on the ssh command line, or the server 
> principal is not in the KDC so the ssh client falls back to 
> using passwords. It could also mean that the client's 
> krb5.conf [domain_realm] section is not configured correctly, 
> or DNS is not configured correctly.
> 
> This could also mean that you are missing a verification of 
> the ticket obtained using when using the password. See the 
> Solaris 10 man page for krb5.conf and look at the 
> verify_ap_req_nofail option.
> 
> > The admin working on
> > this project doesn't, since he never had to put it on the Solaris 8 
> > hosts.  Again, the password does work and completes the login.
> > 
> > I'm looking for some very direct step-by-step instructions 
> on setting 
> > up Solaris 10 as a client against AD.  There is a ton of 
> documents out 
> > there, but they're very long and not very direct.
> 
> Not sure what you mean by "client of AD" In Kerberos terms, 
> there are clients (usually people) that have user principals 
> and servers like sshd that use keytabs, and have service principals.
> 
> > 
> > Thanks in advance for any help.
> > 
> > Regards,
> > Brian
> > ________________________________________________
> > Kerberos mailing list           Kerberos at mit.edu
> > https://mailman.mit.edu/mailman/listinfo/kerberos
> > 
> > 
> 
> -- 
> 
>   Douglas E. Engert  <DEEngert at anl.gov>
>   Argonne National Laboratory
>   9700 South Cass Avenue
>   Argonne, Illinois  60439
>   (630) 252-5444
>