asetkey - Add a key from a keytab to an AFS KeyFile or KeyFileExt

       Historically, AFS only supported des-cbc-crc:v4 Kerberos keys.  In environments which have not been
       upgraded to use the rxkad-k5 extension, when creating the keytab with "ktadd", you must pass "-e
       des-cbc-crc:v4" to force the encryption type.  Otherwise, AFS authentication may not work.

       As soon as a new keytab is created with "ktadd", new AFS service tickets will use the new key.  However,
       tokens formed from those service tickets will only work if the new key is present in the KeyFileExt on
       the AFS file server.  There is therefore an outage window between when the new keytab is created and when
       the key had been added to the KeyFileExt of all AFS servers with asetkey, during which newly obtained AFS
       tokens will not work properly.

       All of the KeyFileExt entries must match the key in the Kerberos KDC, but each time "ktadd" is run, it
       creates a new key.  Some secure mechanism must be used to distribute the KeyFileExt to all servers, or
       the same keytab must be used with asetkey on each server.

       Copyright 2006 Russ Allbery <rra@stanford.edu> Copyright 2013,2015 Massachusetts Institute of Technology

       This documentation is covered by the IBM Public License Version 1.0.  This man page was written by Russ
       Allbery for OpenAFS and updated for the rxkad-k5 extension by Benjamin Kaduk.

OpenAFS                                            2025-03-21                                         ASETKEY(8)

       The asetkey command is used to add a key to an AFS KeyFile or KeyFileExt from a Kerberos keytab.  It is
       similar to bosaddkey except that it must be run locally on the system where the KeyFile or KeyFileExt is
       located and it takes the new key from a Kerberos 5 keytab rather than prompting for the password.

       asetkeydelete can be used to delete a key (similar to bosremovekeys), and asetkeylist will list the
       keys in a KeyFile and the keys in a KeyFileExt (similar to boslistkeys, but more fully featured, since
       boslistkeys cannot list the contents of a KeyFileExt).

       asetkey is used when authentication for an AFS cell is provided by a Kerberos 5 KDC rather than the
       deprecated kaserver.  The key for the "afs" or "afs/cellname" principal in the Kerberos 5 KDC must match
       the key stored in the AFS KeyFileExt on all AFS database servers and file servers.  This is done by
       creating a keytab containing that key using the standard Kerberos commands (generally the "ktadd"
       function of the kadmin command) and then, on each AFS database server and file server, adding that key to
       the KeyFileExt with asetkeyadd.  The kvno chosen should match the kvno in the Kerberos KDC (checked with
       kvno or the "getprinc" function of kadmin).  principal should be the name of the AFS principal in the
       keytab, which must be either "afs" or "afs/cellname".

       In a cell which is using the rxkad-k5 extension, the following commands create a new keytab for the
       principal "afs/cellname" and then import its keys into the KeyFileExt.  Note the kvno in the output from
       "ktadd".  The values 18, 17, and 16 are the assigned numbers corresponding to the kerberos enctypes in
       the keytab.  These numbers can be determined from your system's krb5 headers.

           % kadmin
           Authenticating as principal kaduk/admin@ZONE.MIT.EDU with password.
           Password for kaduk/admin@ZONE.MIT.EDU:
           kadmin:  ktadd -k /tmp/afs.keytab afs/disarray.mit.edu
           Entry for principal afs/disarray.mit.edu with kvno 4, encryption type
           aes256-cts-hmac-sha1-96 added to keytab WRFILE:/tmp/afs.keytab.
           Entry for principal afs/disarray.mit.edu with kvno 4, encryption type
           aes128-cts-hmac-sha1-96 added to keytab WRFILE:/tmp/afs.keytab.
           Entry for principal afs/disarray.mit.edu with kvno 4, encryption type
           des3-cbc-sha1 added to keytab WRFILE:/tmp/afs.keytab.
           kadmin:  exit
           % asetkey add rxkad_krb5 4 18 /tmp/afs.keytab afs/disarray.mit.edu
           % asetkey add rxkad_krb5 4 17 /tmp/afs.keytab afs/disarray.mit.edu
           % asetkey add rxkad_krb5 4 16 /tmp/afs.keytab afs/disarray.mit.edu

       A modern AFS cell should be using the rxkad-k5 extension, or risks terribly insecure operation (complete
       cell compromise for $100 in 1 day).  The keys used for rxkad-k5 operation are stored in the KeyFileExt.
       Cells not using the rxkad-k5 extension (i.e., stock rxkad) use keys of the des-cbc-crc encryption type,
       which are stored in the KeyFile.

       asetkey retains the functionality needed to support stock rxkad operation, but its use is disrecommended.
       A bare 8-byte hex key can be added with

           % asetkey add I<kvno> I<key>

       key should be an 8 byte hex representation.  An example using a kvno of 3:

           % asetkey add 3 80b6a7cd7a9dadb6

       The following commands create a new keytab for the principal "afs" and then import the key into the
       KeyFile.  Note the kvno in the output from "ktadd".

           % kadmin
           Authenticating as principal rra/admin@stanford.edu with password.
           Password for rra/admin@stanford.edu:
           kadmin:  ktadd -k /tmp/afs.keytab -e des-cbc-crc:v4 afs
           Entry for principal afs with kvno 3, encryption type DES cbc mode
           with CRC-32 added to keytab WRFILE:/tmp/afs.keytab.
           kadmin:  exit
           % asetkey add 3 /tmp/afs.keytab afs

       You may want to use "afs/cellname" instead of "afs", particularly if you may have multiple AFS cells for
       a single Kerberos realm.

       asetkey - Add a key from a keytab to an AFS KeyFile or KeyFileExt

       The issuer must be able to read (for asetkeylist) and write (for asetkeyadd and asetkeydelete) the
       KeyFileExt, normally /etc/openafs/server/KeyFileExt.  In practice, this means that the issuer must be the
       local superuser "root" on the AFS file server or database server.  For asetkeyadd, the issuer must also
       be able to read the specified keytab file.

KeyFile(5), KeyFileExt(5), bos_addkey(8), bos_listkeys(8), bos_removekey(8), kadmin(8), kvno(1)

asetkey add <kvno> <keyfile> <principal>

       asetkey add <kvno> <key>

       asetkey add <type> <kvno> <subtype> <key>

       asetkey add <type> <kvno> <subtype> <keyfile> <princ>

       asetkey delete <kvno>

       asetkey delete <type> <kvno>

       asetkey delete <type> <kvno> <subtype>

       asetkey list