Kerberos

Kerberos 是一个网络认证系统. 见 krb5 文档.

安装[编辑 | 编辑源代码]

在客户端和服务端上安装 krb5^包软件包.

注意： 强烈建议使用时钟同步守护进程来保持客户端/服务器时钟同步

如果尚未配置主机名解析，则可以手动将客户端和服务器添加到每台计算机的hosts(5)文件中。

注意： FQDN（myclient.example.com）必须是hosts文件中IP地址之后的第一个hostname。

客户端配置[编辑 | 编辑源代码]

编辑客户端的 /etc/krb5.conf 来适配你服务器的配置. 您可以从服务器复制此文件，或者只设置所需的领域信息.

测试[编辑 | 编辑源代码]

您现在应该能够在客户端上获得Kerberos凭证:

$ kinit

Password for [email protected]: ***

$ klist

Ticket cache: FILE:/tmp/krb5cc_1000
Default principal: [email protected]

Valid starting       Expires              Service principal
08/30/2017 15:36:10  08/31/2017 15:36:10  krbtgt/[email protected]

配置 kadmin[编辑 | 编辑源代码]

You will need /etc/krb5.conf configured on the kadmin client, and the server"s firewall configured for kadmin.

Configuring kadmin ACL[编辑 | 编辑源代码]

Create a principal for administration:

kadmin.local:  add_principal myuser/[email protected]

WARNING: no policy specified for myuser/[email protected]; defaulting to no policy
Enter password for principal "myuser/[email protected]": ***
Re-enter password for principal "myuser/[email protected]": ***
Principal "myuser/[email protected]" created.

Add the user to the kadmin ACL file:

/var/lib/krb5kdc/kadm5.acl

myuser/[email protected] *

This file"s format is described in the MIT Kerberos documentation

Configure kdc.conf:

/var/lib/krb5kdc/kdc.conf

[kdcdefaults]
    kdc_ports = 750,88

[realms]
    EXAMPLE.COM = {
        database_name = /var/lib/krb5kdc/principal
        acl_file = /var/lib/krb5kdc/kadm5.acl
        key_stash_file = /var/lib/krb5kdc/.k5.EXAMPLE.COM
        kdc_ports = 750,88
        max_life = 10h 0m 0s
        max_renewable_life = 7d 0h 0m 0s
    }

This file"s format is described in the MIT Kerberos documentation

Restart krb5-kdc.servce and krb5-kadmind.

You can now use kadmin as your own user, authenticating with kerberos:

$ kadmin

Authenticating as principal myuser/[email protected] with password.
Password for myuser/[email protected]: ***
kadmin:

Service principals and keytabs[编辑 | 编辑源代码]

First, ensure you have configured krb5.conf on all involved machines.

A kerberos principal has three components, formatted as `primary/instance@REALM`. For user principals, the primary is your username and the instance is omitted or is a role (eg. "admin"): `[email protected]` or `myuser/[email protected]`. For hosts, the primary is "host" and the instance is the server FQDN: `host/[email protected]`. For services, the primary is the service abbreviation and the instance is the FQDN: `nfs/[email protected]`. The realm can often be omitted, the local computer"s default realm is usually assumed.

With remote kadmin[编辑 | 编辑源代码]

This is the easier method, but requires you to have configured kadmin.

Open kadmin as root (so we can write the keytab) on the client, authenticating with your admin principal:

client# kadmin -p myuser/admin

Authenticating as principal myuser/admin with password.
Password for myuser/[email protected]:
kadmin:

Add a principal for any services you will be using, eg. "host" for SSH authentication or "nfs" for NFS:

kadmin: addprinc -randkey host/kbclient.example.com

WARNING: no policy specified for host/[email protected]; defaulting to no policy
Principal "host/[email protected]" created.

Save each key to the local keytab:

kadmin: ktadd host/kbclient.example.com

Entry for principal host/kbclient.example.com with kvno 2, encryption type aes256-cts-hmac-sha1-96 added to keytab FILE:/etc/krb5.keytab.
Entry for principal host/kbclient.example.com with kvno 2, encryption type aes128-cts-hmac-sha1-96 added to keytab FILE:/etc/krb5.keytab.

Without remote kadmin[编辑 | 编辑源代码]

Start kadmin on the Kerberos server, using either unix or kerberos authentication:

# kadmin.local

Authenticating as principal root/[email protected] with password.
kadmin.local:

Add a principal for any services you will be using, eg. "host" for SSH authentication or "nfs" for NFS:

kadmin.local: addprinc -randkey host/kbclient.example.com

WARNING: no policy specified for host/[email protected]; defaulting to no policy
Principal "host/[email protected]" created.

Save each key to a new keytab to be transferred to the client:

kadmin.local: ktadd -k kbclient.keytab host/kbclient.example.com

Entry for principal host/kbclient.example.com with kvno 2, encryption type aes256-cts-hmac-sha1-96 added to keytab FILE:/etc/krb5.keytab.
Entry for principal host/kbclient.example.com with kvno 2, encryption type aes128-cts-hmac-sha1-96 added to keytab FILE:/etc/krb5.keytab.

Finally, copy kbclient.keytab from the server to the client using SCP or similar, then put it in place with correct permissions:

# install -b -o root -g root -m 600 kbclient.keytab /etc/krb5.keytab

Finally, delete kbclient.keytab from the server and client.

Cross-Realm Trust[编辑 | 编辑源代码]

Set up a second server as shown above, then create the cross-realm principal on both KDCs. Cross-realm principals must be created with strong passwords, not -randkey, and the same password must be used on both KDCs. The principal must have the same key version number (kvno) in both KDCs.

To grant EXAMPLE.COM principals access to EXAMPLE.ORG resources, you would use the following principal:

