This is krb5-user.info, produced by makeinfo version 4.5 from
user-guide.texinfo.

INFO-DIR-SECTION Kerberos
START-INFO-DIR-ENTRY
* krb5-user: (krb5-user).               Kerberos V5 UNIX User's Guide
END-INFO-DIR-ENTRY


File: krb5-user.info,  Node: Granting Access to Your Account,  Prev: Password Advice,  Up: Password Management

Granting Access to Your Account
-------------------------------

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 `.k5login' in your home directory.  This file
should contain the Kerberos principal (*Note 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 `.k5login' file:

     jennifer@ATHENA.MIT.EDU
     david@EXAMPLE.COM

This file would allow the users `jennifer' and `david' 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 `.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,
     e.g., over NFS), that user does not inherit your network
     privileges.

   * 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 machine to the 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.


File: krb5-user.info,  Node: Kerberos V5 Applications,  Prev: Password Management,  Up: Kerberos V5 Tutorial

Kerberos V5 Applications
========================

Kerberos V5 is a "single-sign-on" system.  This means that you only
have to type your password once, and the Kerberos V5 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 Kerberos V5 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 Kerberos V5 applications are versions of existing UNIX network
programs with the Kerberos features added.

* Menu:

* Overview of Additional Features::
* telnet::
* rlogin::
* FTP::
* rsh::
* rcp::
* ksu::


File: krb5-user.info,  Node: Overview of Additional Features,  Next: telnet,  Prev: Kerberos V5 Applications,  Up: Kerberos V5 Applications

Overview of Additional Features
-------------------------------

