当 ftp、rcp、rlogin、rsh、ssh、telnet 或 ssh 客户机的 Kerberos 版本用于连接到服务器时，发起方用户的身份必须针对 Kerberos V5 验证系统进行验证。如果适当的条目存在于 ~/.k5login 文件、gsscred 表中，或如果缺省 GSS/Kerberos 验证规则成功将 Kerberos 主体名称映射到 Unix 登录名，则可授权帐户访问权。
要避免安全问题，~/.k5login 文件必须由客户机尝试访问的服务器上的远程用户所有。文件应该包含专用授权列表，其中包含格式为 principal/instance@realm 的 Kerberos 主体名称。/instance 变量在 Kerberos 主体名称中是可选项。例如，jdb@ENG.ACME.COM 和 jdb/happy.eng.acme.com@ENG.ACME.COM 之类的不同主体名称均是合法的 Kerberos 主体（虽然并不等效）。如果 ~/.k5login 文件位于远程用户帐户的登录目录中且可以针对文件中指定的某个主体验证发起方用户，则可以授予客户机访问权限。有关 Kerberos 主体名称的更多信息，请参见 gkadmin(1M) 和 kadm5.acl(4)。
当远程用户的登录帐户中找不到 ~/.k5login 文件时，会针对 gsscred 表检查与发起方用户相关联的 Kerberos V5 主体名称。如果 gsscred 表存在且主体名称在表中有匹配项目，并且表中列出的 Unix 用户 ID 对应于客户机尝试访问的用户帐户，则会授予访问权。如果 Unix 用户 ID 不匹配，则会拒绝访问权。请参见 gsscred(1M)。
例如，如果 23154 也是用户帐户数据库中列出的 jdb-user 的 uid，则会授予 gsscred 表中列出的具有主体名称 jdb@ENG.ACME.COM 和 uid 23154 的发起方用户对 jdb-user 帐户的访问权。请参见 passwd(4)。
最后，如果不存在 ~/.k5login 文件且发起方用户的 Kerberos V5 身份不在 gsscred 表中，或 gsscred 表不存在，则在以下情况下会授予客户机对帐户的访问权（缺省 GSS/Kerberos 验证规则）：
经过验证的主体名称的用户部分与客户机指定的 Unix 帐户名相同。
客户机和服务器的领域部分相同，除非 krb5.conf(4) auth_to_local_realm 参数用于创建等效项。
Unix 帐户名存在于服务器上。
例如，如果发起方用户的主体名称为 jdb@ENG.ACME.COM 且服务器位于 SALES.ACME.COM 领域中，则即使 jdb 是服务器上有效的帐户名也会拒绝客户机的访问权。这是因为领域 SALES.ACME.COM 和 ENG.ACME.COM 不同。
krb5.conf(4) auth_to_local_realm 参数也会影响授权。非缺省领域可等效于经过验证的 name-to-local name 映射的缺省领域。
每用户帐户的授权文件。
系统帐户文件。此信息也可在目录服务中。请参见 passwd(4)。
有关以下属性的说明，请参见 attributes(5)：
|
ftp(1)、rcp(1)、rsh(1)、telnet(1)、gkadmin(1M)、gsscred(1M)、kadm5.acl(4)、krb5.conf(4)、passwd(4)、attributes(5)、gss_auth_rules(5)