New documentation from Cygnus

[krb5.git] / doc / user-guide.texinfo

\input texinfo @c -*-texinfo-*-
@c %**start of header
@c guide
@setfilename KerbNet-User.info
@settitle Kerb*Net UNIX User's Guide
@setchapternewpage odd                  @c chapter begins on next odd page
@c @setchapternewpage on                   @c chapter begins on next page
@smallbook                              @c Format for 7" X 9.25" paper
@c %**end of header

@paragraphindent 0
@iftex
@parskip 6pt plus 6pt
@end iftex

@include definitions.texinfo
@set EDITION 0.9 beta

@finalout                               @c don't print black warning boxes

@titlepage
@title @value{PRODUCT} UNIX User's Guide
@subtitle Release:  @value{RELEASE}
@subtitle Document Edition:  @value{EDITION}
@subtitle Last updated:  @value{UPDATED}
@author @value{COMPANY}

@page
@vskip 0pt plus 1filll

@include copyright.texinfo
@end titlepage

@comment  node-name,  next,  previous,  up
@node Top, Introduction, (dir), (dir)

@ifinfo
This file describes how to use the @value{PRODUCT} client programs.

@include copyright.texinfo
@end ifinfo

@c The master menu is updated using emacs19's M-x texinfo-all-menus-update
@c function.  Don't forget to run M-x texinfo-every-node-update after
@c you add a new section or subsection, or after you've rearranged the
@c comand before each @section or @subsection!  All you need to enter
@c is:
@c

@c @section New Section Name
@c
@c M-x texinfo-every-node-update will take care of calculating the
@c node's forward and back pointers.
@c
@c ---------------------------------------------------------------------

@menu
* Introduction::                
* @value{PRODUCT} Tutorial::    
* @value{PRODUCT} Reference::   
* Kerberos Glossary::           
@end menu

@node Introduction, @value{PRODUCT} Tutorial, Top, Top
@chapter Introduction

@value{PRODUCT} 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 Kerberos, a client (generally either a user or a service) sends a
request for a ticket to the @i{Key Distribution Center} (KDC).  The KDC
creates a @dfn{ticket-granting ticket} (TGT) for the client, encrypts it
using the client's 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 (@i{i.e.}, 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 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 @i{inside} firewalls,
@value{COMPANY}'s @value{PRODUCT} plays a vital role in maintaining your
nework security.

The @value{PRODUCT} package is designed to be easy to use.  Most of the
commands are nearly identical to UNIX network programs you are already
used to.  @value{PRODUCT} is a @dfn{single-sign-on} system, which means
that you have to type your password only once per session, and Kerberos
does the authenticating and encrypting transparently.

@iftex
@vfil
@end iftex
@need 2000
@menu
* What is a Ticket?::           
* What is a Kerberos Principal?::  
@end menu

@node What is a Ticket?, What is a Kerberos Principal?, Introduction, Introduction
@section What is a Ticket?

Your Kerberos @dfn{credentials}, or ``@dfn{tickets}'', are a set of
electronic information that can be used to verify your identity.  Your
Kerberos tickets may be stored in a file, or they may exist only in
memory.

