> 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.