Kerberos client basics on Linux: krb5.conf, kinit/klist/kdestroy, and keytabs

Goal

Obtain, inspect and clear a Kerberos ticket-granting ticket (TGT) on a Linux client using MIT Kerberos (krb5), and use a keytab for a process that must authenticate without an interactive password.

Prerequisites

The krb5-user/krb5-workstation package installed; /etc/krb5.conf configured with at least a default_realm under [libdefaults], unless DNS SRV records provide it a [realms] stanza mapping the realm to its KDC, and usually a [domain_realm] section mapping DNS domains to the realm; network reachability to the KDC (usually TCP/UDP 88).

Steps

1. Confirm configuration: default_realm in /etc/krb5.conf must match the realm name exactly, including case — Kerberos realm names are conventionally uppercase and are treated as case-sensitive strings, so EXAMPLE.COM and example.com are different realms to the library even if DNS is case-insensitive.
2. Obtain a ticket interactively: kinit user@EXAMPLE.COM, which prompts for the password and, on success, stores a TGT in the default credential cache. kinit documents -k -t <keytab> to authenticate from a keytab instead of a password — the form needed for unattended use, e.g. kinit -k -t /etc/svc.keytab svc@EXAMPLE.COM (without a principal it defaults to the local host/ principal).
3. Inspect the cache: klist shows the principal, ticket flags, and issue/expiry times without needing further authentication.
4. List a keytab's contents (for a service or automation principal) without extracting secrets: klist -k -t -e /etc/krb5.keytab, which prints the principals, key timestamps and (with -e) encryption types the keytab holds; the system keytab is readable only by root.
5. Discard the cached tickets when done or before switching identity: kdestroy.

Expected result

klist after a successful kinit shows a valid TGT with an expiry time in the future; a subsequent Kerberized service call (SSH with GSSAPI, an LDAP SASL/GSSAPI bind) succeeds without a password prompt. kdestroy followed by klist reports no credentials cached.

Limits and test basis

The most common client-side failures are clock skew — Kerberos rejects tickets when the client and KDC clocks differ by more than the configured tolerance (clockskew in [libdefaults], default 300 seconds), reported as a "clock skew too great" error — and realm-name case mismatches between krb5.conf and what the KDC expects. Neither is a network or password problem, so checking chronyc tracking/timedatectl and the exact realm string first saves time. A keytab file grants whoever can read it the ability to obtain tickets for its principal, so its file permissions (owner-read-only) matter as much as its location.