The first ticket you obtain is a @dfn{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 @value{PRODUCT} 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.

@iftex
@vfil
@end iftex
@need 2000
@node What is a Kerberos Principal?,  , What is a Ticket?, Introduction
@section What is a Kerberos Principal?

A Kerberos @dfn{principal} is a unique identity to which Kerberos can
assign tickets.  By convention, a principal is divided into three parts:
the @dfn{primary}, the @dfn{instance}, and the @dfn{realm}.  The format
of a typical Kerberos V5 principal is @code{primary/instance@@REALM}.

@itemize @bullet
@item The @dfn{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 @code{host}.

@item The @dfn{instance} is an optional string that qualifies the
primary.  The instance is separated from the primary by a slash
(@code{/}).  In the case of a user, the instance is usually null, but a
user might also have an additional principal, with an instance called
@samp{admin}, which he/she uses to administrate a database.  The
principal @code{@value{RANDOMUSER1}@@@value{PRIMARYREALM}} is completely
separate from the principal
@code{@value{RANDOMUSER1}/admin@@@value{PRIMARYREALM}}, with a separate
password, and separate permissions.  In the case of a host, the instance
is the fully qualified hostname, e.g.,
@code{@value{RANDOMHOST1}.@value{PRIMARYDOMAIN}}.

@item The @dfn{realm} is your Kerberos realm.  In most cases, your
Kerberos realm is your domain name, in upper-case letters.  For example,
the machine @code{@value{RANDOMHOST1}.@value{PRIMARYDOMAIN}} would be in
the realm @code{@value{PRIMARYREALM}}.
@end itemize

@node @value{PRODUCT} Tutorial, @value{PRODUCT} Reference, Introduction, Top
@chapter @value{PRODUCT} Tutorial

This tutorial is intended to familiarize you with the @value{PRODUCT}
client programs.  We will represent your prompt as ``@code{shell%}''.
So an instruction to type the ``@kbd{ls}'' command would be represented as
follows:

@need 600
@smallexample
@group
@b{shell%} ls
@end group
@end smallexample

In these examples, we will use sample usernames, such as
@code{@value{RANDOMUSER1}} and @code{@value{RANDOMUSER2}}, sample
hostnames, such as @code{@value{RANDOMHOST1}} and
@code{@value{RANDOMHOST2}}, and sample domain names, such as
@code{@value{PRIMARYDOMAIN}} and @code{@value{SECONDDOMAIN}}.  When you
see one of these, substitute your username, hostname, or domain name
accordingly.

@menu
* Setting Up to Use @value{PRODUCT}::  
* Ticket Management::           
* Password Management::         
* @value{PRODUCT} Applications::  
@end menu

@node Setting Up to Use @value{PRODUCT}, Ticket Management, @value{PRODUCT} Tutorial, @value{PRODUCT} Tutorial
@section Setting Up to Use @value{PRODUCT}

Your system administrator will have installed the @value{PRODUCT}
programs in whichever directory makes the most sense for your system.
We will use @code{@value{ROOTDIR}} throughout this guide to refer to the
top-level directory @value{PRODUCT} directory.  We will therefor use
@code{@value{BINDIR}} to denote the location of the @value{PRODUCT} user
programs.  In your installation, the directory name may be different,
but whatever the directory name is, you should make sure it is included
in your path.  You will probably want to put it @i{ahead of} the
directories @code{/bin} and @code{/usr/bin} so you will get the
@value{PRODUCT} network programs, rather than the standard UNIX
versions, when you type their command names.

@node Ticket Management, Password Management, Setting Up to Use @value{PRODUCT}, @value{PRODUCT} Tutorial
@section Ticket Management

On many systems, Kerberos is built into the login program, and you get
tickets automatically when you log in.  Other programs, such as
@code{rsh}, @code{rcp}, @code{telnet}, and @code{rlogin}, can forward
copies of your tickets to the remote host.  Most of these programs also
automatically destroy your tickets when they exit.  However,
@value{COMPANY} recommends that you explicitly destroy your Kerberos
tickets when you are through with them, just to be sure.  One way to
help ensure that this happens is to add the @code{kdestroy} command to
your @code{.logout} file.  Additionally, if you are going to be away
from your machine 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.

@need 2000
@menu
* Obtaining Tickets with kinit::  
* Viewing Your Tickets with klist::  
* Destroying Your Tickets with kdestroy::  
@end menu

@node Obtaining Tickets with kinit, Viewing Your Tickets with klist, Ticket Management, Ticket Management
@subsection Obtaining Tickets with kinit

If your site is using the @value{PRODUCT} login program, you will get
Kerberos tickets automatically when you log in.  If your site uses a
different login program, you may need to explicitly obtain your Kerberos
tickets, using the @code{kinit} program.  Similarly, if your Kerberos
tickets expire, use the @code{kinit} program to obtain new ones.

@need 1500
To use the @code{kinit} program, simply type @kbd{kinit} and then type
your password at the prompt.  For example, Jennifer (whose username is
@code{@value{RANDOMUSER1}}) works for Bleep, Inc. (a fictitious company
with the domain name @code{@value{PRIMARYDOMAIN}} and the Kerberos realm
@code{@value{PRIMARYREALM}}).  She would type:

@smallexample
@group
@b{shell%} kinit
@b{Password for @value{RANDOMUSER1}@@@value{PRIMARYREALM}:} @i{<-- [Type @value{RANDOMUSER1}'s password here.]}
@b{shell%}
@end group
@end smallexample

@need 1000
If you type your password incorrectly, kinit will give you the following
error message:

@smallexample
@group
@b{shell%} kinit
@b{Password for @value{RANDOMUSER1}@@@value{PRIMARYREALM}:} @i{<-- [Type the wrong password here.]}
@b{kinit: Password incorrect}
@b{shell%}
@end group
@end smallexample

@noindent and you won't get Kerberos tickets.

@noindent Notice that @code{kinit} assumes you want tickets for your own
username in your default realm.  
@need 1500
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, @value{SECONDREALM}.@footnote{Note:  the realm
@value{SECONDREALM} must be listed in your computer's Kerberos
configuration file, @code{/etc/krb5.conf}.}  He would type:

@smallexample
@group
@b{shell%} kinit @value{RANDOMUSER2}@@@value{SECONDREALM}
@b{Password for @value{RANDOMUSER2}@@@value{SECONDREALM}:} @i{<-- [Type @value{RANDOMUSER2}'s password here.]}
@b{shell%}
@end group
@end smallexample

@noindent David would then have tickets which he could use to log onto
his own machine.  Note that he typed his password locally on Jennifer's
machine, but it never went over the network.  Kerberos on the local host
performed the authentication to the KDC in the other realm.

@need 1000
If you want to be able to forward your tickets to another host, you need
to request @dfn{forwardable} tickets.  You do this by specifying the
@kbd{-f} option:

@smallexample
@group
@b{shell%} kinit -f
@b{Password for @value{RANDOMUSER1}@@@value{PRIMARYREALM}:} @i{<-- [Type your password here.]}
@b{shell%}
@end group
@end smallexample

@noindent
Note that @code{kinit} does not tell you that it obtained forwardable
tickets; you can verify this using the @code{klist} command
(@pxref{Viewing Your Tickets with klist}).

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 @samp{-l} option.  Add the letter
@samp{s} to the value for seconds, @samp{m} for minutes, @samp{h} for
hours, or @samp{d} for days.
@need 1500
For example, to obtain forwardable tickets for
@code{@value{RANDOMUSER2}@@@value{SECONDREALM}} that would be good for
three hours, you would type:

@smallexample
@group
@b{shell%} kinit -f -l 3h @value{RANDOMUSER2}@@@value{SECONDREALM}
@b{Password for @value{RANDOMUSER2}@@@value{SECONDREALM}:} @i{<-- [Type @value{RANDOMUSER2}'s password here.]}
@b{shell%}
@end group
@end smallexample

@noindent
You cannot mix units; specifying a lifetime of @samp{3h30m} would result
in an error.  Note also that most systems specify a maximum ticket
lifetime.  If you request a longer ticket lifetime, it will be
automatically truncated to the maximum lifetime.

@iftex
@vfil
@end iftex
@need 3000
@node Viewing Your Tickets with klist, Destroying Your Tickets with kdestroy, Obtaining Tickets with kinit, Ticket Management
@subsection Viewing Your Tickets with klist

The @code{klist} command shows your tickets.  When you first obtain
tickets, you will have only the ticket-granting ticket.  (@xref{What is
a Ticket?}.)  The listing would look like this:

@smallexample
@group
@b{shell%} klist
Ticket cache: /tmp/krb5cc_ttypa
Default principal: @value{RANDOMUSER1}@@@value{PRIMARYREALM}

Valid starting     Expires            Service principal
06/07/96 19:49:21  06/08/96 05:49:19  krbtgt/@value{PRIMARYREALM}@@@value{PRIMARYREALM}
@b{shell%}
@end group
@end smallexample

@noindent
The ticket cache is the location of your ticket file.  In the above
example, this file is named @code{/tmp/krb5cc_ttypa}.  The default
principal is your kerberos @dfn{principal}.  (@pxref{What is a Kerberos
Principal?})

The ``valid starting'' and ``expires'' fields describe the period of
time during which the ticket is valid.  The @dfn{service principal}
describes each ticket.  The ticket-granting ticket has the primary
@code{krbtgt}, and the instance is the realm name.

@need 2000
Now, if @value{RANDOMUSER1} connected to the machine
@code{@value{RANDOMHOST1}.@value{PRIMARYDOMAIN}}, and then typed
@kbd{klist} again, she would have gotten the following result:

@smallexample
@group
@b{shell%} klist
Ticket cache: /tmp/krb5cc_ttypa
Default principal: @value{RANDOMUSER1}@@@value{PRIMARYREALM}

Valid starting     Expires            Service principal
06/07/96 19:49:21  06/08/96 05:49:19  krbtgt/@value{PRIMARYREALM}@@@value{PRIMARYREALM}
06/07/96 20:22:30  06/08/96 05:49:19  host/@value{RANDOMHOST1}.@value{PRIMARYDOMAIN}@@@value{PRIMARYREALM}
@b{shell%}
@end group
@end smallexample

@noindent
Here's what happened:  when @value{RANDOMUSER1} used telnet to connect
to the host @code{@value{RANDOMHOST1}.@value{PRIMARYDOMAIN}}, the telnet
program presented her ticket-granting ticket to the KDC and requested a
host ticket for the host
@code{@value{RANDOMHOST1}.@value{PRIMARYDOMAIN}}.  The KDC sent the host
ticket, which telnet then presented to the host
@code{@value{RANDOMHOST1}.@value{PRIMARYDOMAIN}}, and she was allowed to
log in without typing her password.
@iftex
@vfil
@end iftex

@need 3000
Suppose your Kerberos tickets allow you to log into a host in another
domain, such as @code{@value{RANDOMHOST2}.@value{SECONDDOMAIN}}, which
is also in another Kerberos realm, @code{@value{SECONDREALM}}.  If you
telnet to this host, you will receive a ticket-granting ticket for the
realm @code{@value{SECONDREALM}}, plus the new @code{host} ticket for
@code{@value{RANDOMHOST2}.@value{SECONDDOMAIN}}.  @kbd{klist} will now
show:

@smallexample
@group
@b{shell%} klist
Ticket cache: /tmp/krb5cc_ttypa
Default principal: @value{RANDOMUSER1}@@@value{PRIMARYREALM}

Valid starting     Expires            Service principal
06/07/96 19:49:21  06/08/96 05:49:19  krbtgt/@value{PRIMARYREALM}@@@value{PRIMARYREALM}
06/07/96 20:22:30  06/08/96 05:49:19  host/@value{RANDOMHOST1}.@value{PRIMARYDOMAIN}@@@value{PRIMARYREALM}
06/07/96 20:24:18  06/08/96 05:49:19  krbtgt/@value{SECONDREALM}@@@value{PRIMARYREALM}
06/07/96 20:24:18  06/08/96 05:49:19  host/@value{RANDOMHOST2}.@value{SECONDDOMAIN}@@@value{PRIMARYREALM}
@b{shell%}
@end group
@end smallexample

You can use the @code{-f} option to view the @dfn{flags} that apply to
your tickets.  The flags are:

@table @b
@itemx F
@b{F}orwardable
@itemx f
@b{f}orwarded
@itemx P
@b{P}roxiable
@itemx p
@b{p}roxy
@itemx D
post@b{D}ateable
@itemx d
post@b{d}ated
@itemx R
@b{R}enewable
@itemx I
@b{I}nitial
@itemx i
@b{i}nvalid
@end table

@need 1500
Here is a sample listing.  In this example, the user @value{RANDOMUSER1}
obtained her initial tickets (@samp{I}), which are forwardable
(@samp{F}) and postdated (@samp{d}) but not yet validated (@samp{i}).
(@xref{kinit Reference} for more information about postdated tickets.)

@smallexample
@group
@b{shell%} klist -f
@b{Ticket cache: /tmp/krb5cc_320
Default principal: @value{RANDOMUSER1}@@@value{PRIMARYREALM}

Valid starting      Expires             Service principal
31 Jul 96 19:06:25  31 Jul 96 19:16:25  krbtgt/@value{PRIMARYREALM}@@@value{PRIMARYREALM}
        Flags: FdiI
shell%}
@end group
@end smallexample

@need 1500
In the following example, the user @value{RANDOMUSER2}'s tickets were
forwarded (@samp{f}) to this host from another host.  The tickets are
reforwardable (@samp{F}).

@smallexample
@group
@b{shell%} klist -f
@b{Ticket cache: /tmp/krb5cc_p11795
Default principal: @value{RANDOMUSER2}@@@value{SECONDREALM}

Valid starting     Expires            Service principal
07/31/96 11:52:29  07/31/96 21:11:23  krbtgt/@value{SECONDREALM}@@@value{SECONDREALM}
        Flags: Ff
07/31/96 12:03:48  07/31/96 21:11:23  host/@value{RANDOMHOST2}.@value{SECONDDOMAIN}@@@value{SECONDREALM}
        Flags: Ff
shell%}
@end group
@end smallexample

@iftex
@vfil
@end iftex
@need 2000
@node Destroying Your Tickets with kdestroy,  , Viewing Your Tickets with klist, Ticket Management
@subsection Destroying Your Tickets with kdestroy

Your 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 Kerberos tickets when you are away from your computer.

@need 1000
Destroying your tickets is easy.  Simply type @kbd{kdestroy}.

@smallexample
@group
@b{shell%} kdestroy
@b{shell%}
@end group
@end smallexample

@need 1500
If @code{kdestroy} fails to destroy your tickets, it will beep and give
an error message.  For example, if @code{kdestroy} can't find any
tickets to destroy, it will give the following message:

@smallexample
@group
@b{shell%} kdestroy
@b{kdestroy: No credentials cache file found while destroying cache
Ticket cache NOT destroyed!
shell%}
@end group
@end smallexample

@iftex
@vfil
@end iftex
@need 2000
@node Password Management, @value{PRODUCT} Applications, Ticket Management, @value{PRODUCT} Tutorial
@section Password Management

Your password is the only way Kerberos has of verifying your identity.
If someone finds out your password, that person can masquerade as
you---send email that comes from you, read, edit, or delete your files,
or log into other hosts as you---and no one will be able to tell the
difference.  For this reason, it is important that you choose a good
password (@pxref{Password Advice}), and keep it secret.  If you need to
give access to your account to someone else, you can do so through
Kerberos.  (@xref{Granting Access to Your Account}.)  You should
@i{never} tell your password to anyone, including your system
administrator, for any reason.  You should change your password
frequently, particularly any time you think someone may have found out
what it is.

@iftex
@vfil
@end iftex
@need 2000
@menu
* Changing Your Password::      
* Password Advice::             
* Granting Access to Your Account::  
@end menu

@node Changing Your Password, Password Advice, Password Management, Password Management
@subsection Changing Your Password

@need 2500
To change your Kerberos password, use the @code{kpasswd} command.  It
will ask you for your old password (to prevent someone else from walking
up to your computer when you're not there and changing your password),
and then prompt 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 @code{@value{RANDOMUSER2}} would do the following:

@smallexample
@group
@b{shell%} kpasswd
@b{Old password for @value{RANDOMUSER2}:}    @i{<- Type your old password.}
@b{New Password for @value{RANDOMUSER2}:}    @i{<- Type your new password.}
@b{Verifying, please re-enter New Password for @value{RANDOMUSER2}:}  @i{<- Type the new password again.}
@b{Password changed.}
@b{shell%}
@end group
@end smallexample

@need 1800
If @value{RANDOMUSER2} typed the incorrect old password, he would get
the following message:

@smallexample
@group
@b{shell%} kpasswd
@b{Old password for @value{RANDOMUSER2}:}  @i{<- Type the incorrect old password.}
@b{Incorrect old password.
shell%}
@end group
@end smallexample

@need 2500
If you make a mistake and don't type the new password the same way
twice, @code{kpasswd} will ask you to try again:

@smallexample
@group
@b{shell%} kpasswd
@b{Old password for @value{RANDOMUSER2}:}  @i{<- Type the old password.}
@b{New Password for @value{RANDOMUSER2}:}  @i{<- Type the new password.}
@b{Verifying, please re-enter New Password for @value{RANDOMUSER2}:} @i{<- Type a different new password.}
@b{Mismatch - try again
New Password for @value{RANDOMUSER2}:}  @i{<- Type the new password.}
@b{Verifying, please re-enter New Password for @value{RANDOMUSER2}:} @i{<- Type the same new password.}
@b{Password changed.
shell%}
@end group
@end smallexample

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 Kerberos tickets shortly after changing your password,
try the new password.  If the new password doesn't work, try again using
the old one.
@iftex
@vfil
@end iftex

@need 2000
@node Password Advice, Granting Access to Your Account, Changing Your Password, Password Management
@subsection Password Advice

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 @i{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 username in any form (@i{e.g.}, forward, backward, repeated
twice, @i{etc.}), 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.

@need 2200
@value{COMPANY} recommends that your password be at least 6 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:

@itemize @bullet
@item some initials, like ``GykoR-66.'' for ``Get your kicks on Route
66.''

@item an easy-to-pronounce nonsense word, like ``slaRooBey'' or
``krang-its''

@item a misspelled phrase, like ``2HotPeetzas!'' or ``ItzAGurl!!!''
@end itemize

@noindent Note:  don't actually use any of the above passwords.  They're
only meant to show you how to make up a good password.  Passwords that
appear in a manual are the first ones intruders will try.
@iftex
@vfil
@end iftex

@need 3800
@value{PRODUCT} allows your system administrators to automatically
reject bad passwords, based on whatever criteria they choose.  For
example, if the user @code{@value{RANDOMUSER1}} chose a bad password,
Kerberos would give an error message like the following:

@smallexample
@group
@b{shell%} kpasswd
@b{Old password for @value{RANDOMUSER1}:}  @i{<- Type your old password here.}
@b{New Password for @value{RANDOMUSER1}:}  @i{<- Type an insecure new password.}
@b{Verifying, please re-enter New Password for @value{RANDOMUSER1}:}  @i{<- Type it again.}

ERROR: Insecure password not accepted.  Please choose another.

kpasswd: Insecure password rejected while attempting to change password.
Please choose another password.

@b{New Password for @value{RANDOMUSER1}:}  @i{<- Type a good password here.}
@b{Verifying, please re-enter New Password for @value{RANDOMUSER2}:}  @i{<- Type it again.}
@b{Password changed.
shell%}
@end group
@end smallexample

@noindent 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.

@iftex
@vfil
@end iftex
@need 2000
@node Granting Access to Your Account,  , Password Advice, Password Management
@subsection Granting Access to Your Account

@need 1800
If you need to give someone access to log into your account, you can do
so through Kerberos, without telling the person your password.  Simply
create a file called @code{.k5login} in your home directory.  This file
should contain the Kerberos principal (@xref{What is a Kerberos
Principal?}) of each person to whom you wish to give access.  Each
principal must be on a separate line.  Here is a sample @code{.k5login}
file:

@smallexample
@group
@value{RANDOMUSER1}@@@value{PRIMARYREALM}
@value{RANDOMUSER2}@@@value{SECONDREALM}
@end group
@end smallexample

@noindent This file would allow the users @code{@value{RANDOMUSER1}} and
@code{@value{RANDOMUSER2}} to use your user ID, provided that they had
Kerberos tickets in their respective realms.  If you will be logging
into other hosts across a network, you will want to include your own
Kerberos principal in your @code{.k5login} file on each of these hosts.

@need 1000
Using a @code{.k5login} file is much safer than giving out your
password, because:

@itemize @bullet
@item You can take access away any time simply by removing the principal
from your @code{.k5login} file.

@item Although the user has full access to your account on one
particular host (or set of hosts if your @code{.k5login} file is shared,
@i{e.g.}, over NFS), that user does not inherit your network privileges.

@item 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.
@end itemize

One common application is to have a @code{.k5login} file in
@code{root}'s home directory, giving root access to that machine to the
Kerberos principals listed.  This allows system administrators to allow
users to become root locally, or to log in remotely as @code{root},
without their having to give out the root password, and without anyone
having to type the root password over the network.

@iftex
@vfil
@end iftex
@need 2000

@node @value{PRODUCT} Applications,  , Password Management, @value{PRODUCT} Tutorial
@section @value{PRODUCT} Applications

@value{PRODUCT} is a @dfn{single-sign-on} system.  This means that you
only have to type your password once, and the @value{PRODUCT} programs
do the authenticating (and optionally encrypting) for you.  The way this
works is that Kerberos has been built into each of a suite of network
programs.  For example, when you use a @value{PRODUCT} 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 @value{PRODUCT} applications are versions of existing UNIX network
programs with the Kerberos features added.

@iftex
@vfil
@end iftex
@need 2000
@menu
* Overview of Additional Features::  
* telnet::                      
* rlogin::                      
* FTP::                         
* rsh::                         
* rcp::                         
* ksu::                         
@end menu

@node Overview of Additional Features, telnet, @value{PRODUCT} Applications, @value{PRODUCT} Applications
@subsection Overview of Additional Features

The @value{PRODUCT} @dfn{network programs} are those programs that
connect to another host somewhere on the internet.  These programs
include @code{rlogin}, @code{telnet}, @code{ftp}, @code{rsh},
@code{rcp}, @code{krdist}, and @code{ksu}.  These programs have all of
the original features of the corresponding non-Kerberos @code{rlogin},
@code{telnet}, @code{ftp}, @code{rsh}, @code{rcp}, @code{rdist}, and
@code{su} programs, plus additional features that transparently use your
Kerberos tickets for negotiating authentication and optional encryption
with the remote host.  In most cases, all you'll notice is that you no
longer have to type your password, because Kerberos has already proven
your identity.

The @value{PRODUCT} network programs allow you the options of forwarding
your tickets to the remote host (if you obtained forwardable tickets
with the @code{kinit} program; @pxref{Obtaining Tickets with kinit}), and
encrypting data transmitted between you and the remote host.

This section of the tutorial assumes you are familiar with the
non-Kerberos versions of these programs, and highlights the Kerberos
functions added in the @value{PRODUCT} package.

@iftex
@vfil
@end iftex
@need 2000
@node telnet, rlogin, Overview of Additional Features, @value{PRODUCT} Applications
@subsection telnet

The @value{PRODUCT} @code{telnet} command works exactly like the
standard UNIX telnet program, with the following Kerberos options added:

@table @kbd
@itemx -f, --forward
forwards a copy of your tickets to the remote host.

@itemx --noforward
turns off forwarding of tickets to the remote host.  (This option
overrides any forwarding specified in your machine's configuration
files.)

@itemx -F, --forwardable
forwards a copy of your tickets to the remote host, and marks them
re-forwardable from the remote host.

@itemx --noforwardable
makes any forwarded tickets nonforwardable.  (This option overrides any
forwardability specified in your machine's configuration files.)

@itemx -k @i{realm}
requests tickets for the remote host in the specified realm, instead of
determining the realm itself.

@itemx -K
uses your tickets to authenticate to the remote host, but does not log
you in.

@itemx -a
attempt automatic login using your tickets.  @code{telnet} will assume
the same username unless you explicitly specify another.

@itemx -x, --encrypt
turns on encryption.

@itemx --noencrypt
turns off encryption.
@end table

@iftex
@vfil
@end iftex

@need 4000
For example, if @code{@value{RANDOMUSER2}} wanted to use the standard
UNIX telnet to connect to the machine
@code{@value{RANDOMHOST1}.@value{PRIMARYDOMAIN}}, he would type:

@smallexample
@group
@b{shell%} telnet @value{RANDOMHOST1}.@value{PRIMARYDOMAIN}
@b{Trying 128.0.0.5 ...
Connected to @value{RANDOMHOST1}.@value{PRIMARYDOMAIN}.
Escape character is '^]'.

NetBSD/i386 (@value{RANDOMHOST1}) (ttyp3)

login:} @value{RANDOMUSER2}
@b{Password:}    @i{<- @value{RANDOMUSER2} types his password here}
@b{Last login: Fri Jun 21 17:13:11 from @value{RANDOMHOST2}.@value{SECONDDOMAIN}
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!
shell%}
@end group
@end smallexample

@noindent Note that the machine
@code{@value{RANDOMHOST1}.@value{PRIMARYDOMAIN}} asked for
@code{@value{RANDOMUSER2}}'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
@code{@value{RANDOMUSER2}}'s password.

@iftex
@vfil
@end iftex
@need 4000
If, on the other hand, @code{@value{RANDOMUSER1}} wanted to use the
@value{PRODUCT} telnet to connect to the machine
@code{@value{RANDOMHOST2}.@value{SECONDDOMAIN}}, she could forward a
copy of her tickets, request an encrypted session, and log on as herself
as follows:

@smallexample
@group
@b{shell%} telnet -a -f -x @value{RANDOMHOST2}.@value{SECONDDOMAIN}
@b{Trying 128.0.0.5...
Connected to @value{RANDOMHOST2}.@value{SECONDDOMAIN}.
Escape character is '^]'.
[ Kerberos V5 accepts you as ``@value{RANDOMUSER1}@@@value{SECONDDOMAIN}'' ]
[ Kerberos V5 accepted forwarded credentials ]
NetBSD 1.1: Tue May 21 00:31:42 EDT 1996

Welcome to NetBSD!
shell%}
@end group
@end smallexample

@noindent Note that @code{@value{RANDOMUSER1}}'s machine used Kerberos
to authenticate her to @code{@value{RANDOMHOST2}.@value{SECONDDOMAIN}},
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 forwarded your Kerberos tickets, @code{telnet} automatically
destroys them when it exits.  The full set of options to @value{PRODUCT}
@code{telnet} are discussed in the Reference section of this manual.
(@pxref{telnet Reference})

@iftex
@vfil
@end iftex
@need 2000
@node rlogin, FTP, telnet, @value{PRODUCT} Applications
@subsection rlogin

@need 1000
The @value{PRODUCT} @code{rlogin} command works exactly like the
standard UNIX rlogin program, with the following Kerberos options added:

@table @kbd
@itemx -f, --forward
forwards a copy of your tickets to the remote host.

@itemx --noforward
turns off forwarding of tickets to the remote host.  (This option
overrides any forwarding specified in your machine's configuration
files.)

@itemx -F, --forwardable
forwards a copy of your tickets to the remote host, and marks them
re-forwardable from the remote host.

@itemx --noforwardable
makes any forwarded tickets nonforwardable.  (This option overrides any
forwardability specified in your machine's configuration files.)

@itemx -k @i{realm}
requests tickets for the remote host in the specified realm, instead of
determining the realm itself.

@itemx -x, --encrypt
turns on encryption.

@itemx --noencrypt
turns off encryption.
@end table

@need 3000
For example, if @code{@value{RANDOMUSER2}} wanted to use the standard
UNIX rlogin to connect to the machine
@code{@value{RANDOMHOST1}.@value{PRIMARYDOMAIN}}, he would type:

@smallexample
@group
@b{shell%} rlogin @value{RANDOMHOST1}.@value{PRIMARYDOMAIN} -l @value{RANDOMUSER2}
@b{Password:}  @i{<- @value{RANDOMUSER2} types his password here}
@b{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!
shell%}
@end group
@end smallexample

@noindent Note that the machine
@code{@value{RANDOMHOST1}.@value{PRIMARYDOMAIN}} asked for
@code{@value{RANDOMUSER2}}'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
@code{@value{RANDOMUSER2}}'s password.

@iftex
@vfil
@end iftex
@need 4000
If, on the other hand, @code{@value{RANDOMUSER1}} wanted to use
@value{PRODUCT} rlogin to connect to the machine
@code{@value{RANDOMHOST2}.@value{SECONDDOMAIN}}, she could forward a
copy of her tickets, mark them as not forwardable from the remote host,
and request an encrypted session as follows:

@smallexample
@group
@b{shell%} rlogin @value{RANDOMHOST2}.@value{SECONDDOMAIN} -f -x
@b{This rlogin session is using DES encryption for all data transmissions.
Last login: Thu Jun 20 16:20:50 from @value{RANDOMHOST1}
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.
shell%}
@end group
@end smallexample

@noindent Note that @code{@value{RANDOMUSER1}}'s machine used Kerberos
to authenticate her to @code{@value{RANDOMHOST2}.@value{SECONDDOMAIN}},
and logged her in automatically as herself.  She had an encrypted
session, a copy of her tickets were waiting for her, and she never typed
her password.

If you forwarded your Kerberos tickets, @code{rlogin} automatically
destroys them when it exits.  The full set of options to @value{PRODUCT}
@code{rlogin} are discussed in the Reference section of this manual.
(@pxref{rlogin Reference})

@iftex
@vfil
@end iftex
@need 2000
@node FTP, rsh, rlogin, @value{PRODUCT} Applications
@subsection FTP

@need 1000
The @value{PRODUCT} @code{FTP} program works exactly like the standard
UNIX FTP program, with the following Kerberos features added:

@table @kbd
@itemx -k @i{realm}
requests tickets for the remote host in the specified realm, instead of
determining the realm itself.

@itemx -forward
requests that your tickets be forwarded to the remote host.  The
@kbd{-forward} argument must be the last argument on the command line.

@itemx protect @i{level}
(issued at the @code{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.
@end table

@need 5000
For example, suppose @code{@value{RANDOMUSER1}} wants to get her
@code{RMAIL} file from the directory @code{~@value{RANDOMUSER1}/Mail},
on the host @code{@value{RANDOMHOST1}.@value{PRIMARYDOMAIN}}.  She wants
to encrypt the file transfer.  The exchange would look like the
following:

@smallexample
@group
@b{shell%} ftp @value{RANDOMHOST1}.@value{PRIMARYDOMAIN}
Connected to @value{RANDOMHOST1}.@value{PRIMARYDOMAIN}.
220 @value{RANDOMHOST1}.@value{PRIMARYDOMAIN} FTP server (Version 5.60) ready.
334 Using authentication type GSSAPI; ADAT must follow
GSSAPI accepted as authentication type
GSSAPI authentication succeeded
Name (@value{RANDOMHOST1}.@value{PRIMARYDOMAIN}:@value{RANDOMUSER1}): 
232 GSSAPI user @value{RANDOMUSER1}@@@value{PRIMARYREALM} is authorized as @value{RANDOMUSER1}
230 User @value{RANDOMUSER1} logged in.
Remote system type is UNIX.
Using binary mode to transfer files.
ftp> protect private
200 Protection level set to Private.
ftp> cd ~@value{RANDOMUSER1}/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
@b{shell%}
@end group
@end smallexample

The full set of options to @value{PRODUCT} @code{FTP} are discussed
in the Reference section of this manual.  (@pxref{FTP Reference})

@iftex
@vfil
@end iftex
@need 2000
@node rsh, rcp, FTP, @value{PRODUCT} Applications
@subsection rsh

@need 1000
The @value{PRODUCT} @code{rsh} program works exactly like the standard
UNIX rlogin program, with the following Kerberos features added:

@table @kbd
@itemx -f, --forward
forwards a copy of your tickets to the remote host.

@itemx --noforward
turns off forwarding of tickets to the remote host.  (This option
overrides any forwarding specified in your machine's configuration
files.)

@itemx -F, --forwardable
forwards a copy of your tickets to the remote host, and marks them
re-forwardable from the remote host.

@itemx --noforwardable
makes any forwarded tickets nonforwardable.  (This option overrides any
forwardability specified in your machine's configuration files.)

@itemx -k @i{realm}
requests tickets for the remote host in the specified realm, instead of
determining the realm itself.

@itemx -x, --encrypt
turns on encryption.

@itemx --noencrypt
turns off encryption.
@end table

@need 1800
For example, if your Kerberos tickets allowed you to run programs on the
host @code{@value{RANDOMHOST2}@@@value{SECONDDOMAIN}} as root, you could
run the @samp{date} program as follows:

@smallexample
@group
@b{shell%} rsh @value{RANDOMHOST2}.@value{SECONDDOMAIN} -l root -x date
@b{This rsh session is using DES encryption for all data transmissions.
Fri Jun 21 17:06:12 EDT 1996
shell%}
@end group
@end smallexample

If you forwarded your Kerberos tickets, @code{rsh} automatically
destroys them when it exits.  The full set of options to @value{PRODUCT}
@code{rsh} are discussed in the Reference section of this manual.
(@pxref{rsh Reference})

@iftex
@vfil
@end iftex
@need 2000
@node rcp, ksu, rsh, @value{PRODUCT} Applications
@subsection rcp

@need 1000
The @value{PRODUCT} @code{rcp} program works exactly like the standard
UNIX rcp program, with the following Kerberos features added:

@table @kbd
@itemx -k @i{realm}
requests tickets for the remote host in the specified realm, instead of
determining the realm itself.

@itemx -x, --encrypt
turns on encryption.
@end table


@need 1500
For example, if you wanted to copy the file @code{/etc/motd} from the
host @code{@value{RANDOMHOST1}.@value{PRIMARYDOMAIN}} into the current
directory, via an encrypted connection, you would simply type:

@smallexample
@b{shell%} rcp -x @value{RANDOMHOST1}.@value{PRIMARYDOMAIN}:/etc/motd .
@end smallexample

The @kbd{rcp} program negotiates authentication and encryption
transparently.  The full set of options to @value{PRODUCT} @code{rcp}
are discussed in the Reference section of this manual.  (@pxref{rcp
Reference})

@iftex
@vfil
@end iftex
@need 2000
@node ksu,  , rcp, @value{PRODUCT} Applications
@subsection ksu

The @value{PRODUCT} @code{ksu} program replaces the standard UNIX su
program.  @code{ksu} first authenticates you to Kerberos.  Depending on
the configuration of your system, @code{ksu} may ask for your Kerberos
password if authentication fails.  @emph{Note that you should never type
your password if you are remotely logged in using an unencrypted
connection.}

Once @code{ksu} has authenticated you, if your Kerberos principal
appears in the target's @code{.k5login} file (@pxref{Granting Access to
Your Account}) or in the target's @code{.k5users} file (see below), it
switches your user ID to the target user ID.

@need 2000
For example, @code{@value{RANDOMUSER2}} has put
@code{@value{RANDOMUSER1}}'s Kerberos principal in his @code{.k5login}
file.  If @code{@value{RANDOMUSER1}} uses @code{ksu} to become
@code{@value{RANDOMUSER2}}, the exchange would look like this.  (To
differentiate between the two shells, @code{@value{RANDOMUSER1}}'s
prompt is represented as @code{@value{RANDOMUSER1}%} and
@code{@value{RANDOMUSER2}}'s prompt is represented as
@code{@value{RANDOMUSER2}%}.)

@smallexample
@group
@b{@value{RANDOMUSER1}%} ksu @value{RANDOMUSER2}
@b{Account @value{RANDOMUSER2}: authorization for @value{RANDOMUSER1}@@@value{PRIMARYREALM} successful
Changing uid to @value{RANDOMUSER2} (3382)
@value{RANDOMUSER2}%}
@end group
@end smallexample

@noindent
Note that the new shell has a copy of @code{@value{RANDOMUSER1}}'s
tickets.  The ticket filename contains @code{@value{RANDOMUSER2}}'s UID
with @samp{.1} appended to it:

@smallexample
@group
@b{@value{RANDOMUSER2}%} klist
@b{Ticket cache: /tmp/krb5cc_3382.1
Default principal: @value{RANDOMUSER1}@@@value{PRIMARYREALM}

Valid starting      Expires             Service principal
31 Jul 96 21:53:01  01 Aug 96 07:52:53  krbtgt/@value{PRIMARYREALM}@@@value{PRIMARYREALM}
31 Jul 96 21:53:39  01 Aug 96 07:52:53  host/@value{RANDOMHOST1}.@value{PRIMARYDOMAIN}@@@value{PRIMARYREALM}
@value{RANDOMUSER2}%}
@end group
@end smallexample

@need 2500
If @code{@value{RANDOMUSER1}} had not appeared in
@code{@value{RANDOMUSER2}}'s @code{.k5login} file (and the system was
configured to ask for a password), the exchange would have looked like
this (assuming @code{@value{RANDOMUSER2}} has taken appropriate
precautions in protecting his password):

@smallexample
@group
@b{@value{RANDOMUSER1}%} ksu @value{RANDOMUSER2}
@b{WARNING: Your password may be exposed if you enter it here and are logged 
         in remotely using an unsecure (non-encrypted) channel. 
Kerberos password for @value{RANDOMUSER2}@@@value{PRIMARYREALM}:}  @i{<-  @code{@value{RANDOMUSER1}} types the wrong password here.}
@b{ksu: Password incorrect
Authentication failed.
@value{RANDOMUSER1}%}
@end group
@end smallexample

Now, suppose @code{@value{RANDOMUSER2}} did not want to give
@code{@value{RANDOMUSER1}} full access to his account, but wanted to
give her permission to list his files and use the "more" command to view
them.  He could create a @code{.k5users} file giving her permission to
run only those specific commands.

@need 3500
The @code{.k5users} file is like the @code{.k5login} file, except that
each principal is optionally followed by a list of commands.  @code{ksu}
will let those principals execute only the commands listed, using the
@kbd{-e} option.  @code{@value{RANDOMUSER2}}'s @code{.k5users} file
might look like the following:

@smallexample
@group
@value{RANDOMUSER1}@@@value{PRIMARYREALM}       /bin/ls /usr/bin/more
@value{ADMINUSER}@@@value{PRIMARYREALM}         /bin/ls
@value{ADMINUSER}/admin@@@value{PRIMARYREALM}   *
@value{RANDOMUSER2}@@@value{SECONDREALM}
@end group
@end smallexample

@noindent The above @code{.k5users} file would let
@code{@value{RANDOMUSER1}} run only the commands @code{/bin/ls} and
@code{/usr/bin/more}.  It would let @code{@value{ADMINUSER}} run only
the command @code{/bin/ls} if he had regular tickets, but if he had
tickets for his @code{admin} instance,
@code{@value{ADMINUSER}/admin@@@value{PRIMARYREALM}}, he would be able
to execute any command.  The last line gives @code{@value{RANDOMUSER2}}
in the realm @value{SECONDREALM} permission to execute any command.
(@i{I.e.}, having only a Kerberos principal on a line is equivalent to
giving that principal permission to execute @code{*}.)  This is so that
@value{RANDOMUSER2} can allow himself to execute commands when he logs
in, using Kerberos, from a machine in the realm @value{SECONDREALM}.

@need 2500
Then, when @code{@value{RANDOMUSER1}} wanted to list his home directory,
she would type:

@smallexample
@group
@b{@value{RANDOMUSER1}%} ksu @value{RANDOMUSER2} -e ls ~@value{RANDOMUSER2}
@b{Authenticated @value{RANDOMUSER1}@@@value{PRIMARYREALM}
Account @value{RANDOMUSER2}: authorization for @value{RANDOMUSER1}@@@value{PRIMARYREALM} for execution of
               /bin/ls successful
Changing uid to @value{RANDOMUSER2} (3382)
Mail            News            Personal        misc            bin
@value{RANDOMUSER1}%}
@end group
@end smallexample

@noindent If @code{@value{RANDOMUSER1}} had tried to give a different
command to @code{ksu}, it would have prompted for a password as with the
previous example.

Note that unless the @code{.k5users} file gives the target permission to
run any command, the user must use @code{ksu} with the @kbd{-e}
@i{command} option.

@need 1000
The @code{ksu} options you are most likely to use are:

@table @kbd
@itemx -n @i{principal}
specifies which Kerberos principal you want to use for @code{ksu}.
(@i{e.g.}, the user @code{@value{ADMINUSER}} might want to use his
@code{admin} instance.  @xref{What is a Ticket?}.)

@itemx -c
specifies the location of your Kerberos credentials cache (ticket file).

@itemx -C
specifies the location you want the Kerberos credentials cache (ticket
file) to be for the target user ID.

@itemx -k
tells @code{ksu} not to destroy your Kerberos tickets when @code{ksu} is
finished.

@itemx -f
requests forwardable tickets.  (@xref{Obtaining Tickets with kinit}.)  This
is only applicable if @code{ksu} needs to obtain tickets.

@itemx -l @i{lifetime}
sets the ticket lifetime.  (@xref{Obtaining Tickets with kinit}.)  This is
only applicable if @code{ksu} needs to obtain tickets.

@itemx -z
tells @code{ksu} to copy your Kerberos tickets only if the UID you are
switching is the same as the Kerberos primary (either yours or the one
specified by the @kbd{-n} option).

@itemx -Z
tells @code{ksu} not to copy any Kerberos tickets to the new UID.

@itemx -e @i{command}
tells @code{ksu} to execute @i{command} and then exit.  See the
description of the @code{.k5users} file above.

@itemx -a @i{text}
(at the end of the command line) tells @code{ksu} to pass everything
after @samp{-a} to the target shell.
@end table

The full set of options to @value{PRODUCT} @code{ksu} are discussed
in the Reference section of this manual.  (@pxref{ksu Reference})

@node @value{PRODUCT} Reference, Kerberos Glossary, @value{PRODUCT} Tutorial, Top
@chapter @value{PRODUCT} Reference

This section will include copies of the manual pages for the
@value{PRODUCT} client programs.  You can read the manual entry for any
command by typing @code{man} @i{command}, where @i{command} is the name
of the command for which you want to read the manual entry.  For
example, to read the @code{kinit} manual entry, you would type:

@smallexample
@b{shell%} man kinit
@end smallexample

Note:  To be able to view the @value{PRODUCT} manual pages on line, you
may need to add the directory @code{@value{ROOTDIR}/man} to your MANPATH
environment variable.  (Remember to replace @code{@value{ROOTDIR}} with
the top-level directory in which @value{PRODUCT} is installed.)  For
example, if you had the the following line in your @code{.login}
file@footnote{The MANPATH variable may be specified in a different
initialization file, depending on your operating system.  Some of the
files in which you might specify environment variables include
@code{.login}, @code{.profile}, or @code{.cshrc}.}:

@smallexample
setenv MANPATH /usr/local/man:/usr/man
@end smallexample

@noindent
and the @value{PRODUCT} man pages were in the directory
@code{/usr/@value{LCPRODUCT}/man}, you would change the line to the following:

@smallexample
setenv MANPATH /usr/@value{LCPRODUCT}/man:/usr/local/man:/usr/man
@end smallexample

@ifinfo
Note to info users:  the manual pages are not available within this info
tree.  You can read them from emacs with the command:

@smallexample
M-x manual-entry @emph{command}
@end smallexample
@end ifinfo

@page

@menu
* kinit Reference::             
* klist Reference::             
* kdestroy Reference::          
* kpasswd Reference::           
* telnet Reference::            
* rlogin Reference::            
* FTP Reference::               
* rsh Reference::               
* rcp Reference::               
* ksu Reference::               
* krdist Reference::            
@end menu

@node kinit Reference, klist Reference, @value{PRODUCT} Reference, @value{PRODUCT} Reference
@section kinit Reference

@iftex
@special{psfile=kinit1.ps voffset=-1115 hoffset=-40}
@centerline{Reference Manual for @code{kinit}}
@page

@special{psfile=kinit2.ps voffset=-1115 hoffset=-40}
@centerline{Reference Manual for @code{kinit}}
@page
@end iftex
@ifinfo
Type @kbd{M-x manual-entry kinit} to read this manual page.
@end ifinfo

@node klist Reference, kdestroy Reference, kinit Reference, @value{PRODUCT} Reference
@section klist Reference

@iftex
@special{psfile=klist1.ps voffset=-1115 hoffset=-40}
@centerline{Reference Manual for @code{klist}}
@page
@end iftex
@ifinfo
Type @kbd{M-x manual-entry klist} to read this manual page.
@end ifinfo

@node kdestroy Reference, kpasswd Reference, klist Reference, @value{PRODUCT} Reference
@section kdestroy Reference

@iftex
@special{psfile=kdestroy1.ps voffset=-1115 hoffset=-60}
@centerline{Reference Manual for @code{kdestroy}}
@page
@end iftex
@ifinfo
Type @kbd{M-x manual-entry kdestroy} to read this manual page.
@end ifinfo

@node kpasswd Reference, telnet Reference, kdestroy Reference, @value{PRODUCT} Reference
@section kpasswd Reference

@iftex
@special{psfile=kpasswd1.ps voffset=-1115 hoffset=-40}
@centerline{Reference Manual for @code{kpasswd}}
@page
@end iftex
@ifinfo
Type @kbd{M-x manual-entry kpasswd} to read this manual page.
@end ifinfo

@node telnet Reference, rlogin Reference, kpasswd Reference, @value{PRODUCT} Reference
@section telnet Reference

@iftex
@special{psfile=telnet1.ps voffset=-1115 hoffset=-40}
@centerline{Reference Manual for @code{telnet}}
@page

@special{psfile=telnet2.ps voffset=-1115 hoffset=-40}
@centerline{Reference Manual for @code{telnet}}
@page

@special{psfile=telnet3.ps voffset=-1115 hoffset=-40}
@centerline{Reference Manual for @code{telnet}}
@page

@special{psfile=telnet4.ps voffset=-1115 hoffset=-40}
@centerline{Reference Manual for @code{telnet}}
@page

@special{psfile=telnet5.ps voffset=-1115 hoffset=-40}
@centerline{Reference Manual for @code{telnet}}
@page

@special{psfile=telnet6.ps voffset=-1115 hoffset=-40}
@centerline{Reference Manual for @code{telnet}}
@page

@special{psfile=telnet7.ps voffset=-1115 hoffset=-40}
@centerline{Reference Manual for @code{telnet}}
@page

@special{psfile=telnet8.ps voffset=-1115 hoffset=-40}
@centerline{Reference Manual for @code{telnet}}
@page

@special{psfile=telnet9.ps voffset=-1115 hoffset=-40}
@centerline{Reference Manual for @code{telnet}}
@page

@special{psfile=telnet10.ps voffset=-1115 hoffset=-40}
@centerline{Reference Manual for @code{telnet}}
@page
@end iftex
@ifinfo
Type @kbd{M-x manual-entry telnet} to read this manual page.
@end ifinfo

@node rlogin Reference, FTP Reference, telnet Reference, @value{PRODUCT} Reference
@section rlogin Reference

@iftex
@special{psfile=rlogin1.ps voffset=-1115 hoffset=-40}
@centerline{Reference Manual for @code{rlogin}}
@page

@special{psfile=rlogin2.ps voffset=-1115 hoffset=-40}
@centerline{Reference Manual for @code{rlogin}}
@page
@end iftex
@ifinfo
Type @kbd{M-x manual-entry rlogin} to read this manual page.
@end ifinfo

@node FTP Reference, rsh Reference, rlogin Reference, @value{PRODUCT} Reference
@section FTP Reference

@iftex
@special{psfile=ftp1.ps voffset=-1115 hoffset=-40}
@centerline{Reference Manual for @code{FTP}}
@page

@special{psfile=ftp2.ps voffset=-1115 hoffset=-40}
@centerline{Reference Manual for @code{FTP}}
@page

@special{psfile=ftp3.ps voffset=-1115 hoffset=-40}
@centerline{Reference Manual for @code{FTP}}
@page

@special{psfile=ftp4.ps voffset=-1115 hoffset=-40}
@centerline{Reference Manual for @code{FTP}}
@page

@special{psfile=ftp5.ps voffset=-1115 hoffset=-40}
@centerline{Reference Manual for @code{FTP}}
@page

@special{psfile=ftp6.ps voffset=-1115 hoffset=-40}
@centerline{Reference Manual for @code{FTP}}
@page

@special{psfile=ftp7.ps voffset=-1115 hoffset=-40}
@centerline{Reference Manual for @code{FTP}}
@page

@special{psfile=ftp8.ps voffset=-1115 hoffset=-40}
@centerline{Reference Manual for @code{FTP}}
@page
@end iftex
@ifinfo
Type @kbd{M-x manual-entry FTP} to read this manual page.
@end ifinfo

@node rsh Reference, rcp Reference, FTP Reference, @value{PRODUCT} Reference
@section rsh Reference

@iftex
@special{psfile=rsh1.ps voffset=-1115 hoffset=-40}
@centerline{Reference Manual for @code{rsh}}
@page

@special{psfile=rsh2.ps voffset=-1115 hoffset=-40}
@centerline{Reference Manual for @code{rsh}}
@page
@end iftex
@ifinfo
Type @kbd{M-x manual-entry rsh} to read this manual page.
@end ifinfo

@node rcp Reference, ksu Reference, rsh Reference, @value{PRODUCT} Reference
@section rcp Reference

@iftex
@special{psfile=rcp1.ps voffset=-1115 hoffset=-40}
@centerline{Reference Manual for @code{rcp}}
@page

@special{psfile=rcp2.ps voffset=-1115 hoffset=-40}
@centerline{Reference Manual for @code{rcp}}
@page
@end iftex
@ifinfo
Type @kbd{M-x manual-entry rcp} to read this manual page.
@end ifinfo

@node ksu Reference, krdist Reference, rcp Reference, @value{PRODUCT} Reference
@section ksu Reference

@iftex
@special{psfile=ksu1.ps voffset=-1115 hoffset=-40}
@centerline{Reference Manual for @code{ksu}}
@page

@special{psfile=ksu2.ps voffset=-1115 hoffset=-40}
@centerline{Reference Manual for @code{ksu}}
@page

@special{psfile=ksu3.ps voffset=-1115 hoffset=-40}
@centerline{Reference Manual for @code{ksu}}
@page

@special{psfile=ksu4.ps voffset=-1115 hoffset=-40}
@centerline{Reference Manual for @code{ksu}}
@page

@special{psfile=ksu5.ps voffset=-1115 hoffset=-40}
@centerline{Reference Manual for @code{ksu}}
@page
@end iftex
@ifinfo
Type @kbd{M-x manual-entry ksu} to read this manual page.
@end ifinfo

@node krdist Reference,  , ksu Reference, @value{PRODUCT} Reference
@section krdist Reference

@iftex
@special{psfile=krdist1.ps voffset=-1115 hoffset=-40}
@centerline{Reference Manual for @code{krdist}}
@page

@special{psfile=krdist2.ps voffset=-1115 hoffset=-40}
@centerline{Reference Manual for @code{krdist}}
@page

@special{psfile=krdist3.ps voffset=-1115 hoffset=-40}
@centerline{Reference Manual for @code{krdist}}
@page

@special{psfile=krdist4.ps voffset=-1115 hoffset=-40}
@centerline{Reference Manual for @code{krdist}}
@page

@special{psfile=krdist5.ps voffset=-1115 hoffset=-40}
@centerline{Reference Manual for @code{krdist}}
@page

@special{psfile=krdist6.ps voffset=-1115 hoffset=-40}
@centerline{Reference Manual for @code{krdist}}
@page

@special{psfile=krdist7.ps voffset=-1115 hoffset=-40}
@centerline{Reference Manual for @code{krdist}}
@page
@end iftex
@ifinfo
Type @kbd{M-x manual-entry krdist} to read this manual page.
@end ifinfo

@node Kerberos Glossary,  , @value{PRODUCT} Reference, Top
@appendix Kerberos Glossary

@include glossary.texinfo

@contents
@bye