The Kerberos V5 "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 non-Kerberos
`rlogin', `telnet', `ftp', `rsh', `rcp', and `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 Kerberos V5 network programs allow you the options of forwarding
your tickets to the remote host (if you obtained forwardable tickets
with the `kinit' program; *note 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 Kerberos V5 package.


File: krb5-user.info,  Node: telnet,  Next: rlogin,  Prev: Overview of Additional Features,  Up: Kerberos V5 Applications

telnet
------

The Kerberos V5 `telnet' command works exactly like the standard UNIX
telnet program, with the following Kerberos options added:

`-f'
     forwards a copy of your tickets to the remote host.

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

`-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'
     attempt automatic login using your tickets.  `telnet' will assume
     the same username unless you explicitly specify another.

`-x'
     turns on encryption.


For example, if `david' wanted to use the standard UNIX telnet to
connect to the machine `daffodil.mit.edu', he would type:

     shell% telnet daffodil.example.com
     Trying 128.0.0.5 ...
     Connected to daffodil.example.com.
     Escape character is '^]'.
     
     NetBSD/i386 (daffodil) (ttyp3)
     
     login: david
     Password:    <- david types his password here
     Last login: Fri Jun 21 17:13:11 from trillium.mit.edu
     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%

Note that the machine `daffodil.example.com' asked for `david''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 `david''s password.

If, on the other hand, `jennifer' wanted to use the Kerberos V5 telnet
to connect to the machine `trillium.mit.edu', she could forward a copy
of her tickets, request an encrypted session, and log on as herself as
follows:

     shell% telnet -a -f -x trillium.mit.edu
     Trying 128.0.0.5...
     Connected to trillium.mit.edu.
     Escape character is '^]'.
     [ Kerberos V5 accepts you as "jennifer@mit.edu" ]
     [ Kerberos V5 accepted forwarded credentials ]
     What you type is protected by encryption.
     Last login: Tue Jul 30 18:47:44 from daffodil.example.com
     Athena Server (sun4) Version 9.1.11 Tue Jul 30 14:40:08 EDT 2002
     
     shell%

Note that `jennifer''s machine used Kerberos to authenticate her to
`trillium.mit.edu', 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, `telnet' automatically destroys
them when it exits.  The full set of options to Kerberos V5 `telnet'
are discussed in the Reference section of this manual.  (*note telnet
Reference::)


File: krb5-user.info,  Node: rlogin,  Next: FTP,  Prev: telnet,  Up: Kerberos V5 Applications

rlogin
------

The Kerberos V5 `rlogin' command works exactly like the standard UNIX
rlogin program, with the following Kerberos options added:

`-f'
     forwards a copy of your tickets to the remote host.

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

`-k realm'
     requests tickets for the remote host in the specified realm,
     instead of determining the realm itself.

`-x'
     encrypts the input and output data streams (the username is sent
     unencrypted)


For example, if `david' wanted to use the standard UNIX rlogin to
connect to the machine `daffodil.example.com', he would type:

     shell% rlogin daffodil.example.com -l david
     Password:  <- david 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!
     shell%

Note that the machine `daffodil.example.com' asked for `david''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 `david''s password.

If, on the other hand, `jennifer' wanted to use Kerberos V5 rlogin to
connect to the machine `trillium.mit.edu', she could forward a copy of
her tickets, mark them as not forwardable from the remote host, and
request an encrypted session as follows:

     shell% rlogin trillium.mit.edu -f -x
     This rlogin session is using DES encryption for all data transmissions.
     Last login: Thu Jun 20 16:20:50 from daffodil
     Athena Server (sun4) Version 9.1.11 Tue Jul 30 14:40:08 EDT 2002
     shell%

Note that `jennifer''s machine used Kerberos to authenticate her to
`trillium.mit.edu', 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, `rlogin' automatically destroys
them when it exits.  The full set of options to Kerberos V5 `rlogin'
are discussed in the Reference section of this manual.  (*note rlogin
Reference::)


File: krb5-user.info,  Node: FTP,  Next: rsh,  Prev: rlogin,  Up: Kerberos V5 Applications

FTP
---

The Kerberos V5 `FTP' program works exactly like the standard UNIX FTP
program, with the following Kerberos features added:

`-k realm'
     requests tickets for the remote host in the specified realm,
     instead of determining the realm itself.

`-f'
     requests that your tickets be forwarded to the remote host.  The
     `-f' 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 `daffodil.mit.edu'.  She wants
to encrypt the file transfer.  The exchange would look like the
following:

     shell% ftp daffodil.mit.edu
     Connected to daffodil.mit.edu.
     220 daffodil.mit.edu FTP server (Version 5.60) ready.
     334 Using authentication type GSSAPI; ADAT must follow
     GSSAPI accepted as authentication type
     GSSAPI authentication succeeded
     200 Data channel protection level set to private.
     Name (daffodil.mit.edu:jennifer):
     232 GSSAPI user jennifer@ATHENA.MIT.EDU 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
     shell%

The full set of options to Kerberos V5 `FTP' are discussed in the
Reference section of this manual.  (*note FTP Reference::)


File: krb5-user.info,  Node: rsh,  Next: rcp,  Prev: FTP,  Up: Kerberos V5 Applications

rsh
---

The Kerberos V5 `rsh' program works exactly like the standard UNIX
rlogin program, with the following Kerberos features added:

`-f'
     forwards a copy of your tickets to the remote host.

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

`-k realm'
     requests tickets for the remote host in the specified realm,
     instead of determining the realm itself.

`-x'
     encrypts the input and output data streams (the command line is
     not encrypted)


For example, if your Kerberos tickets allowed you to run programs on the
host
`trillium@example.com' as root, you could run the `date' program as
follows:

     shell% rsh trillium.example.com -l root -x date
     This rsh session is using DES encryption for all data transmissions.
     Tue Jul 30 19:34:21 EDT 2002
     shell%

If you forwarded your Kerberos tickets, `rsh' automatically destroys
them when it exits.  The full set of options to Kerberos V5 `rsh' are
discussed in the Reference section of this manual.  (*note rsh
Reference::)


File: krb5-user.info,  Node: rcp,  Next: ksu,  Prev: rsh,  Up: Kerberos V5 Applications

rcp
---

The Kerberos V5 `rcp' program works exactly like the standard UNIX rcp
program, with the following Kerberos features added:

`-k realm'
     requests tickets for the remote host in the specified realm,
     instead of determining the realm itself.

`-x'
     turns on encryption.

For example, if you wanted to copy the file `/etc/motd' from the host
`daffodil.mit.edu' into the current directory, via an encrypted
connection, you would simply type:

     shell% rcp -x daffodil.mit.edu:/etc/motd .

The `rcp' program negotiates authentication and encryption
transparently.  The full set of options to Kerberos V5 `rcp' are
discussed in the Reference section of this manual.  (*note rcp
Reference::)


File: krb5-user.info,  Node: ksu,  Prev: rcp,  Up: Kerberos V5 Applications

ksu
---

The Kerberos V5 `ksu' program replaces the standard UNIX su program.
`ksu' first authenticates you to Kerberos.  Depending on the
configuration of your system, `ksu' may ask for your 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 Kerberos principal appears in
the target's `.k5login' file (*note Granting Access to Your Account::)
or in the target's `.k5users' file (see below), it switches your user
ID to the target user ID.

For example, `david' has put `jennifer''s Kerberos principal in his
`.k5login' file.  If `jennifer' uses `ksu' to become `david', the
exchange would look like this.  (To differentiate between the two
shells, `jennifer''s prompt is represented as `jennifer%' and
`david''s prompt is represented as `david%'.)

     jennifer% ksu david
     Account david: authorization for jennifer@ATHENA.MIT.EDU successful
     Changing uid to david (3382)
     david%

Note that the new shell has a copy of `jennifer''s tickets.  The ticket
filename contains `david''s UID with `.1' appended to it:

     david% klist
     Ticket cache: /tmp/krb5cc_3382.1
     Default principal: jennifer@ATHENA.MIT.EDU
     
     Valid starting      Expires             Service principal
     07/31/04 21:53:01  08/01/04 07:52:53  krbtgt/ATHENA.MIT.EDU@ATHENA.MIT.EDU
     07/31/04 21:53:39  08/01/04 07:52:53  host/daffodil.mit.edu@ATHENA.MIT.EDU
     david%

If `jennifer' had not appeared in `david''s `.k5login' file (and the
system was configured to ask for a password), the exchange would have
looked like this (assuming `david' has taken appropriate precautions in
protecting his password):

     jennifer% ksu david
     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 david@ATHENA.MIT.EDU:  <-  `jennifer' types the wrong password here.
     ksu: Password incorrect
     Authentication failed.
     jennifer%

Now, suppose `david' did not want to give `jennifer' 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 `.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.  `ksu' will let
those principals execute only the commands listed, using the `-e'
option.  `david''s `.k5users' file might look like the following:

     jennifer@ATHENA.MIT.EDU       /bin/ls /usr/bin/more
     joeadmin@ATHENA.MIT.EDU         /bin/ls
     joeadmin/admin@ATHENA.MIT.EDU   *
     david@EXAMPLE.COM

The above `.k5users' file would let `jennifer' run only the commands
`/bin/ls' and `/usr/bin/more'.  It would let `joeadmin' run only the
command `/bin/ls' if he had regular tickets, but if he had tickets for
his `admin' instance, `joeadmin/admin@ATHENA.MIT.EDU', he would be able
to execute any command.  The last line gives `david' in the realm
EXAMPLE.COM permission to execute any command.  (I.e., having only a
Kerberos principal on a line is equivalent to giving that principal
permission to execute `*'.)  This is so that david can allow himself to
execute commands when he logs in, using Kerberos, from a machine in the
realm EXAMPLE.COM.

