[602] in Kerberos
rkinit and rkinitd
daemon@TELECOM.MIT.EDU (qjb@ATHENA.MIT.EDU)
Sun Jan 22 19:05:44 1989
From: qjb@ATHENA.MIT.EDU
To: qjb@ATHENA.MIT.EDU
Cc: kerberos@ATHENA.MIT.EDU
In-Reply-To: <qjb@ATHENA.MIT.EDU>'s message of Sun, 22 Jan 89 18:16:02 EST <8901222316.AA14061@SOUP.MIT.EDU>
I've already gotten requests for the manual pages. Here they are.
I'm interested in any comments or complaints that anyone may have.
--Jay
-------------------
NAME
rkinit - establish kerberos tickets safely on a remote host
SYNOPSIS
rkinit host [-u username] [-l localname] [-notimeout]
DESCRIPTION
rkinit is a program that allows a user with valid kerberos
tickets to establish tickets on a remote registered host,
i.e., one that has an rcmd key. In the current implementa-
tion, the ticket file on the remote host will be the
default: /tmp/tkt<uid> on a unix host where <uid> is the
user id of the person who owns the ticket file. You can
think of rkinit as a substitute for rlogin followed by
kinit. If you can rlogin to a host with your tickets as a
certain user and create tickets as that user, you can
achieve this with rkinit.
If no commandline arguments are given, rkinit will prompt
for a password and replicate the invoker's tickets on the
specified remote host. These tickets will be owned on the
remote host by the user who invoked rkinit and will be for
the local realm of the remote host. rkinit can be used to
create any tickets on a remote host and have those tickets
be owned by any user to whom they entitle a login. Thus,
the invoker can create tickets for a user if he is in that
user's .klogin file. rkinit always tells the invoker whose
password should be entered. The kerberos realm of the tick-
ets to be obtained is printed if either a realm is specified
in the username field explained below or if the realm of the
remote host is different from the local realm. rkinit will
also tell you who is to own the tickets if the user who will
own the tickets is different from the name in the tickets.
If username is specified, in the format name[.inst][@realm]
is specified, the tickets create on the remote host will be
the tickets indicated by the username field. The password
you should supply is the password for these tickets. If
localname is specified, the ticket file on the remote host
will be owned by the user localname. You should still sup-
ply the password for your current tickets or the password
required to obtain username tickets if specified. Kerberos
realm should be used if the host on which you are creating
tickets is in a kerberos realm recognized by the client host
but the host's kerberos realm is not specified in
krb.realms. If the realm of the remote host is specified,
however, this parameter is not necessary. -notimeout
prevents the client from timing out which it would otherwise
do in thirty seconds.
If you do not specify an explicit realm in the username
field of rkinit, you will be prompted for tickets in the
local realm of the remote host. Thus, if you use rkinit to
establish tickets on a remote host in a different kerberos
realm and you do not specify a realm name explicitly in the
username field, rather than "copying" your tickets exactly,
rkinit will try to establish tickets whose principal and
instance match but whose realm is the local realm of the
remote host.
The same access checks that are used by rlogin are used by
rkinit. In order for you to create username tickets owned
by localname on a remote host, you must be able to login to
the remote host as localname using username tickets.
EXAMPLES
% rkinit soup
Kerberos initialization on host priam for qjb
Password:
%
% rkinit charon -u qjb.root
Kerberos initialization on host priam for qjb.root
Password:
%
% rkinit soup -l local
Kerberos initialization: qjb's tickets for local on host
soup
Password:
%
% rkinit dodo
Kerberos initialization on host dodo for
qjb@SMS_TEST.MIT.EDU
Password:
%
NOTE
Since rkinit creates the ticket file in a fixed place for a
given user, it is possible for one user to create tickets
that will overwrite other tickets owned by the same user.
This will ordinarily not be a problem since the usual case
is that you can only create tickets for yourself. The prin-
cipal exception, however, is root. If you create tickets
for yourself to be owned by root on the remote host, it is a
good idea to rename the ticket file from /tmp/tkt0 and set
the environment variable KRBTKFILE appropriately.
BUGS
Only one rkinit can be run to a given server at a time.
FUTURE EXPANSION
It might be good for the user running rkinit to be able to
specify the name of the ticket file and for rkinitd to be
smarter about where to put tickets owned by root.
SEE ALSO
rkinitd(8)
AUTHOR
Emanuel Jay Berkenbilt (MIT-Project Athena)
-------------------
NAME
rkinitd - server for rkinit, a remote ticket establishment
utility
SYNOPSIS
rkinit [-notimeout]
DESCRIPTION
rkinitd is the server for rkinit. See rkinit(1) for informa-
tion about rkinit. rkinitd can be started either from the
commandline or by inetd. In either case it must be run as
root or be installed setuid root as it does a setuid(2) call
before establishing tickets, attempts to bind to a
privileged port, and needs to be able to read /etc/srvtab.
rkinitd normally times out in 30 seconds. Invoking rkinitd
with the -notimeout flag will override this behavior.
If you wish to run rkinitd from inetd, you should install
the following line in inetd.conf:
atest6 dgram udp wait unswitched root
/site/local/rtbin/rkinitd rkinitd
rkinitd must be running on a machine with a srvtab contain-
ing an rcmd.<host> key.
BUGS
Only one rkinit can be run to a given server at a time.
This is because rkinitd does not make any effort to keep
track of where requests are coming from or what the nature
of the requests are.
FUTURE EXPANSION
It might be good for the user running rkinit to be able to
specify the name of the ticket file and for rkinitd to be
smarter about where to put tickets owned by root.
SEE ALSO
rkinit(1) inetd(8)
AUTHOR
Emanuel Jay Berkenbilt (MIT-Project Athena)
