AKEYCONVERT(8)

📦
version 1.8.16.1 · 10 versions
, in ubuntu stonking

💅 AKEYCONVERT 💅

okay bestie, so this is akeyconvert from section 8 of the AFS Command Reference — it's a server-side glow-up tool and honestly it's giving "quiet little utility that saves your entire cell" energy. ✨

✨ NAME ✨

akeyconvert — import keys from rxkad.keytab to an AFS KeyFileExt, no cap 🫶

🎀 SYNOPSIS 🎀

akeyconvert -all

🦋 DESCRIPTION 🦋

so here's the tea: akeyconvert is the command you run when you're upgrading an AFS cell from the 1.6.x release series to the 1.8.x release series. glow-up era. 💖

when you were using the rxkad-k5 security extension, the 1.6.x release series kept the AFS long-term Kerberos keys in a krb5 keytab file named rxkad.keytab. meanwhile the 1.8.x series releases said "not me linking against libkrb5 everywhere 🙈" and instead store the AFS long-term Kerberos keys in an OpenAFS-specific file format: the KeyFileExt(5).

akeyconvert is literally just the easy way to convert the AFS long-term Kerberos keys from the krb5 keytab format to the KeyFileExt format. you could do the exact same thing by using asetkey(8) over and over and over, but akeyconvert exists to simplify the whole process, because she's thoughtful like that. 👑

by default, akeyconvert will only migrate the newest key (the highest kvno) for each Kerberos principal that has a key in the rxkad.keytab. and if you want to convert all the keys, regardless of kvno? that's what akeyconvert -all is for. slay.

⚠️ CAUTIONS ⚠️

okay this is the important part, so bestie please pay attention: the KeyFileExt format is slightly less flexible than the krb5 keytab format. the KeyFileExt identifies keys only by the type (rxkad-k5), the kvno, and the enctype (the "subtype"), whereas the krb5 keytab also stores the principal name associated with each key. 💀

what that means: if you had a krb5 keytab containing keys with identical kvno and enctype, but for different principals, that literally would not be representable as a KeyFileExt. and akeyconvert will detect that situation and will not perform any key conversions until the conflict is removed. she refuses to be messy. 💅

also, a lot of the concerns that asetkey(8) lays out about extracting new Kerberos keys with ktadd apply here too, whenever you're making changes involving the rxkad.keytab. so go read that too, iykyk.

🌈 EXAMPLES 🌈

in a cell that's using the rxkad-k5 extension, this command will read the newest keys from the rxkad.keytab and write them to the KeyFileExt in the appropriate format:

% akeyconvert

now consider a cell that has a key of kvno 2 and enctype aes128-cts-hmac-sha1-96 for both afs/example.com@EXAMPLE.COM and a different key with the same kvno and enctype but for the principal afs@EXAMPLE.COM. akeyconvert will detect the kvno/enctype collision and refuse to continue. 😭

to fix it, you should use the appropriate Kerberos keytab-manipulation tools to generate a new key (of higher kvno) for one of the colliding principals and remove the old (colliding) key for that principal before akeyconvert is used. clean up your room first, then convert. 🧚

% akeyconvert -all
Duplicate kvno/enctype 2/17
FATAL: duplicate key identifiers found.

👑 PRIVILEGE REQUIRED 👑

the issuer must be able to read the rxkad.keytab and write the KeyFile and KeyFileExt, which normally live at /etc/openafs/server/KeyFile and /etc/openafs/server/KeyFileExt. in practice? that means the issuer must be the local superuser "root" on the AFS file server or database server. main character privileges only, fr fr. 🔥

🌸 SEE ALSO 🌸

Copyright 2015 Massachusetts Institute of Technology.

This documentation is covered by the IBM Public License Version 1.0.

This man page was written by Benjamin Kaduk for OpenAFS.

and that's the whole page bestie, that's the vibe check passed ✅ — this one's from OpenAFS, dated 2026-07-27, and it's living in section 8 of the manual alongside her sisters. go forth and convert those keys responsibly 💖🦋✨

📦 where this page comes from