Russ Allbery <[EMAIL PROTECTED]> writes:
> It looks like this fixes some of the problems, but it still doesn't fix
> the problem for ksu. Running ksu without a domain_realm setting for the
> local hostname fails:
>
> wanderer:~> ksu
> WARNING: Your password may be exposed if you enter it here and are logged
> in remotely using an unsecure (non-encrypted) channel.
> Kerberos password for rra/[EMAIL PROTECTED]: :
> ksu: Wrong principal in request while verifying ticket for server
> Authentication failed.
>
> I'm still trying to figure out why.
Here's the results when ksu is built with debugging support with a small
patch that I'll submit back to make the debugging more useful.
wanderer:~> ./ksu -D
GET_best_princ_for_target: via prompt passwd list choice: approximation of
princ in trials # 0
GET_best_princ_for_target result-best principal rra/[EMAIL PROTECTED]
source cache = FILE:/tmp/krb5cc_1000
target cache = FILE:/tmp/krb5cc_0.1
krb5_check_exp: the krb5_clockskew is 300
krb5_check_exp: currenttime - endtime -82497
krb5_check_exp: the krb5_clockskew is 300
krb5_check_exp: currenttime - endtime -82497
krb5_check_exp: the krb5_clockskew is 300
krb5_check_exp: currenttime - endtime -82497
krb5_auth_check: Client principal name: rra/[EMAIL PROTECTED]
krb5_auth_check: Server principal name: host/wanderer.stanford.edu@
ksu: Matching credential not found While Retrieving credentials
local tgt principal name: krbtgt/[EMAIL PROTECTED]
WARNING: Your password may be exposed if you enter it here and are logged
in remotely using an unsecure (non-encrypted) channel.
Kerberos password for rra/[EMAIL PROTECTED]: :
krb5_auth_check: got ticket for end server
out_creds->server: host/wanderer.stanford.edu@
krb5_verify_tkt_def: verifying target server
server: host/wanderer.stanford.edu@
tkt->server: host/[EMAIL PROTECTED]
ksu: Wrong principal in request while verifying ticket for server
Authentication failed.
It looks like the principal verification logic in ksu is problematic. ksu
appears not to use krb5_verify_init_creds, which I'm guessing is the
problem.
Do you know of any particular reason why ksu shouldn't use
krb5_get_init_creds_password and krb5_verify_init_creds with
krb5_verify_init_creds_opt_set_ap_req_nofail set to true? It looks like
it was written to the old API, but I'm not sure if there was some reason
for that. Would using the current API fix this problem?
To see more details, look at clients/ksu/krb_auth_su.c, in particular the
krb5_verify_tkt_def function.
--
Russ Allbery ([EMAIL PROTECTED]) <http://www.eyrie.org/~eagle/>
--
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
