freebsd-dev/crypto/kerberosIV/man/kerberos.1
Mark Murray 03656ac1b0 Initial import of KTH eBones. This has been cleaned up to only include
the "core" Kerberos functionality. The rest of the userland will get their
own changes later.
1997-09-04 06:04:33 +00:00

259 lines
5.5 KiB
Groff

.\" $Id: kerberos.1,v 1.2 1996/06/12 21:29:16 bg Exp $
.\" Copyright 1989 by the Massachusetts Institute of Technology.
.\"
.\" For copying and distribution information,
.\" please see the file <mit-copyright.h>.
.\"
.TH KERBEROS 1 "Kerberos Version 4.0" "MIT Project Athena"
.SH NAME
kerberos \- introduction to the Kerberos system
.SH DESCRIPTION
The
Kerberos
system authenticates
individual users in a network environment.
After authenticating yourself to
Kerberos,
you can use network utilities such as
.IR rlogin ,
.IR rcp ,
and
.IR rsh
without
having to present passwords to remote hosts and without having to bother
with
.I \.rhosts
files.
Note that these utilities will work without passwords only if
the remote machines you deal with
support the
Kerberos
system.
All Athena timesharing machines and public workstations support
Kerberos.
.PP
Before you can use
Kerberos,
you must register as an Athena user,
and you must make sure you have been added to
the
Kerberos
database.
You can use the
.I kinit
command to find out.
This command
tries to log you into the
Kerberos
system.
.I kinit
will prompt you for a username and password.
Enter your username and password.
If the utility lets you login without giving you a message,
you have already been registered.
.PP
If you enter your username and
.I kinit
responds with this message:
.nf
Principal unknown (kerberos)
.fi
you haven't been registered as a
Kerberos
user.
See your system administrator.
.PP
A Kerberos name contains three parts.
The first is the
.I principal name,
which is usually a user's or service's name.
The second is the
.I instance,
which in the case of a user is usually null.
Some users may have privileged instances, however,
such as ``root'' or ``admin''.
In the case of a service, the instance is the
name of the machine on which it runs; i.e. there
can be an
.I rlogin
service running on the machine ABC, which
is different from the rlogin service running on
the machine XYZ.
The third part of a Kerberos name
is the
.I realm.
The realm corresponds to the Kerberos service providing
authentication for the principal.
For example, at MIT there is a Kerberos running at the
Laboratory for Computer Science and one running at
Project Athena.
.PP
When writing a Kerberos name, the principal name is
separated from the instance (if not null) by a period,
and the realm (if not the local realm) follows, preceded by
an ``@'' sign.
The following are examples of valid Kerberos names:
.sp
.nf
.in +8
billb
jis.admin
srz@lcs.mit.edu
treese.root@athena.mit.edu
.in -8
.fi
.PP
When you authenticate yourself with
Kerberos,
through either the workstation
.I toehold
system or the
.I kinit
command,
Kerberos
gives you an initial
Kerberos
.IR ticket .
(A
Kerberos
ticket
is an encrypted protocol message that provides authentication.)
Kerberos
uses this ticket for network utilities
such as
.I rlogin
and
.IR rcp .
The ticket transactions are done transparently,
so you don't have to worry about their management.
.PP
Note, however, that tickets expire.
Privileged tickets, such as root instance tickets,
expire in a few minutes, while tickets that carry more ordinary
privileges may be good for several hours or a day, depending on the
installation's policy.
If your login session extends beyond the time limit,
you will have to re-authenticate yourself to
Kerberos
to get new tickets.
Use the
.IR kinit
command to re-authenticate yourself.
.PP
If you use the
.I kinit
command to get your tickets,
make sure you use the
.I kdestroy
command
to destroy your tickets before you end your login session.
You should probably put the
.I kdestroy
command in your
.I \.logout
file so that your tickets will be destroyed automatically when you logout.
For more information about the
.I kinit
and
.I kdestroy
commands,
see the
.I kinit(1)
and
.I kdestroy(1)
manual pages.
.PP
Currently,
Kerberos
supports the following network services:
.IR rlogin ,
.IR rsh ,
and
.IR rcp .
Other services are being worked on,
such as the
.IR pop
mail system and NFS (network file system),
but are not yet available.
.SH "SEE ALSO"
kdestroy(1), kinit(1), klist(1), kpasswd(1), des_crypt(3), kerberos(3),
kadmin(8)
.SH BUGS
Kerberos
will not do authentication forwarding.
In other words,
if you use
.I rlogin
to login to a remote host,
you cannot use
Kerberos
services from that host
until you authenticate yourself explicitly on that host.
Although you may need to authenticate yourself on the remote
host,
be aware that when you do so,
.I rlogin
sends your password across the network in clear text.
.SH AUTHORS
Steve Miller, MIT Project Athena/Digital Equipment Corporation
.br
Clifford Neuman, MIT Project Athena
The following people helped out on various aspects of the system:
Jeff Schiller designed and wrote the administration server and its
user interface, kadmin.
He also wrote the dbm version of the database management system.
Mark Colan developed the
Kerberos
versions of
.IR rlogin ,
.IR rsh ,
and
.IR rcp ,
as well as contributing work on the servers.
John Ostlund developed the
Kerberos
versions of
.I passwd
and
.IR userreg .
Stan Zanarotti pioneered Kerberos in a foreign realm (LCS),
and made many contributions based on that experience.
Many people contributed code and/or useful ideas, including
Jim Aspnes,
Bob Baldwin,
John Barba,
Richard Basch,
Jim Bloom,
Bill Bryant,
Rob French,
Dan Geer,
David Jedlinsky,
John Kohl,
John Kubiatowicz,
Bob McKie,
Brian Murphy,
Ken Raeburn,
Chris Reed,
Jon Rochlis,
Mike Shanzer,
Bill Sommerfeld,
Jennifer Steiner,
Ted Ts'o,
and
Win Treese.
.SH RESTRICTIONS
COPYRIGHT 1985,1986 Massachusetts Institute of Technology