Administering TCP/IP

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:

Client utilities Server daemon

ftp(TC) ftpd(ADMN)

rcmd(TC) and rcp(TC) rshd(ADMN)

rlogin(TC) rlogind(ADMN)

telnet(TC) telnetd(ADMN)

You can use these utilities and daemons in a Kerberos Version 5 realm to provide authenticated TCP/IP services as described below.

Client utilities	Server daemon
ftp(TC)	ftpd(ADMN)
rcmd(TC) and rcp(TC)	rshd(ADMN)
rlogin(TC)	rlogind(ADMN)
telnet(TC)	telnetd(ADMN)

NOTE: 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 or rgy_edit 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 would be:

/.:/sec/principal/host/foo.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 auth.config(ADMN) command.
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 k5login(SFF)), 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 login(M) and scologin(XC) 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 kinit(TC). 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 run the ksession(TC) command which will warn when the credentials are about to expire. The user can also use the klist(TC) command to view their credentials and their expiry date.

WARNING: 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 ktadd(ADMN) 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.

WARNING: You should only invoke ktadd(ADMN) 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
ksession

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.