[ Previous | Next | Contents | Glossary | Home | Search ]
AIX Version 4.3 System User's Guide: Communications and Networks

Understanding the Secure Rcmds

The secure rcmds are rlogin, rcp, rsh, telnet, and ftp. These commands have been enhanced to provide additional authentication methods to those used today (known collectively as the Standard AIX method). The two additional methods are Kerberos V.5 and Kerberos V.4.

When using the Kerberos V.5 authentication method, the client gets a Kerberos V.5 ticket from the security server. The ticket is a portion of the user's current DCE credentials encrypted for the TCP/IP server with which they wish to connect. The daemon on the TCP/IP server decrypts the ticket. This allows the TCP/IP server to absolutely identify the user. If the DCE prinicpal described in the ticket is allowed access to the AIX user's account, the connection proceeds.

Note: Beginning with DCE version 2.2, the DCE security server can return Kerberos V.5 tickets.

In addition to authenticating the client, Kerberos V.5 forwards the current user's credentials to the TCP/IP server. If the credentials are marked forwardable, the client sends them to the server as a Kerberos TGT (Ticket Granting Ticket). On the TCP/IP server side, the daemon upgrades the TGT into full DCE credentials using the k5dcelogin command.

The ftp command uses a different authentication method than the other commands. It uses the GSSAPI security mechanism to pass the authentication between the ftp command and the ftpd daemon. Using the clear/safe/private subcommands, the ftp client supports data encryption.

Between AIX clients and servers, ftp has been enhanced to allow multiple byte transfers for encrypted data connections. The standards define only single byte transfers for encrypted data connections. When connected to third party machines and using data encryption, ftp follows the single byte transfer limit.

System Configuration

For all of the secure rcmds, there is a system-level configuration mechanism to determine which authentication methods are allowed for that system. The configuration controls both outgoing and incoming connections.

The authentication configuration consists of a library, libauthm.a, and two commands, lsauthent and chauthent, that provide command line access to the library's two routines: get_auth_methods and set_auth_methods.

The system supports three different authentication methods: Kerberos V.5, Kerberos V.4, and Standard AIX. The authentication method defines which method is used to authenticate a user across a network.

There is a fallback implementation when more than one authentication method is configured. If the first method fails to connect, the client attempts to authenticate using the next authentication method configured.

Authentication methods can be configured in any order. The only exception is that Standard AIX must be the final authentication method configured, since there is no fallback option from it. If Standard AIX is not a configured authentication method, password authentication is not attempted and any connection attempt using this method is rejected.

It is possible to configure the system without any authentication methods. In this case, the machine refuses all connections from and to any machine using secure rcmds.

For more information, see get_auth_methods, set_auth_methods, lsauthent, and chauthent.

Kerberos V.5 User Validation

When using the Kerberos V.5 authentication method, the TCP/IP client gets a service ticket encrypted for the TCP/IP server. When the server decrypts the ticket, it has a secure method of identifying the user (by DCE principal). However, it still needs to determine if this DCE principal is allowed access to the local account. Mapping the DCE principal to the local AIX account is handled by a shared library, libvaliduser.a, which has a single subroutine kvalid_user. If a different method of mapping is preferred, the system administrator must provide an alternative for the libvaliduser.a library.

DCE Configuration

To use the secure rcmds, two DCE principals must exist for every network interface to which they can be connected. They are:


where FullInterfaceName is the interface name and domain name. For the primary HostName.DomainName.

[ Previous | Next | Contents | Glossary | Home | Search ]