krb5 commit: Remove unused texinfo sources
Benjamin Kaduk
kaduk at MIT.EDU
Mon Oct 15 17:20:06 EDT 2012
https://github.com/krb5/krb5/commit/612d64fa15ec1efe1bdd0001b62ff1eabab64da5
commit 612d64fa15ec1efe1bdd0001b62ff1eabab64da5
Author: Ben Kaduk <kaduk at mit.edu>
Date: Fri Oct 12 12:05:30 2012 -0400
Remove unused texinfo sources
Now that the users guide make rules are removed, some of the texinfo
sources are not referenced from anywhere and can be safely removed.
ticket: 7408
doc/glossary.texinfo | 64 --
doc/user-guide.texinfo | 1711 ------------------------------------------------
2 files changed, 0 insertions(+), 1775 deletions(-)
diff --git a/doc/glossary.texinfo b/doc/glossary.texinfo
deleted file mode 100644
index d49a56a..0000000
--- a/doc/glossary.texinfo
+++ /dev/null
@@ -1,64 +0,0 @@
- at table @b
- at item client
-an entity that can obtain a ticket. This entity is usually either a
-user or a host.
-
- at item host
-a computer that can be accessed over a network.
-
- at item 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.
-
- at item KDC
-Key Distribution Center. A machine that issues Kerberos tickets.
-
- at item keytab
-a @b{key tab}le file containing one or more keys. A host or service
-uses a @dfn{keytab} file in much the same way as a user uses his/her
-password.
-
- at item 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:
-
- at table @b
- at item primary
-the first part of a Kerberos @i{principal}. In the case of a user, it
-is the username. In the case of a service, it is the name of the
-service.
-
- at item instance
-the second part of a Kerberos @i{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.
-
- at item 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.
- at end table
-
- at noindent
-The typical format of a typical Kerberos principal is
-primary/instance@@REALM.
-
- at item service
-any program or computer you access over a network. Examples of services
-include ``host'' (a host, @i{e.g.}, when you use @code{telnet} and
- at code{rsh}), ``ftp'' (FTP), ``krbtgt'' (authentication;
-cf. @i{ticket-granting ticket}), and ``pop'' (email).
-
- at item ticket
-a temporary set of electronic credentials that verify the identity of a
-client for a particular service.
-
- at item TGT
-Ticket-Granting Ticket. A special Kerberos ticket that permits the
-client to obtain additional Kerberos tickets within the same Kerberos
-realm.
- at end table
diff --git a/doc/user-guide.texinfo b/doc/user-guide.texinfo
deleted file mode 100644
index 0dafe87..0000000
--- a/doc/user-guide.texinfo
+++ /dev/null
@@ -1,1711 +0,0 @@
-\input texinfo @c -*-texinfo-*-
- at c %**start of header
- at c guide
- at setfilename krb5-user.info
- at settitle Kerberos V5 UNIX User's Guide
- at setchapternewpage odd @c chapter begins on next odd page
- at c @setchapternewpage on @c chapter begins on next page
- at c @smallbook @c Format for 7" X 9.25" paper
- at documentencoding UTF-8
- at c %**end of header
- at copying
-Copyright @copyright{} 1985-2010 by the Massachusetts Institute of Technology.
- at end copying
-
- at paragraphindent 0
- at iftex
- at parskip 6pt plus 6pt
- at end iftex
-
- at dircategory Kerberos
- at direntry
-* krb5-user: (krb5-user). Kerberos V5 UNIX User's Guide
- at end direntry
-
- at include definitions.texinfo
- at set EDITION 1.0
-
- at finalout @c don't print black warning boxes
-
- at titlepage
- at title @value{PRODUCT} UNIX User's Guide
- at subtitle Release: @value{RELEASE}
- at subtitle Document Edition: @value{EDITION}
- at subtitle Last updated: @value{UPDATED}
- at author @value{COMPANY}
-
- at page
- at vskip 0pt plus 1filll
- at insertcopying
- at end titlepage
-
- at comment node-name, next, previous, up
- at node Top, Introduction, (dir), (dir)
-
- at ifinfo
-This file describes how to use the @value{PRODUCT} client programs.
-
- at insertcopying
- at end ifinfo
-
- at c The master menu is updated using emacs19's M-x texinfo-all-menus-update
- at c function. Don't forget to run M-x texinfo-every-node-update after
- at c you add a new section or subsection, or after you've rearranged the
- at c comand before each @section or @subsection! All you need to enter
- at c is:
- at c
- at c @section New Section Name
- at c
- at c M-x texinfo-every-node-update will take care of calculating the
- at c node's forward and back pointers.
- at c
- at c ---------------------------------------------------------------------
-
- at menu
-* Introduction::
-* Kerberos V5 Tutorial::
-* Kerberos V5 Reference::
-* Kerberos Glossary::
-* Copyright::
- at end menu
-
- at node Introduction, Kerberos V5 Tutorial, Top, Top
- at chapter Introduction
-
- at ifset CYGNUS
- at value{PRODUCT} is based on the Kerberos V5 authentication system
-developed at MIT.
- at end ifset
- at ifset MIT
-Kerberos V5 is an authentication system developed at MIT.
- at end ifset
-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,
- at value{COMPANY}'s @value{PRODUCT} plays a vital role in maintaining your
-network security.
-
-The @value{PRODUCT} package is designed to be easy to use. Most of the
-commands are nearly identical to UNIX network programs you already
-use. @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.
-
- at menu
-* What is a Ticket?::
-* What is a Kerberos Principal?::
- at end menu
-
- at node What is a Ticket?, What is a Kerberos Principal?, Introduction, Introduction
- at 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.
-
- at node What is a Kerberos Principal?, , What is a Ticket?, Introduction
- at section What is a Kerberos Principal?
-
-A Kerberos @dfn{principal} is a unique identity to which Kerberos can
-assign tickets. Principals can have an arbitrary number of
-components. Each component is separated by a component separator,
-generally `/'. The last component is the realm, separated from the
-rest of the principal by the realm separator, generally `@@'. If there
-is no realm component in the principal, then it will be assumed that
-the principal is in the default realm for the context in which it is
-being used.
-
-Traditionally, a principal is divided into three parts: the
- at dfn{primary}, the @dfn{instance}, and the @dfn{realm}. The format of
-a typical Kerberos V5 principal is @code{primary/instance@@REALM}.
-
- at itemize @bullet
- at 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}.
-
- at 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
- at samp{admin}, which he/she uses to administrate a database. The
-principal @code{@value{RANDOMUSER1}@@@value{PRIMARYREALM}} is completely
-separate from the principal
- at 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.,
- at code{@value{RANDOMHOST1}. at value{PRIMARYDOMAIN}}.
-
- at 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}. at value{SECONDDOMAIN}} would be in
-the realm @code{@value{SECONDREALM}}.
- at end itemize
-
- at node Kerberos V5 Tutorial, Kerberos V5 Reference, Introduction, Top
- at chapter Kerberos V5 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:
-
- at need 600
- at smallexample
- at group
- at b{shell%} ls
- at end group
- at end smallexample
-
-In these examples, we will use sample usernames, such as
- at code{@value{RANDOMUSER1}} and @code{@value{RANDOMUSER2}}, sample
-hostnames, such as @code{@value{RANDOMHOST1}} and
- at code{@value{RANDOMHOST2}}, and sample domain names, such as
- at code{@value{PRIMARYDOMAIN}} and @code{@value{SECONDDOMAIN}}. When you
-see one of these, substitute your username, hostname, or domain name
-accordingly.
-
- at menu
-* Setting Up to Use Kerberos V5::
-* Ticket Management::
-* Password Management::
-* Kerberos V5 Applications::
- at end menu
-
- at node Setting Up to Use Kerberos V5, Ticket Management, Kerberos V5 Tutorial, Kerberos V5 Tutorial
- at 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
- at 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
- at value{PRODUCT} network programs, rather than the standard UNIX
-versions, when you type their command names.
-
- at node Ticket Management, Password Management, Setting Up to Use Kerberos V5, Kerberos V5 Tutorial
- at 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
- at 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,
- at 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.
-
- at need 2000
- at menu
-* Kerberos Ticket Properties::
-* Obtaining Tickets with kinit::
-* Viewing Your Tickets with klist::
-* Destroying Your Tickets with kdestroy::
- at end menu
-
- at node Kerberos Ticket Properties, Obtaining Tickets with kinit, Ticket Management, Ticket Management
- at subsection Kerberos Ticket Properties
-
- at noindent
-There are various properties that Kerberos tickets can have:
-
-If a ticket is @dfn{forwardable}, then the KDC can issue a new ticket with
-a different network address based on the forwardable ticket. This
-allows for authentication forwarding without requiring a password to be
-typed in again. For example, if a user with a forwardable TGT logs
-into a remote system, the KDC could issue a new TGT for that user with
-the network address of the remote system, allowing authentication on
-that host to work as though the user were logged in locally.
-
-When the KDC creates a new ticket based on a forwardable ticket, it
-sets the @dfn{forwarded} flag on that new ticket. Any tickets that are
-created based on a ticket with the forwarded flag set will also have
-their forwarded flags set.
-
-A @dfn{proxiable} ticket is similar to a forwardable ticket in that it
-allows a service to take on the identity of the client. Unlike a
-forwardable ticket, however, a proxiable ticket is only issued for
-specific services. In other words, a ticket-granting ticket cannot be
-issued based on a ticket that is proxiable but not forwardable.
-
-A @dfn{proxy} ticket is one that was issued based on a proxiable ticket.
-
-A @dfn{postdated} ticket is issued with the @i{invalid} flag set.
-After the starting time listed on the ticket, it can be presented to
-the KDC to obtain valid tickets.
-
-Tickets with the @dfn{postdateable} flag set can be used to issue postdated
-tickets.
-
- at dfn{Renewable} tickets can be used to obtain new session keys without
-the user entering their password again. A renewable ticket has two
-expiration times. The first is the time at which this particular
-ticket expires. The second is the latest possible expiration time for
-any ticket issued based on this renewable ticket.
-
-A ticket with the @dfn{initial} flag set was issued based on the
-authentication protocol, and not on a ticket-granting ticket. Clients
-that wish to ensure that the user's key has been recently presented for
-verification could specify that this flag must be set to accept the
-ticket.
-
-An @dfn{invalid} ticket must be rejected by application servers. Postdated
-tickets are usually issued with this flag set, and must be validated by
-the KDC before they can be used.
-
-A @dfn{preauthenticated} ticket is one that was only issued after the
-client requesting the ticket had authenticated itself to the KDC.
-
-The @dfn{hardware authentication} flag is set on a ticket which
-required the use of hardware for authentication. The hardware is
-expected to be possessed only by the client which requested the
-tickets.
-
-If a ticket has the @dfn{transit policy checked} flag set, then the KDC that
-issued this ticket implements the transited-realm check policy and
-checked the transited-realms list on the ticket. The transited-realms
-list contains a list of all intermediate realms between the realm of the
-KDC that issued the first ticket and that of the one that issued the
-current ticket. If this flag is not set, then the application server
-must check the transited realms itself or else reject the ticket.
-
-The @dfn{okay as delegate} flag indicates that the server specified in
-the ticket is suitable as a delegate as determined by the policy of
-that realm. A server that is acting as a delegate has been granted a
-proxy or a forwarded TGT. This flag is a new addition to the
- at value{PRODUCT} protocol and is not yet implemented on MIT servers.
-
-An @dfn{anonymous} ticket is one in which the named principal is a generic
-principal for that realm; it does not actually specify the individual
-that will be using the ticket. This ticket is meant only to securely
-distribute a session key. This is a new addition to the @value{PRODUCT}
-protocol and is not yet implemented on MIT servers.
-
- at node Obtaining Tickets with kinit, Viewing Your Tickets with klist, Kerberos Ticket Properties, Ticket Management
- at 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.
-
- at 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
- at code{@value{RANDOMUSER1}}) works for Bleep, Inc. (a fictitious company
-with the domain name @code{@value{PRIMARYDOMAIN}} and the Kerberos realm
- at code{@value{PRIMARYREALM}}). She would type:
-
- at smallexample
- at group
- at b{shell%} kinit
- at b{Password for @value{RANDOMUSER1}@@@value{PRIMARYREALM}:} @i{<-- [Type @value{RANDOMUSER1}'s password here.]}
- at b{shell%}
- at end group
- at end smallexample
-
- at need 1000
-If you type your password incorrectly, kinit will give you the following
-error message:
-
- at smallexample
- at group
- at b{shell%} kinit
- at b{Password for @value{RANDOMUSER1}@@@value{PRIMARYREALM}:} @i{<-- [Type the wrong password here.]}
- at b{kinit: Password incorrect}
- at b{shell%}
- at end group
- at end smallexample
-
- at noindent and you won't get Kerberos tickets.
-
- at noindent Notice that @code{kinit} assumes you want tickets for your own
-username in your default realm.
- at 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}. at footnote{Note: the realm
- at value{SECONDREALM} must be listed in your computer's Kerberos
-configuration file, @code{/etc/krb5.conf}.} He would type:
-
- at smallexample
- at group
- at b{shell%} kinit @value{RANDOMUSER2}@@@value{SECONDREALM}
- at b{Password for @value{RANDOMUSER2}@@@value{SECONDREALM}:} @i{<-- [Type @value{RANDOMUSER2}'s password here.]}
- at b{shell%}
- at end group
- at end smallexample
-
- at 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.
-
- at 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
- at kbd{-f} option:
-
- at smallexample
- at group
- at b{shell%} kinit -f
- at b{Password for @value{RANDOMUSER1}@@@value{PRIMARYREALM}:} @i{<-- [Type your password here.]}
- at b{shell%}
- at end group
- at end smallexample
-
- at 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
- at samp{s} to the value for seconds, @samp{m} for minutes, @samp{h} for
-hours, or @samp{d} for days.
- at need 1500
-For example, to obtain forwardable tickets for
- at code{@value{RANDOMUSER2}@@@value{SECONDREALM}} that would be good for
-three hours, you would type:
-
- at smallexample
- at group
- at b{shell%} kinit -f -l 3h @value{RANDOMUSER2}@@@value{SECONDREALM}
- at b{Password for @value{RANDOMUSER2}@@@value{SECONDREALM}:} @i{<-- [Type @value{RANDOMUSER2}'s password here.]}
- at b{shell%}
- at end group
- at end smallexample
-
- at 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.
-
- at node Viewing Your Tickets with klist, Destroying Your Tickets with kdestroy, Obtaining Tickets with kinit, Ticket Management
- at 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:
-
- at smallexample
- at group
- at b{shell%} klist
-Ticket cache: /tmp/krb5cc_ttypa
-Default principal: @value{RANDOMUSER1}@@@value{PRIMARYREALM}
-
-Valid starting Expires Service principal
-06/07/04 19:49:21 06/08/04 05:49:19 krbtgt/@value{PRIMARYREALM}@@@value{PRIMARYREALM}
- at b{shell%}
- at end group
- at end smallexample
-
- at 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
- at code{krbtgt}, and the instance is the realm name.
-
- at need 2000
-Now, if @value{RANDOMUSER1} connected to the machine
- at code{@value{RANDOMHOST1}. at value{PRIMARYDOMAIN}}, and then typed
- at kbd{klist} again, she would have gotten the following result:
-
- at smallexample
- at group
- at b{shell%} klist
-Ticket cache: /tmp/krb5cc_ttypa
-Default principal: @value{RANDOMUSER1}@@@value{PRIMARYREALM}
-
-Valid starting Expires Service principal
-06/07/04 19:49:21 06/08/04 05:49:19 krbtgt/@value{PRIMARYREALM}@@@value{PRIMARYREALM}
-06/07/04 20:22:30 06/08/04 05:49:19 host/@value{RANDOMHOST1}. at value{PRIMARYDOMAIN}@@@value{PRIMARYREALM}
- at b{shell%}
- at end group
- at end smallexample
-
- at noindent
-Here's what happened: when @value{RANDOMUSER1} used telnet to connect
-to the host @code{@value{RANDOMHOST1}. at value{PRIMARYDOMAIN}}, the telnet
-program presented her ticket-granting ticket to the KDC and requested a
-host ticket for the host
- at code{@value{RANDOMHOST1}. at value{PRIMARYDOMAIN}}. The KDC sent the host
-ticket, which telnet then presented to the host
- at code{@value{RANDOMHOST1}. at value{PRIMARYDOMAIN}}, and she was allowed to
-log in without typing her password.
-
- at need 3000
-Suppose your Kerberos tickets allow you to log into a host in another
-domain, such as @code{@value{RANDOMHOST2}. at 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
- at code{@value{RANDOMHOST2}. at value{SECONDDOMAIN}}. @kbd{klist} will now
-show:
-
- at smallexample
- at group
- at b{shell%} klist
-Ticket cache: /tmp/krb5cc_ttypa
-Default principal: @value{RANDOMUSER1}@@@value{PRIMARYREALM}
-
-Valid starting Expires Service principal
-06/07/04 19:49:21 06/08/04 05:49:19 krbtgt/@value{PRIMARYREALM}@@@value{PRIMARYREALM}
-06/07/04 20:22:30 06/08/04 05:49:19 host/@value{RANDOMHOST1}. at value{PRIMARYDOMAIN}@@@value{PRIMARYREALM}
-06/07/04 20:24:18 06/08/04 05:49:19 krbtgt/@value{SECONDREALM}@@@value{PRIMARYREALM}
-06/07/04 20:24:18 06/08/04 05:49:19 host/@value{RANDOMHOST2}. at value{SECONDDOMAIN}@@@value{SECONDREALM}
- at b{shell%}
- at end group
- at end smallexample
-
-You can use the @code{-f} option to view the @dfn{flags} that apply to
-your tickets. The flags are:
-
- at table @b
- at itemx F
- at b{F}orwardable
- at itemx f
- at b{f}orwarded
- at itemx P
- at b{P}roxiable
- at itemx p
- at b{p}roxy
- at itemx D
-post at b{D}ateable
- at itemx d
-post at b{d}ated
- at itemx R
- at b{R}enewable
- at itemx I
- at b{I}nitial
- at itemx i
- at b{i}nvalid
- at itemx H
- at b{H}ardware authenticated
- at itemx A
-pre at b{A}uthenticated
- at itemx T
- at b{T}ransit policy checked
- at itemx O
- at b{O}kay as delegate
- at itemx a
- at b{a}nonymous
- at end table
-
- at 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.)
-
- at smallexample
- at group
- at b{shell%} klist -f
- at b{Ticket cache: /tmp/krb5cc_320
-Default principal: @value{RANDOMUSER1}@@@value{PRIMARYREALM}
-
-Valid starting Expires Service principal
-31/07/05 19:06:25 31/07/05 19:16:25 krbtgt/@value{PRIMARYREALM}@@@value{PRIMARYREALM}
- Flags: FdiI
-shell%}
- at end group
- at end smallexample
-
- at 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}).
-
- at smallexample
- at group
- at b{shell%} klist -f
- at b{Ticket cache: /tmp/krb5cc_p11795
-Default principal: @value{RANDOMUSER2}@@@value{SECONDREALM}
-
-Valid starting Expires Service principal
-07/31/05 11:52:29 07/31/05 21:11:23 krbtgt/@value{SECONDREALM}@@@value{SECONDREALM}
- Flags: Ff
-07/31/05 12:03:48 07/31/05 21:11:23 host/@value{RANDOMHOST2}. at value{SECONDDOMAIN}@@@value{SECONDREALM}
- Flags: Ff
-shell%}
- at end group
- at end smallexample
-
- at node Destroying Your Tickets with kdestroy, , Viewing Your Tickets with klist, Ticket Management
- at 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.
-
- at need 1000
-Destroying your tickets is easy. Simply type @kbd{kdestroy}.
-
- at smallexample
- at group
- at b{shell%} kdestroy
- at b{shell%}
- at end group
- at end smallexample
-
- at 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:
-
- at smallexample
- at group
- at b{shell%} kdestroy
- at b{kdestroy: No credentials cache file found while destroying cache
-shell%}
- at end group
- at end smallexample
-
- at node Password Management, Kerberos V5 Applications, Ticket Management, Kerberos V5 Tutorial
- at 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
- at 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.
-
- at menu
-* Changing Your Password::
-* Password Advice::
-* Granting Access to Your Account::
- at end menu
-
- at node Changing Your Password, Password Advice, Password Management, Password Management
- at subsection Changing Your Password
-
- at 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:
-
- at smallexample
- at group
- at b{shell%} kpasswd
- at b{Password for @value{RANDOMUSER2}:} @i{<- Type your old password.}
- at b{Enter new password:} @i{<- Type your new password.}
- at b{Enter it again:} @i{<- Type the new password again.}
- at b{Password changed.}
- at b{shell%}
- at end group
- at end smallexample
-
- at need 1800
-If @value{RANDOMUSER2} typed the incorrect old password, he would get
-the following message:
-
- at smallexample
- at group
- at b{shell%} kpasswd
- at b{Password for @value{RANDOMUSER2}:} @i{<- Type the incorrect old password.}
- at b{kpasswd: Password incorrect while getting initial ticket
-shell%}
- at end group
- at end smallexample
-
- at 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:
-
- at smallexample
- at group
- at b{shell%} kpasswd
- at b{Password for @value{RANDOMUSER2}:} @i{<- Type the old password.}
- at b{Enter new password:} @i{<- Type the new password.}
- at b{Enter it again:} @i{<- Type a different new password.}
- at b{kpasswd: Password mismatch while reading password
-shell%}
- at end group
- at 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.
-
- at node Password Advice, Granting Access to Your Account, Changing Your Password, Password Management
- at 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.
-
- at need 2200
- at 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:
-
- at itemize @bullet
- at item some initials, like ``GykoR-66.'' for ``Get your kicks on Route
-66.''
-
- at item an easy-to-pronounce nonsense word, like ``slaRooBey'' or
-``krang-its''
-
- at item a misspelled phrase, like ``2HotPeetzas!'' or ``ItzAGurl!!!''
- at end itemize
-
- at 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.
-
- at need 3800
- at value{PRODUCT} allows your system administrators to automatically
-reject bad passwords, based on certain criteria, such as a password
-dictionary or a minimum length. For example, if the user
- at code{@value{RANDOMUSER1}}, who had a policy "strict" that required a
-minimum of 8 characaters, chose a password that was less than 8
-characters, Kerberos would give an error message like the following:
-
- at smallexample
- at group
- at b{shell%} kpasswd
- at b{Password for @value{RANDOMUSER1}:} @i{<- Type your old password here.}
-
- at value{RANDOMUSER1}'s password is controlled by the policy strict, which
-requires a minimum of 8 characters from at least 3 classes (the five classes
-are lowercase, uppercase, numbers, punctuation, and all other characters).
-
- at b{Enter new password:} @i{<- Type an insecure new password.}
- at b{Enter it again:} @i{<- Type it again.}
-
-kpasswd: Password is too short while attempting to change password.
-Please choose another password.
-
- at b{Enter new password:} @i{<- Type a good password here.}
- at b{Enter it again:} @i{<- Type it again.}
- at b{Password changed.
-shell%}
- at end group
- at end smallexample
-
- at 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.
-
- at node Granting Access to Your Account, , Password Advice, Password Management
- at subsection Granting Access to Your Account
-
- at 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:
-
- at smallexample
- at group
- at value{RANDOMUSER1}@@@value{PRIMARYREALM}
- at value{RANDOMUSER2}@@@value{SECONDREALM}
- at end group
- at end smallexample
-
- at noindent This file would allow the users @code{@value{RANDOMUSER1}} and
- at 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.
-
- at need 1000
-Using a @code{.k5login} file is much safer than giving out your
-password, because:
-
- at itemize @bullet
- at item You can take access away any time simply by removing the principal
-from your @code{.k5login} file.
-
- at 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,
- at i{e.g.}, over NFS), that user does not inherit your network privileges.
-
- at 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.
- at end itemize
-
-One common application is to have a @code{.k5login} file in
- at 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.
-
- at node Kerberos V5 Applications, , Password Management, Kerberos V5 Tutorial
- at section Kerberos V5 Applications
-
- at 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.
-
- at menu
-* Overview of Additional Features::
-* telnet::
-* rlogin::
-* FTP::
-* rsh::
-* rcp::
-* ksu::
- at end menu
-
- at node Overview of Additional Features, telnet, Kerberos V5 Applications, Kerberos V5 Applications
- at 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},
- at code{rcp}, and @code{ksu}. These programs have all of the original
-features of the corresponding non-Kerberos @code{rlogin}, @code{telnet},
- at code{ftp}, @code{rsh}, @code{rcp}, 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.
-
- at node telnet, rlogin, Overview of Additional Features, Kerberos V5 Applications
- at subsection telnet
-
-The @value{PRODUCT} @code{telnet} command works exactly like the
-standard UNIX telnet program, with the following Kerberos options added:
-
- at table @kbd
- at itemx -f
-forwards a copy of your tickets to the remote host.
-
- at itemx -F
-forwards a copy of your tickets to the remote host, and marks them
-re-forwardable from the remote host.
-
- at itemx -k @i{realm}
-requests tickets for the remote host in the specified realm, instead of
-determining the realm itself.
-
- at itemx -K
-uses your tickets to authenticate to the remote host, but does not log
-you in.
-
- at itemx -a
-attempt automatic login using your tickets. @code{telnet} will assume
-the same username unless you explicitly specify another.
-
- at itemx -x
-turns on encryption.
-
- at end table
-
- at need 4000
-For example, if @code{@value{RANDOMUSER2}} wanted to use the standard
-UNIX telnet to connect to the machine
- at code{@value{RANDOMHOST1}. at value{PRIMARYDOMAIN}}, he would type:
-
- at smallexample
- at group
- at b{shell%} telnet @value{RANDOMHOST1}. at value{SECONDDOMAIN}
- at b{Trying 128.0.0.5 ...
-Connected to @value{RANDOMHOST1}. at value{SECONDDOMAIN}.
-Escape character is '^]'.
-
-NetBSD/i386 (daffodil) (ttyp3)
-
-login:} @value{RANDOMUSER2}
- at b{Password:} @i{<- @value{RANDOMUSER2} types his password here}
- at b{Last login: Fri Jun 21 17:13:11 from @value{RANDOMHOST2}. at value{PRIMARYDOMAIN}
-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%}
- at end group
- at end smallexample
-
- at noindent Note that the machine
- at code{@value{RANDOMHOST1}. at value{SECONDDOMAIN}} asked for
- at 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
- at code{@value{RANDOMUSER2}}'s password.
-
- at need 4000
-If, on the other hand, @code{@value{RANDOMUSER1}} wanted to use the
- at value{PRODUCT} telnet to connect to the machine
- at code{@value{RANDOMHOST2}. at value{PRIMARYDOMAIN}}, she could forward a
-copy of her tickets, request an encrypted session, and log on as herself
-as follows:
-
- at smallexample
- at group
- at b{shell%} telnet -a -f -x @value{RANDOMHOST2}. at value{PRIMARYDOMAIN}
- at b{Trying 128.0.0.5...
-Connected to @value{RANDOMHOST2}. at value{PRIMARYDOMAIN}.
-Escape character is '^]'.
-[ Kerberos V5 accepts you as ``@value{RANDOMUSER1}@@@value{PRIMARYDOMAIN}'' ]
-[ Kerberos V5 accepted forwarded credentials ]
-What you type is protected by encryption.
-Last login: Tue Jul 30 18:47:44 from @value{RANDOMHOST1}. at value{SECONDDOMAIN}
-Athena Server (sun4) Version 9.1.11 Tue Jul 30 14:40:08 EDT 2002
-
-shell%}
- at end group
- at end smallexample
-
- at noindent Note that @code{@value{RANDOMUSER1}}'s machine used Kerberos
-to authenticate her to @code{@value{RANDOMHOST2}. at value{PRIMARYDOMAIN}},
-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}
- at code{telnet} are discussed in the Reference section of this manual.
-(@pxref{telnet Reference})
-
- at need 2000
- at node rlogin, FTP, telnet, Kerberos V5 Applications
- at subsection rlogin
-
- at need 1000
-The @value{PRODUCT} @code{rlogin} command works exactly like the
-standard UNIX rlogin program, with the following Kerberos options added:
-
- at table @kbd
- at itemx -f
-forwards a copy of your tickets to the remote host.
-
- at itemx -F
-forwards a copy of your tickets to the remote host, and marks them
-re-forwardable from the remote host.
-
- at itemx -k @i{realm}
-requests tickets for the remote host in the specified realm, instead of
-determining the realm itself.
-
- at itemx -x
-encrypts the input and output data streams (the username is sent unencrypted)
-
- at end table
-
- at need 3000
-For example, if @code{@value{RANDOMUSER2}} wanted to use the standard
-UNIX rlogin to connect to the machine
- at code{@value{RANDOMHOST1}. at value{SECONDDOMAIN}}, he would type:
-
- at smallexample
- at group
- at b{shell%} rlogin @value{RANDOMHOST1}. at value{SECONDDOMAIN} -l @value{RANDOMUSER2}
- at b{Password:} @i{<- @value{RANDOMUSER2} types his password here}
- at 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%}
- at end group
- at end smallexample
-
- at noindent Note that the machine
- at code{@value{RANDOMHOST1}. at value{SECONDDOMAIN}} asked for
- at 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
- at code{@value{RANDOMUSER2}}'s password.
-
- at need 4000
-If, on the other hand, @code{@value{RANDOMUSER1}} wanted to use
- at value{PRODUCT} rlogin to connect to the machine
- at code{@value{RANDOMHOST2}. at value{PRIMARYDOMAIN}}, she could forward a
-copy of her tickets, mark them as not forwardable from the remote host,
-and request an encrypted session as follows:
-
- at smallexample
- at group
- at b{shell%} rlogin @value{RANDOMHOST2}. at value{PRIMARYDOMAIN} -f -x
- at b{This rlogin session is using DES encryption for all data transmissions.
-Last login: Thu Jun 20 16:20:50 from @value{RANDOMHOST1}
-Athena Server (sun4) Version 9.1.11 Tue Jul 30 14:40:08 EDT 2002
-shell%}
- at end group
- at end smallexample
-
- at noindent Note that @code{@value{RANDOMUSER1}}'s machine used Kerberos
-to authenticate her to @code{@value{RANDOMHOST2}. at value{PRIMARYDOMAIN}},
-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}
- at code{rlogin} are discussed in the Reference section of this manual.
-(@pxref{rlogin Reference})
-
- at node FTP, rsh, rlogin, Kerberos V5 Applications
- at subsection FTP
-
- at need 1000
-The @value{PRODUCT} @code{FTP} program works exactly like the standard
-UNIX FTP program, with the following Kerberos features added:
-
- at table @kbd
- at itemx -k @i{realm}
-requests tickets for the remote host in the specified realm, instead of
-determining the realm itself.
-
- at itemx -f
-requests that your tickets be forwarded to the remote host. The
- at kbd{-f} argument must be the last argument on the command line.
-
- at 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.
- at end table
-
- at need 5000
-For example, suppose @code{@value{RANDOMUSER1}} wants to get her
- at code{RMAIL} file from the directory @code{~@value{RANDOMUSER1}/Mail},
-on the host @code{@value{RANDOMHOST1}. at value{PRIMARYDOMAIN}}. She wants
-to encrypt the file transfer. The exchange would look like the
-following:
-
- at smallexample
- at group
- at b{shell%} ftp @value{RANDOMHOST1}. at value{PRIMARYDOMAIN}
-Connected to @value{RANDOMHOST1}. at value{PRIMARYDOMAIN}.
-220 @value{RANDOMHOST1}. at value{PRIMARYDOMAIN} 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 (@value{RANDOMHOST1}. at 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
- at b{shell%}
- at end group
- at end smallexample
-
-The full set of options to @value{PRODUCT} @code{FTP} are discussed
-in the Reference section of this manual. (@pxref{FTP Reference})
-
- at node rsh, rcp, FTP, Kerberos V5 Applications
- at subsection rsh
-
-The @value{PRODUCT} @code{rsh} program works exactly like the standard
-UNIX rlogin program, with the following Kerberos features added:
-
- at table @kbd
- at itemx -f
-forwards a copy of your tickets to the remote host.
-
- at itemx -F
-forwards a copy of your tickets to the remote host, and marks them
-re-forwardable from the remote host.
-
- at itemx -k @i{realm}
-requests tickets for the remote host in the specified realm, instead of
-determining the realm itself.
-
- at itemx -x
-encrypts the input and output data streams (the command line is not encrypted)
-
- at end table
-
- at 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:
-
- at smallexample
- at group
- at b{shell%} rsh @value{RANDOMHOST2}. at value{SECONDDOMAIN} -l root -x date
- at b{This rsh session is using DES encryption for all data transmissions.
-Tue Jul 30 19:34:21 EDT 2002
-shell%}
- at end group
- at end smallexample
-
-If you forwarded your Kerberos tickets, @code{rsh} automatically
-destroys them when it exits. The full set of options to @value{PRODUCT}
- at code{rsh} are discussed in the Reference section of this manual.
-(@pxref{rsh Reference})
-
- at node rcp, ksu, rsh, Kerberos V5 Applications
- at subsection rcp
-
- at need 1000
-The @value{PRODUCT} @code{rcp} program works exactly like the standard
-UNIX rcp program, with the following Kerberos features added:
-
- at table @kbd
- at itemx -k @i{realm}
-requests tickets for the remote host in the specified realm, instead of
-determining the realm itself.
-
- at itemx -x
-turns on encryption.
- at end table
-
-
- at need 1500
-For example, if you wanted to copy the file @code{/etc/motd} from the
-host @code{@value{RANDOMHOST1}. at value{PRIMARYDOMAIN}} into the current
-directory, via an encrypted connection, you would simply type:
-
- at smallexample
- at b{shell%} rcp -x @value{RANDOMHOST1}. at value{PRIMARYDOMAIN}:/etc/motd .
- at 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})
-
- at node ksu, , rcp, Kerberos V5 Applications
- at 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.
-
- at need 2000
-For example, @code{@value{RANDOMUSER2}} has put
- at code{@value{RANDOMUSER1}}'s Kerberos principal in his @code{.k5login}
-file. If @code{@value{RANDOMUSER1}} uses @code{ksu} to become
- at 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
- at code{@value{RANDOMUSER2}}'s prompt is represented as
- at code{@value{RANDOMUSER2}%}.)
-
- at smallexample
- at group
- at b{@value{RANDOMUSER1}%} ksu @value{RANDOMUSER2}
- at b{Account @value{RANDOMUSER2}: authorization for @value{RANDOMUSER1}@@@value{PRIMARYREALM} successful
-Changing uid to @value{RANDOMUSER2} (3382)
- at value{RANDOMUSER2}%}
- at end group
- at end smallexample
-
- at 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:
-
- at smallexample
- at group
- at b{@value{RANDOMUSER2}%} klist
- at b{Ticket cache: /tmp/krb5cc_3382.1
-Default principal: @value{RANDOMUSER1}@@@value{PRIMARYREALM}
-
-Valid starting Expires Service principal
-07/31/04 21:53:01 08/01/04 07:52:53 krbtgt/@value{PRIMARYREALM}@@@value{PRIMARYREALM}
-07/31/04 21:53:39 08/01/04 07:52:53 host/@value{RANDOMHOST1}. at value{PRIMARYDOMAIN}@@@value{PRIMARYREALM}
- at value{RANDOMUSER2}%}
- at end group
- at end smallexample
-
- at need 2500
-If @code{@value{RANDOMUSER1}} had not appeared in
- at 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):
-
- at smallexample
- at group
- at b{@value{RANDOMUSER1}%} ksu @value{RANDOMUSER2}
- at 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.}
- at b{ksu: Password incorrect
-Authentication failed.
- at value{RANDOMUSER1}%}
- at end group
- at end smallexample
-
-Now, suppose @code{@value{RANDOMUSER2}} did not want to give
- at 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.
-
- at 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
- at kbd{-e} option. @code{@value{RANDOMUSER2}}'s @code{.k5users} file
-might look like the following:
-
- at smallexample
- at group
- at value{RANDOMUSER1}@@@value{PRIMARYREALM} /bin/ls /usr/bin/more
- at value{ADMINUSER}@@@value{PRIMARYREALM} /bin/ls
- at value{ADMINUSER}/admin@@@value{PRIMARYREALM} *
- at value{RANDOMUSER2}@@@value{SECONDREALM}
- at end group
- at end smallexample
-
- at noindent The above @code{.k5users} file would let
- at code{@value{RANDOMUSER1}} run only the commands @code{/bin/ls} and
- at 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,
- at 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
- at value{RANDOMUSER2} can allow himself to execute commands when he logs
-in, using Kerberos, from a machine in the realm @value{SECONDREALM}.
-
- at need 2500
-Then, when @code{@value{RANDOMUSER1}} wanted to list his home directory,
-she would type:
-
- at smallexample
- at group
- at b{@value{RANDOMUSER1}%} ksu @value{RANDOMUSER2} -e ls ~@value{RANDOMUSER2}
- at 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
- at value{RANDOMUSER1}%}
- at end group
- at end smallexample
-
- at 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}
- at i{command} option.
-
- at need 1000
-The @code{ksu} options you are most likely to use are:
-
- at table @kbd
- at 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
- at code{admin} instance. @xref{What is a Ticket?}.)
-
- at itemx -c
-specifies the location of your Kerberos credentials cache (ticket file).
-
- at itemx -k
-tells @code{ksu} not to destroy your Kerberos tickets when @code{ksu} is
-finished.
-
- at itemx -f
-requests forwardable tickets. (@xref{Obtaining Tickets with kinit}.) This
-is only applicable if @code{ksu} needs to obtain tickets.
-
- at itemx -l @i{lifetime}
-sets the ticket lifetime. (@xref{Obtaining Tickets with kinit}.) This is
-only applicable if @code{ksu} needs to obtain tickets.
-
- at 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).
-
- at itemx -Z
-tells @code{ksu} not to copy any Kerberos tickets to the new UID.
-
- at itemx -e @i{command}
-tells @code{ksu} to execute @i{command} and then exit. See the
-description of the @code{.k5users} file above.
-
- at itemx -a @i{text}
-(at the end of the command line) tells @code{ksu} to pass everything
-after @samp{-a} to the target shell.
- at end table
-
-The full set of options to @value{PRODUCT} @code{ksu} are discussed
-in the Reference section of this manual. (@pxref{ksu Reference})
-
- at node Kerberos V5 Reference, Kerberos Glossary, Kerberos V5 Tutorial, Top
- at chapter Kerberos V5 Reference
-
-This section will include copies of the manual pages for the
- at 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:
-
- at smallexample
- at b{shell%} man kinit
- at 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 at 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
- at code{.login}, @code{.profile}, or @code{.cshrc}.}:
-
- at smallexample
-setenv MANPATH /usr/local/man:/usr/man
- at end smallexample
-
- at noindent
-and the @value{PRODUCT} man pages were in the directory
- at code{/usr/@value{LCPRODUCT}/man}, you would change the line to the following:
-
- at smallexample
-setenv MANPATH /usr/@value{LCPRODUCT}/man:/usr/local/man:/usr/man
- at end smallexample
-
- at ifinfo
-Note to info users: the manual pages are not available within this info
-tree. You can read them from emacs with the command:
-
- at smallexample
-M-x manual-entry @emph{command}
- at end smallexample
- at end ifinfo
-
- at page
-
- at menu
-* kinit Reference::
-* klist Reference::
-* ksu Reference::
-* kdestroy Reference::
-* kpasswd Reference::
-* telnet Reference::
-* FTP Reference::
-* rlogin Reference::
-* rsh Reference::
-* rcp Reference::
- at end menu
-
- at node kinit Reference, klist Reference, Kerberos V5 Reference, Kerberos V5 Reference
- at section kinit Reference
-
- at iftex
- at special{psfile=kinit1.ps voffset=-700 hoffset=-40}
- at centerline{Reference Manual for @code{kinit}}
- at page
-
- at special{psfile=kinit2.ps voffset=-700 hoffset=-40}
- at centerline{Reference Manual for @code{kinit}}
- at page
- at end iftex
-
- at ifinfo
-Type @kbd{M-x manual-entry kinit} to read this manual page.
- at end ifinfo
-
- at ifhtml
- at html
-<a href="kinit.html"> kinit manpage</a>
- at end html
- at end ifhtml
-
- at node klist Reference, ksu Reference, kinit Reference, Kerberos V5 Reference
- at section klist Reference
-
- at iftex
- at special{psfile=klist1.ps voffset=-700 hoffset=-40}
- at centerline{Reference Manual for @code{klist}}
- at page
- at end iftex
-
- at iftex
- at special{psfile=klist2.ps voffset=-700 hoffset=-40}
- at centerline{Reference Manual for @code{klist}}
- at page
- at end iftex
-
- at ifinfo
-Type @kbd{M-x manual-entry klist} to read this manual page.
- at end ifinfo
-
- at ifhtml
- at html
-<a href="klist.html"> klist manpage</a>
- at end html
- at end ifhtml
-
- at node ksu Reference, kdestroy Reference, klist Reference, Kerberos V5 Reference
- at section ksu Reference
-
- at iftex
- at special{psfile=ksu1.ps voffset=-700 hoffset=-40}
- at centerline{Reference Manual for @code{ksu}}
- at page
-
- at special{psfile=ksu2.ps voffset=-700 hoffset=-40}
- at centerline{Reference Manual for @code{ksu}}
- at page
-
- at special{psfile=ksu3.ps voffset=-700 hoffset=-40}
- at centerline{Reference Manual for @code{ksu}}
- at page
-
- at special{psfile=ksu4.ps voffset=-700 hoffset=-40}
- at centerline{Reference Manual for @code{ksu}}
- at page
-
- at special{psfile=ksu5.ps voffset=-700 hoffset=-40}
- at centerline{Reference Manual for @code{ksu}}
- at page
- at end iftex
-
- at ifinfo
-Type @kbd{M-x manual-entry ksu} to read this manual page.
- at end ifinfo
-
- at ifhtml
- at html
-<a href="ksu.html"> ksu manpage</a>
- at end html
- at end ifhtml
-
- at node kdestroy Reference, kpasswd Reference, ksu Reference, Kerberos V5 Reference
- at section kdestroy Reference
-
- at iftex
- at special{psfile=kdestroy1.ps voffset=-700 hoffset=-60}
- at centerline{Reference Manual for @code{kdestroy}}
- at page
- at end iftex
-
- at ifinfo
-Type @kbd{M-x manual-entry kdestroy} to read this manual page.
- at end ifinfo
-
- at ifhtml
- at html
-<a href="kdestroy.html"> kdestroy manpage</a>
- at end html
- at end ifhtml
-
- at node kpasswd Reference, telnet Reference, kdestroy Reference, Kerberos V5 Reference
- at section kpasswd Reference
-
- at iftex
- at special{psfile=kpasswd1.ps voffset=-700 hoffset=-40}
- at centerline{Reference Manual for @code{kpasswd}}
- at page
- at end iftex
-
- at ifinfo
-Type @kbd{M-x manual-entry kpasswd} to read this manual page.
- at end ifinfo
-
- at ifhtml
- at html
-<a href="kpasswd.html"> kpasswd manpage</a>
- at end html
- at end ifhtml
-
- at node telnet Reference, FTP Reference, kpasswd Reference, Kerberos V5 Reference
- at section telnet Reference
-
- at iftex
- at special{psfile=telnet1.ps voffset=-700 hoffset=-40}
- at centerline{Reference Manual for @code{telnet}}
- at page
-
- at special{psfile=telnet2.ps voffset=-700 hoffset=-40}
- at centerline{Reference Manual for @code{telnet}}
- at page
-
- at special{psfile=telnet3.ps voffset=-700 hoffset=-40}
- at centerline{Reference Manual for @code{telnet}}
- at page
-
- at special{psfile=telnet4.ps voffset=-700 hoffset=-40}
- at centerline{Reference Manual for @code{telnet}}
- at page
-
- at special{psfile=telnet5.ps voffset=-700 hoffset=-40}
- at centerline{Reference Manual for @code{telnet}}
- at page
-
- at special{psfile=telnet6.ps voffset=-700 hoffset=-40}
- at centerline{Reference Manual for @code{telnet}}
- at page
-
- at special{psfile=telnet7.ps voffset=-700 hoffset=-40}
- at centerline{Reference Manual for @code{telnet}}
- at page
-
- at special{psfile=telnet8.ps voffset=-700 hoffset=-40}
- at centerline{Reference Manual for @code{telnet}}
- at page
-
- at special{psfile=telnet9.ps voffset=-700 hoffset=-40}
- at centerline{Reference Manual for @code{telnet}}
- at page
- at end iftex
-
- at ifinfo
-Type @kbd{M-x manual-entry telnet} to read this manual page.
- at end ifinfo
-
- at ifhtml
- at html
-<a href="telnet.html"> telnet manpage</a>
- at end html
- at end ifhtml
-
- at node FTP Reference, rlogin Reference, telnet Reference, Kerberos V5 Reference
- at section FTP Reference
-
- at iftex
- at special{psfile=ftp1.ps voffset=-700 hoffset=-40}
- at centerline{Reference Manual for @code{FTP}}
- at page
-
- at special{psfile=ftp2.ps voffset=-700 hoffset=-40}
- at centerline{Reference Manual for @code{FTP}}
- at page
-
- at special{psfile=ftp3.ps voffset=-700 hoffset=-40}
- at centerline{Reference Manual for @code{FTP}}
- at page
-
- at special{psfile=ftp4.ps voffset=-700 hoffset=-40}
- at centerline{Reference Manual for @code{FTP}}
- at page
-
- at special{psfile=ftp5.ps voffset=-700 hoffset=-40}
- at centerline{Reference Manual for @code{FTP}}
- at page
-
- at special{psfile=ftp6.ps voffset=-700 hoffset=-40}
- at centerline{Reference Manual for @code{FTP}}
- at page
-
- at special{psfile=ftp7.ps voffset=-700 hoffset=-40}
- at centerline{Reference Manual for @code{FTP}}
- at page
-
- at special{psfile=ftp8.ps voffset=-700 hoffset=-40}
- at centerline{Reference Manual for @code{FTP}}
- at page
-
- at special{psfile=ftp9.ps voffset=-700 hoffset=-40}
- at centerline{Reference Manual for @code{FTP}}
- at page
- at end iftex
-
- at ifinfo
-Type @kbd{M-x manual-entry FTP} to read this manual page.
- at end ifinfo
-
- at ifhtml
- at html
-<a href="ftp.html"> ftp manpage</a>
- at end html
- at end ifhtml
-
- at node rlogin Reference, rsh Reference, FTP Reference, Kerberos V5 Reference
- at section rlogin Reference
-
- at iftex
- at special{psfile=rlogin1.ps voffset=-700 hoffset=-40}
- at centerline{Reference Manual for @code{rlogin}}
- at page
-
- at special{psfile=rlogin2.ps voffset=-700 hoffset=-40}
- at centerline{Reference Manual for @code{rlogin}}
- at page
- at end iftex
-
- at ifinfo
-Type @kbd{M-x manual-entry rlogin} to read this manual page.
- at end ifinfo
-
- at ifhtml
- at html
-<a href="rlogin.html"> rlogin manpage</a>
- at end html
- at end ifhtml
-
- at node rsh Reference, rcp Reference, rlogin Reference, Kerberos V5 Reference
- at section rsh Reference
-
- at iftex
- at special{psfile=rsh1.ps voffset=-700 hoffset=-40}
- at centerline{Reference Manual for @code{rsh}}
- at page
-
- at special{psfile=rsh2.ps voffset=-700 hoffset=-40}
- at centerline{Reference Manual for @code{rsh}}
- at page
- at end iftex
-
- at ifinfo
-Type @kbd{M-x manual-entry rsh} to read this manual page.
- at end ifinfo
-
- at ifhtml
- at html
-<a href="rsh.html"> rsh manpage</a>
- at end html
- at end ifhtml
-
- at node rcp Reference, , rsh Reference, Kerberos V5 Reference
- at section rcp Reference
-
- at iftex
- at special{psfile=rcp1.ps voffset=-700 hoffset=-40}
- at centerline{Reference Manual for @code{rcp}}
- at page
- at end iftex
-
- at iftex
- at special{psfile=rcp2.ps voffset=-700 hoffset=-40}
- at centerline{Reference Manual for @code{rcp}}
- at page
- at end iftex
-
- at ifinfo
-Type @kbd{M-x manual-entry rcp} to read this manual page.
- at end ifinfo
-
- at ifhtml
- at html
-<a href="rcp.html"> rcp manpage</a>
- at end html
- at end ifhtml
-
- at node Kerberos Glossary, Copyright, Kerberos V5 Reference, Top
- at appendix Kerberos Glossary
-
- at include glossary.texinfo
-
- at node Copyright, , Kerberos Glossary, Top
- at appendix Copyright
-
- at include copyright.texinfo
-
- at contents
- at bye
More information about the cvs-krb5
mailing list