Then, when `jennifer' wanted to list his home directory, she would type:

     jennifer% ksu david -e ls ~david
     Authenticated jennifer@ATHENA.MIT.EDU
     Account david: authorization for jennifer@ATHENA.MIT.EDU for execution of
                    /bin/ls successful
     Changing uid to david (3382)
     Mail            News            Personal        misc            bin
     jennifer%

If `jennifer' had tried to give a different command to `ksu', it would
have prompted 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 Kerberos principal you want to use for `ksu'.
     (e.g., the user `joeadmin' might want to use his `admin' instance.
     *Note What is a Ticket?::.)

`-c'
     specifies the location of your Kerberos credentials cache (ticket
     file).

`-k'
     tells `ksu' not to destroy your Kerberos tickets when `ksu' is
     finished.

`-f'
     requests forwardable tickets.  (*Note Obtaining Tickets with
     kinit::.)  This is only applicable if `ksu' needs to obtain
     tickets.

`-l lifetime'
     sets the ticket lifetime.  (*Note Obtaining Tickets with kinit::.)
     This is only applicable if `ksu' needs to obtain tickets.

`-z'
     tells `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 `-n' option).

`-Z'
     tells `ksu' not to copy any 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 Kerberos V5 `ksu' are discussed in the
Reference section of this manual.  (*note ksu Reference::)


File: krb5-user.info,  Node: Kerberos V5 Reference,  Next: Kerberos Glossary,  Prev: Kerberos V5 Tutorial,  Up: Top

Kerberos V5 Reference
*********************

This section will include copies of the manual pages for the Kerberos
V5 client programs.  You can read the manual entry for any command by
typing `man' command, where command is the name of the command for
which you want to read the manual entry.  For example, to read the
`kinit' manual entry, you would type:

     shell% man kinit

Note:  To be able to view the Kerberos V5 manual pages on line, you may
need to add the directory `/usr/local/man' to your MANPATH environment
variable.  (Remember to replace `/usr/local' with the top-level
directory in which Kerberos V5 is installed.)  For example, if you had
the the following line in your `.login' file(1):

     setenv MANPATH /usr/local/man:/usr/man

and the Kerberos V5 man pages were in the directory `/usr/krb5/man',
you would change the line to the following:

     setenv MANPATH /usr/krb5/man:/usr/local/man:/usr/man

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

     M-x manual-entry _command_

* Menu:

