Using the Secure TCP (Kerberized) utilities
This release includes Secure TCP versions
(providing Kerberos Version 5 authentication) of the following
client utilities and server daemons:
You can use these utilities and daemons in a Kerberos Version 5 realm
to provide authenticated TCP/IP services as described
rcmd(TC) and rcp(TC)
You cannot use the Kerberos authentication features of these utilities
unless you have a Kerberos Version 5 Security Server such as the
SCO Security Services (supplied with the SCO Distributed
Services Release 1.0.3).
The utilities will function without providing Kerberos authentication
if you do not have such a server.
Configuring the Secure TCP utilities
To use these utilities with Kerberos Version 5 authentication, you
must first define the users (interactive principals) and host systems
(machine principals) on the Security Server(s) for the Kerberos
realm where they are to operate:
If you are using SCO Security Services, the cell
administrator (authentication principal) must use
the SCO Distributed Administration Service Security Manager
to add a registry object
for each interactive and machine principal to
/.:/sec/principal in the local cell.
See the secadmin(ADMD) and rgy_edit(8sec)
manual pages for more information.
Machine principals must be added to the host subhierarchy.
For example, the machine principal corresponding to the host
foo in the domain bar.com
Interactive principals may be added
directly to the /.:/sec/principal hierarchy.
Create passwords in the account properties of all new principals.
On each host where Secure TCP utilities or daemons are to be
run, log in as root and run the
Use auth.config to
define the DCE cell (or Kerberos realm) and fully qualified
domain name of the Security Server that will be used to authenticate
service requests. When asked for a host password for Secure TCP
services, you can select a machine-generated password as you do not
need to remember this password.
Use auth.config to choose the level of authentication
required for access to the ftpd, rshd,
rlogind and telnetd daemons.
You can select to make authentication optional if some users
require traditional unauthenticated access.
If users are required to use authenticated access, the access control
file, .k5login (see
must exist in their home directories on the
machine where the server daemon is running.
This file contains the names and cells of principals that can access an
account. For example, the entry ``chuck@local_cell'' specifies
that the principal chuck in the cell (or realm)
local_cell has access.
Only the owner must have write permission on .k5login,
and the owner must either be root or the
user associated with the home directory.
Obtaining Kerberos session credentials
Before a user can use the Secure TCP utilities, they
must obtain Kerberos session credentials. Because the current versions of
do not support Kerberos authenticated login, there are two alternative
methods by which a user may obtain these credentials:
Obtaining session credentials using kinit
Log in locally using unauthenticated login and then obtain
session credentials using
The kinit command will authenticate the user's session with
the Security Server and obtain a Ticket Granting Ticket for the user's
session provided the user can supply the correct password for their
interactive principal name. To monitor their credentials, the user must
command which will warn when the credentials are about to expire. The
user can also use the
command to view their credentials and their expiry date.
If a user performs an authenticated connection to another host
(gamma) from a host (beta) to which they
already connected remotely from a machine (alpha),
their password will be transmitted in clear text across the network
from alpha to beta.
Obtaining session credentials using ktadd and kinit
To avoid the possibility that passwords can be transmitted in clear text,
root can use the
command to create user keys on the various machines that different users
are allowed to access. Alternatively a user can use ktadd
to create a user key on each of the machines that they need to use.
You should only invoke
on the system to which you are directly logged in. This is to prevent
passwords being passed in clear text across the network.
For example, to obtain a user key for the interactive principal
chuck with password ``clydenw''
for the cell local_cell, enter the following commands:
ktadd -p chuck@local_cell -pw clydenw -f ~chuck/.v5srvtab
chmod 600 ~chuck/.v5srvtab
This creates a private key table .v5srvtab
for chuck in their home directory and changes
its permissions so only chuck and root
can read from or write to this file.
(Note that this example assumes that the shell being used
is either ksh or csh.)
To use their private key table when obtaining session credentials, the
user calls kinit from their .profile or
.login file. This example also shows ksession
being run to monitor chuck's credentials:
kinit -k -t ~chuck/.v5srvtab
For more information about using the SCO Security Services,
see the SCO Security Services Release and Installation Notes. For more information about using the
SCO DCE Executive, see the SCO DCE Executive Release and Installation Notes.
Protecting against IP address spoofing attacks
Deleting user equivalence
© 2003 Caldera International, Inc. All rights reserved.
SCO OpenServer Release 5.0.7 -- 11 February 2003