When kerberized versions of the ftp, rdist, rcp, rlogin, rsh, telnet, or ssh clients are used to connect to a server, the identity of the originating user must be authenticated to the Kerberos V5 authentication system. Account access can then be authorized if appropriate entries exist in the ~/.k5login file, the gsscred table, or if the default GSS/Kerberos authentication rules successfully map the Kerberos principal name to Unix login name.

To avoid security problems, the ~/.k5login file must be owned by the remote user on the server the client is attempting to access. The file should contain a private authorization list comprised of Kerberos principal names of the form principal/instance@realm. The /instance variable is optional in Kerberos principal names. For example, different principal names such as jdb@ENG.ACME.COM and jdb/happy.eng.acme.com@ENG.ACME.COM would each be legal, though not equivalent, Kerberos principals. The client is granted access if the ~/.k5login file is located in the login directory of the remote user account and if the originating user can be authenticated to one of the principals named in the file. See kadm5.acl(4) for more information on Kerberos principal names.

When no ~/.k5login file is found in the remote user's login account, the Kerberos V5 principal name associated with the originating user is checked against the gsscred table. If a gsscred table exists and the principal name is matched in the table, access is granted if the Unix user ID listed in the table corresponds to the user account the client is attempting to access. If the Unix user ID does not match, access is denied. See gsscred(1M).

For example, an originating user listed in the gsscred table with the principal name jdb@ENG.ACME.COM and the uid 23154 is granted access to the jdb-user account if 23154 is also the uid of jdb-user listed in the user account database. See passwd(4).

Finally, if there is no ~/.k5login file and the Kerberos V5 identity of the originating user is not in the gsscred table, or if the gsscred table does not exist, the client is granted access to the account under the following conditions (default GSS/Kerberos auth rules):

For example, if the originating user has the principal name jdb@ENG.ACME.COM and if the server is in realm SALES.ACME.COM, the client would be denied access even if jdb is a valid account name on the server. This is because the realms SALES.ACME.COM and ENG.ACME.COM differ.

The krb5.conf(4) auth_to_local_realm parameter also affects authorization. Non-default realms can be equated with the default realm for authenticated name-to-local name mapping.

See attributes(5) for a description of the following attributes:

ftp(1), rcp(1), rdist(1), rlogin(1), rsh(1), telnet(1), gsscred(1M), kadm5.acl(4), krb5.conf(4), passwd(4), attributes(5), gss_auth_rules(5)