* kinit Reference::
* klist Reference::
* ksu Reference::
* kdestroy Reference::
* kpasswd Reference::
* telnet Reference::
* FTP Reference::
* rlogin Reference::
* rsh Reference::
* rcp Reference::

---------- Footnotes ----------

(1) 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 `.login', `.profile',
or `.cshrc'.


File: krb5-user.info,  Node: kinit Reference,  Next: klist Reference,  Prev: Kerberos V5 Reference,  Up: Kerberos V5 Reference

kinit Reference
===============

Type `M-x manual-entry kinit' to read this manual page.


File: krb5-user.info,  Node: klist Reference,  Next: ksu Reference,  Prev: kinit Reference,  Up: Kerberos V5 Reference

klist Reference
===============

Type `M-x manual-entry klist' to read this manual page.


File: krb5-user.info,  Node: ksu Reference,  Next: kdestroy Reference,  Prev: klist Reference,  Up: Kerberos V5 Reference

ksu Reference
=============

Type `M-x manual-entry ksu' to read this manual page.


File: krb5-user.info,  Node: kdestroy Reference,  Next: kpasswd Reference,  Prev: ksu Reference,  Up: Kerberos V5 Reference

kdestroy Reference
==================

Type `M-x manual-entry kdestroy' to read this manual page.


File: krb5-user.info,  Node: kpasswd Reference,  Next: telnet Reference,  Prev: kdestroy Reference,  Up: Kerberos V5 Reference

kpasswd Reference
=================

Type `M-x manual-entry kpasswd' to read this manual page.


File: krb5-user.info,  Node: telnet Reference,  Next: FTP Reference,  Prev: kpasswd Reference,  Up: Kerberos V5 Reference

telnet Reference
================

Type `M-x manual-entry telnet' to read this manual page.


File: krb5-user.info,  Node: FTP Reference,  Next: rlogin Reference,  Prev: telnet Reference,  Up: Kerberos V5 Reference

FTP Reference
=============

Type `M-x manual-entry FTP' to read this manual page.


File: krb5-user.info,  Node: rlogin Reference,  Next: rsh Reference,  Prev: FTP Reference,  Up: Kerberos V5 Reference

rlogin Reference
================

Type `M-x manual-entry rlogin' to read this manual page.


File: krb5-user.info,  Node: rsh Reference,  Next: rcp Reference,  Prev: rlogin Reference,  Up: Kerberos V5 Reference

rsh Reference
=============

Type `M-x manual-entry rsh' to read this manual page.


File: krb5-user.info,  Node: rcp Reference,  Prev: rsh Reference,  Up: Kerberos V5 Reference

rcp Reference
=============

Type `M-x manual-entry rcp' to read this manual page.


File: krb5-user.info,  Node: Kerberos Glossary,  Prev: Kerberos V5 Reference,  Up: Top

Kerberos Glossary
*****************

client
     an entity that can obtain a ticket.  This entity is usually either
     a user or a host.

host
     a computer that can be accessed over a network.

Kerberos
     in Greek mythology, the three-headed dog that guards the entrance
     to the underworld.  In the computing world, Kerberos is a network
     security package that was developed at MIT.

KDC
     Key Distribution Center.  A machine that issues Kerberos tickets.

keytab
     a key table file containing one or more keys.  A host or service
     uses a "keytab" file in much the same way as a user uses his/her
     password.

principal
     a string that names a specific entity to which a set of
     credentials may be assigned.  It can have an arbitrary number of
     components, but generally has three:

    primary
          the first part of a Kerberos principal.  In the case of a
          user, it is the username.  In the case of a service, it is
          the name of the service.

    instance
          the second part of a Kerberos principal.  It gives
          information that qualifies the primary.  The instance may be
          null.  In the case of a user, the instance is often used to
          describe the intended use of the corresponding credentials.
          In the case of a host, the instance is the fully qualified
          hostname.

    realm
          the logical network served by a single Kerberos database and
          a set of Key Distribution Centers.  By convention, realm
          names are generally all uppercase letters, to differentiate
          the realm from the internet domain.

     The typical format of a typical Kerberos principal is
     primary/instance@REALM.

service
     any program or computer you access over a network.  Examples of
     services include "host" (a host, e.g., when you use `telnet' and
     `rsh'), "ftp" (FTP), "krbtgt" (authentication; cf. ticket-granting
     ticket), and "pop" (email).

ticket
     a temporary set of electronic credentials that verify the identity
     of a client for a particular service.

TGT
     Ticket-Granting Ticket.  A special Kerberos ticket that permits the
     client to obtain additional Kerberos tickets within the same
     Kerberos realm.


