Harald Barth wrote:
> 
> > 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. 

How do you achieve that? My service principals have "Max ticket life"
property set to "1 week" by default, but all the krbtgt principals
have "Max ticket life=unlimited" (AFAIK it was set by "kadmin init"
and I never changed that).

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

That's funny. Each "kgetcred host/techno..." adds yet another
">>>Expired<<<" entry to the cache!

> 
> Do you have time to test this in newer heimdal?

Well, I could install 7.4.0 from the ports collection, but my ssh and
sshd will remain linked to 1.5.2, right?

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

Yes, something like that in the crontab should perhaps do the job:
apply -d 'kdestroy --credential=%1' `klist | awk '/Expired/{print $6}' | sort 
-u`

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

IMHO this is fine unless the expired tickets kept in the cache don't
prevent from getting new ones.

-- 
Victor Sudakov,  VAS4-RIPE, VAS47-RIPN
AS43859

Reply via email to