Quoth [EMAIL PROTECTED] (Ken Grady):
| What is the correct way to do this? Or is it correct to allow both?
| And should an option be added to SomeNewSSH to allow either
| functionality (-k1 kerberos original -k2 extra principal...)?
| Openssh-3.1p1 uses the default principal is the same as the client and
| things seem to be compatable as far as using forwarded tickets are
| concerned. Compatability between differing versions of ssh is
| practically non-existant AFAICT.
|
| When I kinit I get klg @lanl.gov as the default principal. An od -c
| of the cache shows that klg is also the client. When I use ssh.com's
| ssh-3.1.0 and "ssh -l acct machine.lanl.gov", I end up with a ticket for
| default principal [EMAIL PROTECTED] and client [EMAIL PROTECTED] which isn't
| necessarily bad, because I can use that ticket and "ksu" (ticket default
| principal becomes [EMAIL PROTECTED]) and I become root (I'm in acct's and
| roots's .k5login files). The logs on the KDC show that root was
| authenticated as [EMAIL PROTECTED] for acct (see below). Where it gets
| confusing is if I "ssh -l root machine.lanl.gov" my default principal is
| [EMAIL PROTECTED] client [EMAIL PROTECTED], but [EMAIL PROTECTED] isn't a valid
| kerberos principal. So should ssh-3.1.0 revert back to [EMAIL PROTECTED] or
| should ksu change the principal to [EMAIL PROTECTED] and just leave the
| client [EMAIL PROTECTED]? The ssh from ssh-3.1.0 doesn't seem to use the
| client info from the ticket cache, so I am unable to ssh with a default
| principal of [EMAIL PROTECTED] and client of [EMAIL PROTECTED] to another machine
| (unless I "ksu klg" first. What if I don't have an account on the
| machine?) nor am I able to ssh with a default principal of
| [EMAIL PROTECTED] So the question is "Which is correct?".
I don't have much to do with these things, but since no one else's
followup has appeared yet, here's my opinion. "Where it gets confusing"
above shows why "-l username" should refer to a remote account and not
a Kerberos principal. Authorization to that account can be based on
whatever suits sshd. If Kerberos then the Kerberos principal should be
determined according to general Kerberos rules, i.e., the default
principal from the credentials. If that's inconvenient, the solution
should apply to Kerberos applications in general, where I would imagine
the use of more than one principal could be better supported.
Whether ssh should forward credentials I don't know for sure, but since
there isn't any "real" mapping between principal and account, only a
set of loose conventions, I guess it should be as happy to forward to
a .k5login-authorized account as to a name==name-authorized account.
Donn Cave, [EMAIL PROTECTED]
| The logs show:
| Apr 10 08:11:00 kerb1 krb5kdc[715]: TGS_REQ 123.123.123.2(88):
| ISSUE:authtime 1018447267, [EMAIL PROTECTED] for [EMAIL PROTECTED]
| pr 10 08:11:48 kerb1 krb5kdc[715]: TGS_REQ 123.123.123.2(88):
| ISSUE:authtime 1018447267, [EMAIL PROTECTED] for
| [EMAIL PROTECTED]
| Apr 10 08:11:48 kerb1 ksu[8599]: 'ksu root' authenticated [EMAIL PROTECTED]
| for acct on /dev/pts/2
| Apr 10 08:11:48 kerb1 ksu[8599]: Account root: authorization for
| [EMAIL PROTECTED] successful
________________________________________________
Kerberos mailing list [EMAIL PROTECTED]
http://mailman.mit.edu/mailman/listinfo/kerberos