kadmin# addprinc krbtgt/[email protected]

The [capaths] section of krb5.conf can be used to further control cross-realm trust relationships.

SSH authentication[编辑 | 编辑源代码]

Use the instructions in Service principals and keytabs to create a principal for the "host" service for both client and server, then put the client"s keys in the client"s keytab and the server"s keys in the server"s keytab.

Modify your SSH server configuration to enable GSSAPI authentication:

/etc/ssh/sshd_config

# GSSAPI Options
GSSAPIAuthentication yes
GSSAPICleanupCredentials yes

And modify your client configuration to send GSSAPI requests:

/etc/ssh/ssh_config

Host *
  GSSAPIAuthentication yes
  GSSAPIDelegateCredentials yes

Get a ticket-granting ticket on the client before using ssh:

$ kinit [email protected]

Password for [email protected]: ***

Pass the -v option to ssh to watch what"s happening:

$ ssh sshserver.example.com -v

debug1: Authentications that can continue: publickey,gssapi-with-mic,password
debug1: Next authentication method: gssapi-with-mic
debug1: Delegating credentials
debug1: Delegating credentials
debug1: Authentication succeeded (gssapi-with-mic).
Authenticated to sshserver.example.com ([192.168.100.136]:22).
debug1: channel 0: new [client-session]
debug1: Requesting [email protected]
debug1: Entering interactive session.
debug1: pledge: network
debug1: client_input_global_request: rtype [email protected] want_reply 0
Last login: Wed Aug 30 15:52:41 2017 from 192.168.100.1

And you should now see a host ticket on the client:

client$ klist

Ticket cache: FILE:/tmp/krb5cc_1000
Default principal: [email protected]

Valid starting       Expires              Service principal
08/30/2017 15:37:40  08/31/2017 15:37:40  krbtgt/[email protected]
08/30/2017 15:53:04  08/31/2017 15:37:40  host/[email protected]

Authorize other principals[编辑 | 编辑源代码]

To allow a different kerberos principal to authenticate to a user account, add the principal name to the target account"s .k5login file. For example, to allow [email protected] to SSH to alice"s account:

/home/alice/.k5login

[email protected]

NFS security[编辑 | 编辑源代码]

First, configure your NFS server server. Also see NFS Troubleshooting. Configuring a 时钟同步 daemon on both the clients and the server is strongly recommended. Clock drift will cause this to break, and the error message will not be helpful.

Use the instructions in Service principals and keytabs to create a principal for the "nfs" service for both client and server, then put the client"s keys in the client"s keytab and the server"s keys in the server"s keytab.

NFS server[编辑 | 编辑源代码]

Add a Kerberos export option. Multiple options can be specified using a colon as a delimiter:

sec=krb5 uses kerberos for authentication only, and transmits the data unauthenticated and unencrypted.
sec=krb5i uses kerberos for authentication and integrity checking, but still transmits data unencrypted.
sec=krb5p uses kerberos for authentication and encryption.
sec=sys does not use kerberos

/etc/exports

/srv/export *(rw,async,no_subtree_check,no_root_squash,sec=krb5p:krb5)

And reload the exports:

# exportfs -arv

NFS client[编辑 | 编辑源代码]

Mount the exported directory:

# mount nfsserver:/srv/export /mnt/

You can add -vv for verbose information, and may need -t nfs4 and -o sec=krb5p or your chosen security option.

Check that it worked with the mount command:

mount | grep krb5

nfsserver:/srv/export on /mnt type nfs4 (rw,relatime,vers=4.1,rsize=131072,wsize=131072,namlen=255,hard,proto=tcp,port=0,timeo=600,retrans=2,sec=krb5,clientaddr=192.168.100.139,local_lock=none,addr=192.168.100.136)

Browsers[编辑 | 编辑源代码]

Some browsers have support for Kerberos protocol but disable it by default. Here are the instructions how to enable it:

Chromium[编辑 | 编辑源代码]

Chromium needs to be run with a command line parameter that specifies a list of sites where Kerberos authentication is allowed. The easiest way is to add persistent flag to the config file:

/etc/chromium/policies/managed/test_policy.json

{
  "AuthServerWhitelist": "*.mycompany.com",
  "DisableAuthNegotiateCnameLookup": true
}

Firefox[编辑 | 编辑源代码]

To configure Firefox with trusted sites visit about:config and set network.negotiate-auth.trusted-uris property to FOO.COM (Note: for Firefox there is no "*."; for Chrome, there is).

Troubleshooting[编辑 | 编辑源代码]

Cannot set GSSAPI authentication names[编辑 | 编辑源代码]

Cannot set GSSAPI authentication names, aborting

Your realm is missing either the kadmin/admin or kadmin/changepw principal.

For clients, invalid arguments/options may happen on first setup if rpc-gssd is not loaded. Loading it is usually acomplished by enabling and starting nfs-client.target, but after first setup this target will need a restart.

SSH authentication fails while connecting to a server requiring GSSAPI with KeyExchange[编辑 | 编辑源代码]

If any of the following errors are encountered:

$ ssh -v -o GSSAPIDelegateCredentials=yes -o GSSAPIAuthentication=yes <user>@<IP address>
Unable to negotiate with <IP address> port 22: no matching key exchange method found. Their offer: gss-group14-sha1-...

$ ssh -v -o GSSAPIDelegateCredentials=yes -o GSSAPIKeyExchange=yes -o GSSAPIAuthentication=yes <user>@<IP address>
command-line: line 0: Bad configuration option: gssapikeyexchange

it means that package openssh^包 is not configured with GSSAPI patch for OpenSSH. You can install openssh-gssapi^AUR or follow this method.