CSP-Kerberos is based on the Kerberos V5 authentication system developed at MIT. Kerberos is named for the three-headed watchdog from Greek mythology, who guarded the entrance to the underworld.
Under CSP-Kerberos, a client (generally either a user or a service) sends a request for a ticket to the Key Distribution Center (KDC). The KDC creates a ticket-granting ticket (TGT) for the client, encrypts it using the client password as the key, and sends the encrypted TGT back to the client. The client then attempts to decrypt the TGT, using its password. If the client successfully decrypts the TGT (if the client gave the correct password), it keeps the decrypted TGT, which indicates proof of the client's identity.
The TGT, which expires at a specified time, permits the client to obtain additional tickets, which give permission for specific services. The requesting and granting of these additional tickets is user-transparent.
Since CSP-Kerberos negotiates authenticated, and optionally encrypted, communications between two points anywhere on the Internet, it provides a layer of security that is not dependent on which side of a firewall either client is on. Since studies have shown that half of the computer security breaches in industry happen from inside firewalls, Silicon Graphics CSP-Kerberos plays a vital role in maintaining your network security.
The CSP-Kerberos package is designed to be easy to use. Most of the commands are nearly identical to UNIX network programs you are already used to. CSP-Kerberos is a single-sign-on system, which means that you have to type your password only once per session, and CSP-Kerberos does the authenticating and encrypting transparently.
Your CSP-Kerberos credentials, or “tickets,” are a set of electronic information that can be used to verify your identity. Your CSP-Kerberos tickets may be stored in a file, or they may exist only in memory.
The first ticket you obtain is a ticket-granting ticket, which permits you to obtain additional tickets. These additional tickets give you permission for specific services. The requesting and granting of these additional tickets happens transparently.
A good analogy for the ticket-granting ticket is a three-day ski pass that is good at four different resorts. You show the pass at whichever resort you decide to go to (until it expires), and you receive a lift ticket for that resort. Once you have the lift ticket, you can ski all you want at that resort. If you go to another resort the next day, you once again show your pass, and you get an additional lift ticket for the new resort. The difference is that the CSP-Kerberos programs notice that you have the weekend ski pass, and get the lift ticket for you, so you don't have to perform the transactions yourself.
A CSP-Kerberos principal is a unique identity to which CSP-Kerberos can assign tickets. By convention, a principal is divided into three parts: the primary, the instance, and the realm. The format of a typical CSP-Kerberos V5 principal is primary/instance@REALM:
The primary is the first part of the principal. In the case of a user, it's the same as your username. For a host, the primary is the word host.
The instance is an optional string that qualifies the primary. The instance is separated from the primary by a slash (/). In the case of a user, the instance is usually null, but a user might also have an additional principal, with an instance called admin, which he or she used to administer a database. The principal eugene@YOURSITE.COM is completely separate from the principal eugene/admin@YOURSITE.COM, with a separate password and separate permissions. In the case of a host, the instance is the fully qualified hostname, for example, laughter.yoursite.com
The realm is your CSP-Kerberos realm. In most cases, your CSP-Kerberos realm is your domain name, in uppercase letters. For example, the system laughter.yoursite.com is in the realm YOURSITE.COM.
This tutorial is intended to familiarize you with the CSP-Kerberos client programs. In these examples, sample user names, such as dave and jennifer, sample hostnames, such as laughter and rain, and sample domain names, such as yoursite.com and theirsite.com are used. When you see one of these, substitute your username, hostname, or domain name accordingly.
Your system administrator has installed the CSP-Kerberos programs in whichever directory makes the most sense for your system. The directory /krb5 is used throughout this guide to refer to the top-level CSP-Kerberos directory. The directory /krb5/bin is used to denote the location of the CSP-Kerberos user programs. Place the /krb5/bin and /krb5/sbin directories in your PATH environment variable. You will probably want to put it ahead of the directories /bin and /usr/bin so you automatically use the CSP-Kerberos network programs, rather than the standard IRIX versions, when you type the command names.
On many systems, CSP-Kerberos is built into the login program, and you get tickets automatically when you log in. Other programs, such as rsh, rcp, telnet, and rlogin, can forward copies of your tickets to the remote host. Most of these programs also automatically destroy your tickets when they exit. However, Silicon Graphics recommends that you explicitly destroy your CSP-Kerberos tickets when you are through with them, just to be sure. One way to help ensure that this happens is to add the kdestroy command to your .logout file. Additionally, if you are going to be away from your system and are concerned about an intruder using your permissions, it is safest to either destroy all copies of your tickets or use a screensaver that locks the screen.
If your site is using the CSP-Kerberos login program, you get CSP-Kerberos tickets automatically when you log in. If your site uses another login program, you may need to explicitly obtain your CSP-Kerberos tickets, using the kinit program. Similarly, if your CSP-Kerberos tickets expire, use the kinit program to obtain new ones.
To use the kinit program, simply type kinit and then type your password at the prompt. For example, Jennifer (whose user name is jennifer) works for Yoursite, Inc. (a fictitious company with the domain name yoursite.com and the CSP-Kerberos realm YOURSITE.COM). She would enter the command:
kinit Password for jennifer@YOURSITE.COM: <Type Jennifer's password here> |
If you type your password incorrectly, kinit returns the following error message, and you don't get CSP-Kerberos tickets:
kinit: Password incorrect |
Notice that kinit assumes you want tickets for your own username in your default realm. Suppose Jennifer's friend David is visiting, and he wants to borrow a window to check his mail. David needs to get tickets for himself in his own realm, THEIRSITE.COM.
 | Note: Any alternate realm, such as THEIRSITE.COM,must be listed in your system's CSP-Kerberos configuration file, /etc/krb5.conf. David would enter the command: |
