Adam Megacz <[email protected]> writes: > Russ Allbery <[email protected]> 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 ([email protected]) <http://www.eyrie.org/~eagle/> ________________________________________________ Kerberos mailing list [email protected] https://mailman.mit.edu/mailman/listinfo/kerberos
