| KLOG.KRB5(1) | AFS Command Reference | KLOG.KRB5(1) |
klog.krb5 - Authenticates to Kerberos and obtains a token
klog.krb5 [-x]
[-principal <user name>]
[-password <user's password>]
[-cell <cell name>]
[-k <realm>] [-pipe] [-silent]
[-lifetime <ticket lifetime in hh[:mm[:ss]]>]
[-setpag] [-tmp] [-noprdb] [-unwrap]
[-help]
klog.krb5 [-x]
[-pr <user name>]
[-pa <user's password>]
[-c <cell name>]
[-k <realm>] [-pi]
[-si]
[-l <ticket lifetime in hh[:mm[:ss]]>]
[-se] [-t] [-n] [-u] [-h]
The klog.krb5 command obtains a Kerberos v5 ticket from a Kerberos KDC and, from the ticket, an AFS token and then stores it in the Cache Manager. The Cache Manager keeps the token in kernel memory and uses it when obtaining authenticated access to the AFS filespace. This command does not affect the issuer's identity (UNIX UID) on the local file system.
By default, the command interpreter obtains a token for the AFS user name that matches the issuer's local user name. To specify an alternate user, include the -principal argument. The user named by the -principal argument does not have to appear in the local password file (the /etc/passwd file or equivalent).
By default, the command interpreter obtains a token for the local cell, as defined by the AFSCELL environment variable set in the command shell or by the /etc/openafs/ThisCell file on the local machine. To specify an alternate cell, include the -cell argument. A user can have tokens in multiple cells simultaneously, but only one token per cell per connection to the client machine. If the user's credential structure already contains a token for the requested cell, the token resulting from this command replaces it.
By default, the command interpreter obtains a Kerberos ticket for the local realm. To specify a different Kerberos realm, include the -k argument. The Kerberos realm name need not match the AFS cell name. klog.krb5 will request a ticket for the principal "afs/cell" where cell is the cell name for which the user is requesting tokens, falling back on the principal "afs" if that principal does not work.
The lifetime of the token resulting from this command is the smallest of the following:
By default, this command does not create a new process authentication group (PAG); see the description of the pagsh command to learn about PAGs. If a cell does not use an AFS-modified login utility, users must include -setpag option to this command, or issue the pagsh command before this one, to have their tokens stored in a credential structure that is identified by PAG rather than by local UID. Users should be aware that -setpag will not work on some systems, most notably recent Linux systems, and using pagsh is preferrable and more reliable.
When a credential structure is identified by local UID, the potential security exposure is that the local superuser "root" can use the UNIX su command to assume any other identity and automatically inherit the tokens associated with that UID. Identifying the credential structure by PAG makes it more difficult (but not impossible) for the local superuser to obtain tokens of other users.
If the -password argument is used, the specified password cannot begin with a hyphen, because it is interpreted as another option name. Use of the -password argument is not recommended in any case.
By default, it is possible to issue this command on a properly configured NFS client machine that is accessing AFS via the NFS/AFS Translator, assuming that the NFS client machine is a supported system type. However, if the translator machine's administrator has enabled UID checking by including the -uidcheck on argument to the fs exportafs command, the command fails with an error message similar to the following:
Warning: Remote pioctl to <translator_machine> has failed (err=8). . . Unable to authenticate to AFS because a pioctl failed.
Enabling UID checking means that the credential structure in which tokens are stored on the translator machine must be identified by a UID that matches the local UID of the process that is placing the tokens in the credential structure. After the klog.krb5 command interpreter obtains the token on the NFS client, it passes it to the remote executor daemon on the translator machine, which makes the system call that stores the token in a credential structure on the translator machine. The remote executor generally runs as the local superuser "root", so in most cases its local UID (normally zero) does not match the local UID of the user who issued the klog.krb5 command on the NFS client machine.
Issuing the klog.krb5 command on an NFS client machine creates a security exposure: the command interpreter passes the token across the network to the remote executor daemon in clear text mode.
If this argument is omitted, the command is executed in the local cell, as defined
If the -tmp flag is included, the following message confirms that a Kerberos ticket cache was created:
Wrote ticket file to /tmp/krb5cc_1000_rENJoZ
The path to the cache will vary, of course.
Most often, this command is issued without arguments. The appropriate password is for the person currently logged into the local system. The ticket's lifetime is calculated as described in "DESCRIPTION".
% klog.krb5 Password for user@EXAMPLE.ORG:
The following example authenticates the user as admin in the Example Corporation's test cell:
% klog.krb5 -principal admin -cell test.example.com Password for admin@EXAMPLE.COM:
In the following, the issuer requests a ticket lifetime of 104 hours 30 minutes (4 days 8 hours 30 minutes).
% klog.krb5 -lifetime 104:30 Password for user@EXAMPLE.ORG:
None
IBM Corporation 2000. <http://www.ibm.com/> All Rights Reserved.
This documentation is covered by the IBM Public License Version 1.0. It was converted from HTML to POD by software written by Chas Williams and Russ Allbery, based on work by Alf Wachsmann and Elizabeth Cassell.
| 2021-01-27 | OpenAFS |