ssh publickey auth w/ kerb - Kerberos
This is a discussion on ssh publickey auth w/ kerb - Kerberos ; 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? We have several Solaris 8 clients ...
-
ssh publickey auth w/ kerb
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? 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". 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.
Thanks in advance for any help.
Regards,
Brian
-
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@mit.edu
> https://mailman.mit.edu/mailman/listinfo/kerberos
>
>
--
Douglas E. Engert
Argonne National Laboratory
9700 South Cass Avenue
Argonne, Illinois 60439
(630) 252-5444
-
RE: ssh publickey auth w/ kerb
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@anl.gov]
> Sent: Monday, June 02, 2008 11:13 AM
> To: Whitehead, Brian
> Cc: kerberos@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@mit.edu
> > https://mailman.mit.edu/mailman/listinfo/kerberos
> >
> >
>
> --
>
> Douglas E. Engert
> Argonne National Laboratory
> 9700 South Cass Avenue
> Argonne, Illinois 60439
> (630) 252-5444
>
-
Re: ssh publickey auth w/ kerb
"Whitehead, Brian" writes:
> 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.
Are you considering the ssh server to be a Kerberos client? While
that may be a valid interpretation, please be aware that in the
context of a Kerberos-authenticated ssh connection, the usual
terminology refers to the ssh server as the application server, and to
the ssh client as be both the application client and the Kerberos
client. To better distinguish between the Kerberos server and the
application server, we usually call the Kerberos server itself the KDC
(Key Distribution Center).
-
RE: ssh publickey auth w/ kerb
Thank you for the clarification.
Brian
> -----Original Message-----
> From: Tom Yu [mailto:tlyu@MIT.EDU]
> Sent: Monday, June 02, 2008 1:55 PM
> To: Whitehead, Brian
> Cc: Douglas E. Engert; kerberos@MIT.EDU
> Subject: Re: ssh publickey auth w/ kerb
>
> "Whitehead, Brian" writes:
>
> > 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.
>
> Are you considering the ssh server to be a Kerberos client?
> While that may be a valid interpretation, please be aware
> that in the context of a Kerberos-authenticated ssh
> connection, the usual terminology refers to the ssh server as
> the application server, and to the ssh client as be both the
> application client and the Kerberos client. To better
> distinguish between the Kerberos server and the application
> server, we usually call the Kerberos server itself the KDC
> (Key Distribution Center).
>