ssh_GSSAPI_expiration_workflow

workflow.md

1. kinit THEUSER@EXAMPLE.ORG
2. I got a ticket krbtgt/EXAMPLE.ORG@EXAMPLE.ORG
3. I get a ticket for host/remote.example.org@EXAMPLE.ORG
4. klist shows me that I have successfully retrieved ticket for host/remote.example.org@EXAMPLE.ORG
5. ssh THEUSER@remote.example.org succeeds using GSS-API and everything works perfectly:

• ticket is forwarded if requested
• AFS access works

Now If I manually expires principal OR its password while tickets previously retrieved are still valid.

When I try to connect using password, it:

• fails if principal was expired (which is the expected behavior)
• prompts for a new password if password was expired (this is also the expected behavior)

If I try to ssh THEUSER@remote.example.org as before using GSS-API, it is working (interactive access is allowed) but:

• when I arrive on the remote host, my ticket was not forwarded
• no service ticket was retrieved by pam_krb5 for AFS service

Once my TGT expires, I cannot ssh THEUSER@remote.example.org using GSS-API anylonger which is the expected behavior.

So basically, I can still have (restricted) access to host remote.example.org using SSH while I still got a valid ticket, whatever kind of expiration the Kerberos administrators were using.

Is there a way to mitigate this ? To force SSH / GSS-API / PAM / whatever to refuse SSH+GSS-API connections if principal is expired, whatever still valid credentials are provided ?