> debug1: Next authentication method: gssapi-with-mic
> debug1:  The context has expired

That looks to me like a bug where the library actually should try to
get a new service ticket from the TGT. I don't know if that works in
any heimdal libkrb as most often (at least in my use case) the TGT and
the service ticket have the same lifetime. I only use this scenario
when I use GSSAPI IMAP and there the application is linked against MIT
IIRC.

> Now if I destroy the expired ticket by "kdestroy --credential=host/techno..."
> a new ticket is received and gssapi-with-mic is again successful until
> the new tickets expires again.

Yes, then you create the same situation as with a freshly aquired TGT.

> I'm beginning to think of a cron job which would destroy hourly all
> the service tickets... all except the TGT.

Does the same problem happen with kgetcred host/techno.... instead of
ssh?

Do you have time to test this in newer heimdal?

Ugly workaround: A wrapper script could destroy all expired service
tickets.

Btw, one of my ticket caches looks like this (probably MIT library):

  Issued                Expires               Principal
Aug  5 18:06:47 2017  Aug 12 18:06:45 2017  
krbtgt/besserwisser....@besserwisser.org
Aug  5 18:06:50 2017  >>>Expired<<<         
imap/jaja.besserwisser....@besserwisser.org
Aug  6 18:35:34 2017  >>>Expired<<<         
imap/jaja.besserwisser....@besserwisser.org
Aug  8 09:08:14 2017  >>>Expired<<<         
imap/jaja.besserwisser....@besserwisser.org
Aug  9 09:12:16 2017  Aug 10 09:12:16 2017  
imap/jaja.besserwisser....@besserwisser.org

There is no reason that the expired service tickets are kept around,
but in this case, the code seems to keep them and append new tickets
at the end instead.

Harald.

Reply via email to