kinit dave@THEIRSITE.COM Password for dave@THEIRSITE.COM <Type Dave's password here> |
David now has tickets which he can use to log onto his own system. Note that he typed his password locally on Jennifer's system, but it never went over the network. CSP-Kerberos on the local host performed the authentication to the KDC in the other realm.
If you want to forward your tickets to another host, you need to request forwardable tickets. You do this by specifying the -f option:
kinit -f Password for jennifer@YOURSITE.COM: <Type your password here> |
| Note: The kinit command does not tell you that it obtained forwardable tickets; you can verify this using the klist command |
Normally, your tickets are good for your system's default ticket lifetime, which is ten hours on many systems. You can specify a different ticket lifetime with the -l option. Add the letter s to the value for seconds, m for minutes, h for hours, or d for days.
For example, to obtain forwardable tickets for dave@THEIRSITE.COM that are good for three hours, enter the command:
kinit -f -l 3h dave@THEIRSITE.COM Password for dave@THEIRSITE.COM: <Type dave's password here> |
You cannot mix units; specifying a lifetime of 3h30m results in an error. Note also that most systems specify a maximum ticket lifetime. If you request a longer ticket lifetime, it is automatically truncated to the maximum lifetime.
The klist command shows your tickets. When you first obtain tickets, you have only the ticket-granting ticket. The listing looks like this:
klist Ticket cache: /tmp/krb5cc_ttypa Default principal: jennifer@YOURSITE.COM Valid starting Expires Service principal 01/07/97 19:49:21 01/08/97 05:49:19 krbtgt/YOURSITE.COM@YOURSITE.COM |
The ticket cache is the location of your ticket file. In the above example, this file is named /tmp/krb5cc_ttypa. The default principal is your CSP-Kerberos principal.
The valid starting and expires fields describe the period of time during which the ticket is valid. The service principal describes each ticket. The ticket-granting ticket has the primary krbtgt, and the instance is the realm name.
Now, if Jennifer connects to the system laughter.yoursite.com, and types klist again, she gets the following result:
klist Ticket cache: /tmp/krb5cc_ttypa Default principal: jennifer@YOURSITE.COM Valid starting Expires Service principal 01/07/97 19:49:21 01/08/97 05:49:19 krbtgt/YOURSITE.COM@YOURSITE.COM 01/07/97 20:22:30 01/08/97 05:49:19 host/laughter.yoursite.com@YOURSITE.COM |
Here's what happens: When Jennifer uses telnet to connect to the host laughter.yoursite.com, the telnet program presents her ticket-granting ticket to the KDC and requests a host ticket for the host laughter.yoursite.com. The KDC sends the host ticket, which telnet then presents to the host laughter.yoursite.com, and she is allowed to log in without entering her password.
Suppose your CSP-Kerberos tickets allow you to log into a host in another domain, such as rain.theirsite.com, which is also in another CSP-Kerberos realm, THEIRSITE.COM. If you telnet to this host, you receive a ticket-granting ticket for the realm THEIRSITE.COM, plus the new host ticket for rain.theirsite.com. The klist command now shows:
klist Ticket cache: /tmp/krb5cc_ttypa Default principal: jennifer@YOURSITE.COM Valid starting Expires Service principal 06/07/96 19:49:21 06/08/96 05:49:19 krbtgt/YOURSITE.COM@YOURSITE.COM 06/07/96 20:22:30 06/08/96 05:49:19 host/laughter.yoursite.com@YOURSITE.COM 06/07/96 20:24:18 06/08/96 05:49:19 krbtgt/THEIRSITE.COM@YOURSITE.COM 06/07/96 20:24:18 06/08/96 05:49:19 host/rain.theirsite.com@YOURSITE.COM |
You can use the -f option to view the flags that apply to your tickets. The flags are:
| F | Forwardable | |
| f | forwarded | |
| P | Proxiable | |
| p | proxy | |
| D | postDateable | |
| d | postdated | |
| R | Renewable | |
| I | Initial | |
| i | invalid |
Here is a sample listing. In this example, the user jennifer obtained her initial tickets (I), which are forwardable (F) and postdated (d) but not yet validated (i).
klist -f
Ticket cache: /tmp/krb5cc_320
Default principal: jennifer@YOURSITE.COM
Valid starting Expires Service principal
31 Jul 96 19:06:25 31 Jul 96 19:16:25 krbtgt/YOURSITE.COM@YOURSITE.COM
Flags: FdiI
|
In the following example, Dave's tickets were forwarded (f) to this host from another host. The tickets are reforwardable (F).
klist -f
Ticket cache: /tmp/krb5cc_p11795
Default principal: dave@THEIRSITE.COM
Valid starting Expires Service principal
07/31/96 11:52:29 07/31/96 21:11:23 krbtgt/THEIRSITE.COM@THEIRSITE.COM
Flags: Ff
07/31/96 12:03:48 07/31/96 21:11:23 host/rain.theirsite.com@THEIRSITE.COM
Flags: Ff
|
Your CSP-Kerberos tickets are proof that you are indeed yourself, and tickets can be stolen. If this happens, the person who has them can masquerade as you until they expire. For this reason, you should destroy your CSP-Kerberos tickets when you are away from your computer.
Destroying your ticket is easy. Simply use the kdestroy command:
kdestroy |
If kdestroy fails to destroy all your tickets, it beeps and displays an error message. For example, if kdestroy can't find any tickets to destroy, it displays the following message:
kdestroy kdestroy: No credentials cache file found while destroying cache Ticket cache NOT destroyed! |
Your password is the only way CSP-Kerberos has of verifying your identity. If someone finds out your password, that person can masquerade as you—send e-mail that comes from you, read, edit, or delete your files, or log into other hosts as you—and no one can tell the difference. For this reason, it is important that you choose a good password, and keep it secret. If you need to give access to your account to someone else, you can do so through CSP-Kerberos. Never tell your password to anyone, including your system administrator, for any reason. Change your password frequently, particularly any time you think someone may have found out what it is.
To change your CSP-Kerberos password, use the kpasswd command. It asks you for your old password (to prevent someone else from changing your password), and then prompts you for the new one twice. (The reason you have to type it twice is to make sure you have typed it correctly.) For example, user dave would do the following:
kpasswd Old password for dave: <Type your old password> New Password for dave: <Type your new password> Verifying, please re-enter New Password for dave: <Type the new password again> Password changed. |
If Dave types an incorrect old password, he gets the following message:
kpasswd Old password for dave: <Type an incorrect old password> Incorrect old password. |
If you make a mistake and don't type the new password the same way twice, kpasswd asks you to try again:
kpasswd Old password for dave: <Type the old password> New Password for dave: <Type the new password> Verifying, please re-enter New Password for dave: <Type a different new password> Mismatch - try again New Password for dave: <Type the new password> Verifying, please re-enter New Password for dave: <Type the same new password> Password changed. |
Once you change your password, it takes some time for the change to propagate through the system. Depending on how your system is set up, this might be anywhere from a few minutes to an hour or more. If you need to get new CSP-Kerberos tickets shortly after changing your password, try the new password. If the new password doesn't work, try again using the old one.
Your password can include almost any character you can type (except control keys and the Enter key). A good password is one you can remember, but that no one else can easily guess. Examples of bad passwords are words that can be found in a dictionary, any common or popular name, especially a famous person (or cartoon character), your name or user name in any form (such as forward, backward, repeated twice, and so on.), your spouse's, child's, or pet's name, your birth date, your social security number, and any sample password that appears in this (or any other) manual.
Silicon Graphics recommends that your password be at least six characters long, and contain UPPER and lower case letters, numbers, and/or punctuation marks. Some passwords that would be good if they weren't listed in this manual include:
some initials, like “GykoR-66.” for “Get your kicks on Route 66.”
an easy-to-pronounce nonsense word, like “slaRooBey” or “krang-its.”
a misspelled phrase, like “2HotPeetzas!” or “ItzAGurl!!!”
| Note: Don't use any of the above passwords. They're meant to show you how to make up a good password. Passwords that appear in a manual are the first ones intruders try. |
CSP-Kerberos allows your system administrators to automatically reject bad passwords, based on whatever criteria they choose; the Commercial Security Pak provides a facility to automatically generate good passwords. For example, if the user jennifer chose a bad password, CSP-Kerberos displays an error message like the following:
kpasswd Old password for jennifer: <Type your old password here> New Password for jennifer: <Type an insecure new password> Verifying, please re-enter New Password for jennifer: <Type it again> ERROR: Insecure password not accepted. Please choose another. kpasswd: Insecure password rejected while attempting to change password. Please choose another password. New Password for jennifer: <Type a good password here> Verifying, please re-enter New Password for dave: <Type it again> Password changed. |
Your system administrators can choose the message that is displayed if you choose a bad password, so the message you see may be different from the above example.
If you need to give someone access to log into your account, you can do so through CSP-Kerberos, without telling the person your password. Simply create a file called .k5login in your home directory. This file should contain the CSP-Kerberos principal of each person to whom you wish to give access. Each principal must be on a separate line. Here is a sample .k5login file:
jennifer@YOURSITE.COM dave@THEIRSITE.COM |
This file allows the users jennifer and dave to use your user ID, provided that they had CSP-Kerberos tickets in their respective realms. If you log in to other hosts across a network, you need to include your own CSP-Kerberos principal in your .k5login file on each of these hosts.
Using a .k5login file is much safer than giving out your password, because:
you can take access away any time simply by removing the principal from your .k5login file.
although the user has full access to your account on one particular host (or set of hosts if your .k5login file is shared, such as over NFS™), that user does not inherit your network privileges.
CSP-Kerberos keeps a log of who obtains tickets, so a system administrator could find out, if necessary, who was capable of using your user ID at a particular time.
One common application is to have a .k5login file in root's home directory, giving root access to that system to the CSP-Kerberos principals listed. This allows system administrators to allow users to become root locally, or to log in remotely as root, without their having to give out the root password, and without anyone having to type the root password over the network.
CSP-Kerberos is a single-sign-on system. This means that you have to type your password only once, and the CSP-Kerberos programs authenticate (and optionally encrypt) for you. The way this works is that CSP-Kerberos has been built into each of a suite of network programs. For example, when you use a CSP-Kerberos program to connect to a remote host, the program, the KDC, and the remote host perform a set of rapid negotiations. When these negotiations are completed, your program has proven your identity on your behalf to the remote host, and the remote host has granted you access, all in the space of a few seconds.
The CSP-Kerberos applications are versions of existing UNIX network programs with the CSP-Kerberos features added.
The CSP-Kerberos network programs are those programs that connect to another host somewhere on the Internet. These programs include rlogin, telnet, ftp, rsh, rcp, and ksu. These programs have all of the original features of the corresponding standard rlogin, telnet, ftp, rsh, rcp, and su programs, plus additional features that use your CSP-Kerberos tickets for negotiating authentication and optional encryption with the remote host. In most cases, all you notice is that you no longer have to type your password, because CSP-Kerberos has already proven your identity.
The CSP-Kerberos network programs allow you the options of forwarding your tickets to the remote host (if you obtained forwardable tickets with the kinit program), and encrypting data transmitted between you and the remote host.
This section of the chapter assumes you are familiar with the standard versions of these programs, and highlights the CSP-Kerberos functions added in the CSP-Kerberos package.
The CSP-Kerberos telnet command works exactly like the standard telnet program, with the following CSP-Kerberos options added:
| -f, -forward | Forwards a copy of your tickets to the remote host. | |
| -noforward | Turns off forwarding of tickets to the remote host. (This option overrides any forwarding specified in your system's configuration files.) | |
| -F, -forwardable |
| |
| -noforwardable |
| |
| -k realm | Requests tickets for the remote host in the specified realm, instead of determining the realm itself. | |
| -K | Uses your tickets to authenticate to the remote host, but does not log you in. | |
| -a | Attempts automatic login using your tickets. The telnet command assumes the same user name unless you explicitly specify another. | |
| -x, -encrypt | Turns on encryption. | |
| -noencrypt | Turns off encryption. |
For example, if Dave wants to use the standard IRIX telnet to connect to the system laughter.yoursite.com, he enters the command:
telnet laughter.yoursite.com Trying 128.0.0.5 ... Connected to laughter.yoursite.com. Escape character is '^]'. NetBSD/i386 (laughter) (ttyp3) login: dave Password: <dave types his password here> Last login: Fri Jun 21 17:13:11 from rain.theirsite.com Copyright (c) 1980, 1983, 1986, 1988, 1990, 1991, 1993, 1994 The Regents of the University of California. All rights reserved. NetBSD 1.1: Tue May 21 00:31:42 EDT 1996 Welcome to NetBSD! |
Note that the system laughter.yoursite.com asked for Dave's password. When he typed it, his password was sent over the network unencrypted. If an intruder were watching network traffic at the time, that intruder would know Dave's password.
If, on the other hand, jennifer wanted to use the CSP-Kerberos telnet to connect to the system rain.theirsite.com, she could forward a copy of her tickets, request an encrypted session, and log in as herself, as follows:
telnet -a -f -x rain.theirsite.com Trying 128.0.0.5... Connected to rain.theirsite.com. Escape character is '^]'. [ CSP-Kerberos V5 accepts you as "jennifer@@theirsite.com" ] [ CSP-Kerberos V5 accepted forwarded credentials ] NetBSD 1.1: Tue May 21 00:31:42 EDT 1996 Welcome to NetBSD! |
Note that Jennifer's system used CSP-Kerberos to authenticate her to rain.theirsite.com, and logged her in automatically as herself. She had an encrypted session, a copy of her tickets already waiting for her, and she never typed her password.
If you forward your CSP-Kerberos tickets, telnet automatically destroys them when it exits. The full set of options to CSP-Kerberos telnet are discussed in the telnet reference page.
The CSP-Kerberos rlogin command works exactly like the standard rlogin program, with the following CSP-Kerberos options added:
| -f, -forward | Forwards a copy of your tickets to the remote host. | |
| -noforward | Turns off forwarding of tickets to the remote host. (This option overrides any forwarding specified in your system's configuration files.) | |
| -F, -forwardable |
| |
| -noforwardable |
| |
| -k realm | Requests tickets for the remote host in the specified realm, instead of determining the realm itself. | |
| -x, -encrypt | Turns on encryption. | |
| -noencrypt | Turns off encryption. |
For example, if Dave wanted to use the standard rlogin to connect to the system laughter.yoursite.com, he would enter the command:
rlogin laughter.yoursite.com -l dave Password: <dave types his password here> Last login: Fri Jun 21 10:36:32 from :0.0 Copyright (c) 1980, 1983, 1986, 1988, 1990, 1991, 1993, 1994 The Regents of the University of California. All rights reserved. NetBSD 1.1: Tue May 21 00:31:42 EDT 1996 Welcome to NetBSD! |
| Note: The system laughter.yoursite.com asks for Dave's password. When he types it, his password is sent over the network unencrypted. If an intruder were watching network traffic at the time, that intruder would know Dave's password. If, on the other hand, Jennifer wanted to use CSP-Kerberos rlogin to connect to the system rain.theirsite.com, she could forward a copy of her tickets, mark them as not forwardable from the remote host, and request an encrypted session as follows: |
rlogin rain.theirsite.com -f -x This rlogin session is using DES encryption for all data transmissions. Last login: Thu Jun 20 16:20:50 from laughter SunOS Release 4.1.4 (GENERIC) #2: Tue Nov 14 18:09:31 EST 1995 Not checking quotas. Try quota.real if you need them. |
Notice that Jennifer's system uses CSP-Kerberos to authenticate her to rain.theirsite.com, and logs her in automatically as herself. She has an encrypted session, a copy of her tickets are waiting for her, and she never types her password.
If you forward your CSP-Kerberos tickets, rlogin automatically destroys them when it exits. The full set of options to CSP-Kerberos rlogin are discussed in the rlogin reference page.
The CSP-Kerberos FTP program works exactly like the standard FTP program, with the following CSP-Kerberos features added:
| -k realm | Requests tickets for the remote host in the specified realm, instead of determining the realm itself. | |
| -forward | Requests that your tickets be forwarded to the remote host. The -forward argument must be the last argument on the command line. | |
| protect level | (issued at the ftp> prompt) Sets the protection level. Clear is no protection; Safe ensures data integrity by verifying the checksum, and Private encrypts the data. Encryption also ensures data integrity. |
For example, suppose Jennifer wants to get her RMAIL file from the directory ~jennifer/Mail, on the host laughter.yoursite.com. She wants to encrypt the file transfer. The exchange looks like this:
ftp laughter.yoursite.com Connected to laughter.yoursite.com. 220 laughter.yoursite.com FTP server (Version 5.60) ready. 334 Using authentication type GSSAPI; ADAT must follow GSSAPI accepted as authentication type GSSAPI authentication succeeded Name (laughter.yoursite.com:jennifer): <Return> 232 GSSAPI user jennifer@YOURSITE.COM is authorized as jennifer 230 User jennifer logged in. Remote system type is UNIX. Using binary mode to transfer files. ftp> protect private 200 Protection level set to Private. ftp> cd ~jennifer/MAIL 250 CWD command successful. ftp> get RMAIL 227 Entering Passive Mode (128,0,0,5,16,49) 150 Opening BINARY mode data connection for RMAIL (361662 bytes). 226 Transfer complete. 361662 bytes received in 2.5 seconds (1.4e+02 Kbytes/s) ftp> quit |
The full set of options to CSP-Kerberos FTP are discussed in the ftp reference page.
The CSP-Kerberos rsh program works exactly like the standard UNIX rsh program, with the following CSP-Kerberos features added:
| -f, -forward | Forwards a copy of your tickets to the remote host. | |
| -noforward | Turns off forwarding of tickets to the remote host. (This option overrides any forwarding specified in your system's configuration files.) | |
| -F, -forwardable |
| |
| -noforwardable |
| |
| -k realm | Requests tickets for the remote host in the specified realm, instead of determining the realm itself. | |
| -x, -encrypt | Turns on encryption. | |
| -noencrypt | Turns off encryption. |
For example, if your CSP-Kerberos tickets allowed you to run programs on the host rain@theirsite.com as root, you could run the date program as follows:
rsh rain.theirsite.com -l root -x date This rsh session is using DES encryption for all data transmissions. Fri Jun 21 17:06:12 EDT 1996 % |
If you forward your CSP-Kerberos tickets, rsh automatically destroys them when it exits. The full set of options to CSP-Kerberos rsh are discussed in the rsh reference page.
The CSP-Kerberos rcp program works exactly like the standard rcp program, with the following CSP-Kerberos features added:
| -k realm | Requests tickets for the remote host in the specified realm, instead of determining the realm itself. | |
| -x, -encrypt | Turns on encryption. |
For example, if you want to copy the file /etc/motd from the host laughter.yoursite.com into the current directory, through an encrypted connection, you simply type:
rcp -x laughter.yoursite.com:/etc/motd . |
The rcp program negotiates authentication and encryption transparently. The full set of options to CSP-Kerberos rcp are discussed in the rcp reference page.
The CSP-Kerberos ksu program replaces the standard IRIX su program. The ksu command first authenticates you to CSP-Kerberos. Depending on the configuration of your system, ksu may ask for your CSP-Kerberos password if authentication fails. Note that you should never type your password if you are remotely logged in using an unencrypted connection.
Once ksu has authenticated you, if your CSP-Kerberos principal appears in the target's .k5login file or in the target's .k5users file, it switches your user ID to the target user ID.
For example, Dave has put Jennifer's CSP-Kerberos principal in his .k5login file. If Jennifer uses ksu to become Dave, the exchange would look like the following example. (To differentiate between the two shells, Jennifer's prompt is represented as jennifer% and Dave's prompt is represented as dave%.)
jennifer% ksu dave Account dave: authorization for jennifer@YOURSITE.COM successful Changing uid to dave (3382) dave% |
Note that the new shell has a copy of Jennifer's tickets. The ticket filename contains Dave's UID with .1 appended to it:
dave% klist Ticket cache: /tmp/krb5cc_3382.1 Default principal: jennifer@YOURSITE.COM Valid starting Expires Service principal 31 Jul 96 21:53:01 01 Aug 96 07:52:53 krbtgt/YOURSITE.COM@YOURSITE.COM 31 Jul 96 21:53:39 01 Aug 96 07:52:53 host/laughter.yoursite.com@YOURSITE.COM dave% |
If Jennifer had not appeared in Dave's .k5login file (and the system was configured to ask for a password), the exchange would have looked like this (assuming Dave has taken appropriate precautions in protecting his password):
jennifer% ksu dave WARNING: Your password may be exposed if you enter it here and are logged in remotely using an unsecure (non-encrypted) channel. CSP-Kerberos password for dave@YOURSITE.COM: <jennifer types wrong password> ksu: Password incorrect Authentication failed. jennifer% |
Now, suppose Dave does not want to give Jennifer full access to his account, but wants to give her permission to list his files and use the more command to view them. He could create a .k5users file giving her permission to run only those specific commands.
The .k5users file is like the .k5login file, except that each principal is optionally followed by a list of commands. The ksu command lets those principals execute only the commands listed, using the -e option. Dave's .k5users file might look like this:
jennifer@YOURSITE.COM /bin/ls /usr/bin/more eugene@YOURSITE.COM /bin/ls eugene/admin@YOURSITE.COM * dave@THEIRSITE.COM |
The above .k5users file would let the account jennifer run only the commands /bin/ls and /usr/bin/more. It lets the account eugene run only the command /bin/ls if he has regular tickets, but if he has tickets for his admin instance, eugene/admin@YOURSITE.COM, he can execute any command. The last line gives Dave in the realm THEIRSITE.COM permission to execute any command. (For example, having only a CSP-Kerberos principal on a line is equivalent to giving that principal permission to execute anything.) This is so that Dave can allow himself to execute commands when he logs in, using CSP-Kerberos, from a system in the realm THEIRSITE.COM.
Then, when Jennifer wants to list his home directory, she types:
jennifer% ksu dave -e ls ~dave Authenticated jennifer@YOURSITE.COM Account dave: authorization for jennifer@YOURSITE.COM for execution of /bin/ls successful Changing uid to dave (3382) Mail News Personal misc bin jennifer% |
If Jennifer tries to give a different command to ksu, it prompts for a password as with the previous example.
Note that unless the .k5users file gives the target permission to run any command, the user must use ksu with the -e command option.
The ksu options you are most likely to use are:
| -n principal | Specifies which CSP-Kerberos principal you want to use for ksu. (For example, the user eugene might want to use his admin instance.) | |
| -c | Specifies the location of your CSP-Kerberos credentials cache (ticket file). | |
| -C | Specifies the location you want the CSP-Kerberos credentials cache (ticket file) to be for the target user ID. | |
| -k | Tells ksu not to destroy your CSP-Kerberos tickets when ksu is finished. | |
| -f | Requests forwardable tickets. This is applicable only if ksu needs to obtain tickets. | |
| -l lifetime | Sets the ticket lifetime. This is applicable only if ksu needs to obtain tickets. | |
| -z | Tells ksu to copy your CSP-Kerberos tickets only if the UID you are switching to is the same as the CSP-Kerberos primary (either yours or the one specified by the -n option). | |
| -Z | Tells ksu not to copy any CSP-Kerberos tickets to the new UID. | |
| -e command | Tells ksu to execute command and then exit. See the description of the .k5users file above. | |
| -a text | (At the end of the command line) Tells ksu to pass everything after -a to the target shell. |
The full set of options to CSP-Kerberos ksu are discussed in the ksu reference page.