K5LOGIN(5)

📦
version 1.22.2 · 9 versions
, in alpine 3.24, arch rolling, fedora 43, freebsd 15.1, nixos 26.05, nixpkgs unstable

💖 K5LOGIN(5) — Kerberos V5 acl file for host access 💖

okay bestie, this is the K5LOGIN(5) manual page from MIT Kerberos — manual name folded in near the top, exactly like we're supposed to, and no boring header line copied. we're talking about k5login, the little file that decides who gets to log in as whom. it's giving "tiny file, huge consequences" and honestly? iconic. 🌈

✨ NAME ✨

k5login — Kerberos V5 acl file for host access

🌸 DESCRIPTION 🌸

bestie, the .k5login file resides in a user's home directory, and it contains a list of the Kerberos principals. that's the whole storage situation. the rule is: anyone with valid tickets for a principal in the file is allowed host access with the UID of the user in whose home directory the file resides. yes, UID. yes, that user. periodt.

one common use is to place a .k5login file in root's home directory, thereby granting system administrators remote root access to the host via Kerberos. that's the classic glow-up for this file — sysadmins get in with Kerberos instead of doing the whole root-password thing. 🫶

🦋 EXAMPLES 🦋

okay so suppose the user alice had a .k5login file in her home directory containing just the following line:

bob@FOOBAR.ORG

this would allow bob to use Kerberos network applications, such as ssh(1), to access alice's account, using bob's Kerberos tickets. slay for bob, honestly.

in a default configuration (with k5login_authoritative set to true in krb5.conf), this .k5login file would not let alice use those network applications to access her account, since she is not listed! not alice catching strays in her own home directory 😭 that's the authoritative part doing its thing.

with no .k5login file, or with k5login_authoritative set to false, a default rule would permit the principal alice in the machine's default realm to access the alice account. so yeah, the file being absent or non-authoritative changes the vibe check. ✨

let us further suppose that alice is a system administrator. alice and the other system administrators would have their principals in root's .k5login file on each host:

alice@BLEEP.COM

joeadmin/root@BLEEP.COM

this would allow either system administrator to log in to these hosts using their Kerberos tickets instead of having to type the root password. root access without typing the root password is highkey the moment. 👑

note that because bob retains the Kerberos tickets for his own principal, bob@FOOBAR.ORG, he would not have any of the privileges that require alice's tickets, such as root access to any of the site's hosts, or the ability to change alice's password. so bob can be bob, but bob cannot be alice. no cap, that distinction is the whole plot. 💅

👑 SEE ALSO 👑

kerberos(1)

that's the one reference, bestie. go read it if you want the wider Kerberos lore. 📚

💜 AUTHOR 💜

MIT

1985-2026, MIT

okay that's the whole K5LOGIN(5) page, bestie 💖 signing off with version 1.22.2 of the MIT Kerberos manual, and the copyright date range 1985-2026, MIT — mwah, go forth and let the right principals in 💋✨

📦 where this page comes from