GSSAPIDelegateCredentials only works for REQUIRES_PRE_AUTH principals?

[Russ Allbery]

Adam Megacz <megacz at cs.berkeley.edu> writes:
> Russ Allbery <rra at stanford.edu> writes:

>> Check the host/* principal on the system to which you were
>> authenticating.  I bet that the REQUIRES_PRE_AUTH flag was set for it,
>> which means that only tickets that are pre-authenticated can
>> authenticate to that service principal.

> Indeed, that was it!  Russ saves the day again.

The behavior caused by setting REQUIRES_PRE_AUTH on principals to which
one authenticates rather than principals one authenticates as always
strikes me as surprising, unexpected, and unintuitive.

> Curious: I assume that the failure mode here is some variation on the
> sshd machine asking the KDC for a delegation and the KDC refusing.

I believe it fails even if you're not doing delegation.  I believe the KDC
refuses to issue you a service ticket for a principal with
REQUIRES_PRE_AUTH set if your TGT is not tagged as preauthenticated.  But
I don't remember the details of the research that I did when I ran into
this.  (We just cleared that flag from principals like host/* principals
and moved on with our lives; given that they're randomly generated keys,
hopefully brute force attacks are difficult anyway.)

> Does the refusal include enough information to produce an error message
> (either in the sshd log or elsewhere) mentioning this as the reason for
> the failure?

ssh (well, OpenSSH) never reports useful error messages by default for
anything related to GSSAPI.

> In general I find that sshd really does a very poor job explaining the
> reason why things went wrong when it comes to Kerberos/GSSAPI.  I've got
> some free cycles this summer that I can put towards fixing that if it's
> something that can be fixed.

I haven't looked at the code personally, but what I recall from what other
people have said is that the code is structured so that doing proper error
reporting is fairly difficult.  It can also quite hard to get OpenSSH
upstream to take GSSAPI-related patches, depending on how those patches
strike them.

-- 
Russ Allbery (rra at stanford.edu)             <http://www.eyrie.org/~eagle/>