RHEL7: Configure a Kerberos KDC.

Share this link

Presentation of Kerberos

Kerberos is an authentication protocol that was developed at MIT in 1988.
A client connects to a KDC server (Kerberos Distribution Center) by using a principal (kind of login) and get a ticket. As long as the ticket is valid, the client can access some services and doesn’t need to authenticate any more.
Both client (here kbclient.example.com) and KDC server (here kbserver.example.com) must be inside the same realm (usually your domain name written in upper case, here EXAMPLE.COM).

Prerequisites

Before configuring Kerberos, NTP synchronization and hostname resolution must be working.
If DNS is not configured, add the following lines in the /etc/hosts file (replace the specified ip addresses with yours):

192.168.1.11 kbserver.example.com
192.168.1.12 kbclient.example.com

Caution: When adding a new line in the /etc/hosts file, you have to write the fully qualified domain name just after the ip address. If you use one or several aliases and add them before the fully qualified domain name, Kerberos will not work.

Server Configuration

Install the Kerberos packages:

# yum install -y krb5-server krb5-workstation pam_krb5

First, edit the /var/kerberos/krb5kdc/kdc.conf file and replace EXAMPLE.COM with your own realm.
Optionally, uncomment the master_key_type = aes256-cts line and paste the following line in the [realms] stanza:

default_principal_flags = +preauth

Note: This removes compatibility with Kerberos 4 but improves security.

Then, in the /etc/krb5.conf file, uncomment all the lines, replace EXAMPLE.COM with your own realm, example.com with your own domain name, and kerberos.example.com with your own KDC server name (here kbserver.example.com).

Finally, edit the /var/kerberos/krb5kdc/kadm5.acl file and replace EXAMPLE.COM with your own realm.

Create the Kerberos database (replace EXAMPLE.COM with you own realm):

# kdb5_util create -s -r EXAMPLE.COM
Loading random data
Initializing database '/var/kerberos/krb5kdc/principal' for realm 'EXAMPLE.COM',
master key name 'K/M@EXAMPLE.COM'
You will be prompted for the database Master Password.
It is important that you NOT FORGET this password.
Enter KDC database master key: example
Re-enter KDC database master key to verify: example

Note: It can be necessary to type keys on the keyboard to increase the entropy needed for the random data generation!

Start the Kerberos services:

# systemctl start krb5kdc kadmin

Activate the Kerberos services at boot:

# systemctl enable krb5kdc kadmin

Create a user for test:

# useradd user01

Execute the Kerberos administration tool:

# kadmin.local
Authenticating as principal root/admin@EXAMPLE.COM with password.

Create the admin principal:

kadmin.local:  addprinc root/admin
Authenticating as principal root/admin@EXAMPLE.COM with password.
WARNING: no policy specified for root/admin@EXAMPLE.COM; defaulting to no policy
Enter password for principal "root/admin@EXAMPLE.COM": kerberos
Re-enter password for principal "root/admin@EXAMPLE.COM": kerberos
Principal "root/admin@EXAMPLE.COM" created.

Create the user01 principal:

kadmin.local:  addprinc user01
Enter password for principal "user01@EXAMPLE.COM": user01
Re-enter password for principal "user01@EXAMPLE.COM": user01
Principal "user01@EXAMPLE.COM" created.

Add the KDC hostname to the Kerberos database:

kadmin.local:  addprinc -randkey host/kbserver.example.com
Authenticating as principal root/admin@EXAMPLE.COM with password.
WARNING: no policy specified for host/kbserver.example.com@EXAMPLE.COM; defaulting to no policy
Principal "host/kbserver.example.com@EXAMPLE.COM" created.

Create a local copy stored by default in the /etc/krb5.keytab file:

kadmin.local:  ktadd host/kbserver.example.com
Authenticating as principal root/admin@EXAMPLE.COM with password.
Entry for principal host/kbserver.example.com with kvno 2, encryption type aes256-cts-hmac-sha1-96 added to keytab WRFILE:/etc/krb5.keytab.
Entry for principal host/kbserver.example.com with kvno 2, encryption type aes128-cts-hmac-sha1-96 added to keytab WRFILE:/etc/krb5.keytab.
Entry for principal host/kbserver.example.com with kvno 2, encryption type des3-cbc-sha1 added to keytab WRFILE:/etc/krb5.keytab.
Entry for principal host/kbserver.example.com with kvno 2, encryption type arcfour-hmac added to keytab WRFILE:/etc/krb5.keytab.
Entry for principal host/kbserver.example.com with kvno 2, encryption type camellia256-cts-cmac added to keytab WRFILE:/etc/krb5.keytab.
Entry for principal host/kbserver.example.com with kvno 2, encryption type camellia128-cts-cmac added to keytab WRFILE:/etc/krb5.keytab.
Entry for principal host/kbserver.example.com with kvno 2, encryption type des-hmac-sha1 added to keytab WRFILE:/etc/krb5.keytab.
Entry for principal host/kbserver.example.com with kvno 2, encryption type des-cbc-md5 added to keytab WRFILE:/etc/krb5.keytab.

Exit the Kerberos administration tool:

kadmin.local:  quit

Edit the /etc/ssh/sshd_config file and add/uncomment the following lines:

GSSAPIAuthentication yes
GSSAPIDelegateCredentials yes

Reload the sshd service configuration:

# systemctl reload sshd

Configure the PAM component at the command line:

# authconfig --enablekrb5 --update

To get the correct firewall configuration (port udp/tcp 88 for Kerberos itself, port tcp 749 for kadmin communication), create the /etc/firewalld/services/kerberos.xml file and paste the following lines:

<?xml version="1.0" encoding="utf-8"?>
<service>
  <short>Kerberos</short>
  <description>Kerberos network authentication protocol server</description>
  <port protocol="tcp" port="88"/>
  <port protocol="udp" port="88"/>
  <port protocol="tcp" port="749"/>
</service>

Note: A Kerberos Firewalld configuration file already exists in the /usr/lib/firewalld/services directory but it doesn’t specify the kadmin protocol (749/tcp). This would force all configurations to be made on the KDC server only, which is not very handy.

Add the new service to the firewall :

# firewall-cmd --permanent --add-service=kerberos

Reload the firewall configuration:

# firewall-cmd --reload

Test your configuration (here kbserver.example.com is the KDC server name):

# su - user01
$ kinit
Password for user01@EXAMPLE.COM: user01
$ klist
Ticket cache: KEYRING:persistent:1000:1000
Default principal: user01@EXAMPLE.COM

Valid starting Expires Service principal
07/22/2014 16:48:35 07/23/2014 16:48:11 krbtgt/EXAMPLE.COM@EXAMPLE.COM
 renew until 07/22/2014 16:48:11
$ ssh kbserver.example.com

Now, you should be able to quit and reconnect without giving any password.
Note: To delete a ticket, use the kdestroy command.

Source: RHEL 5 Deployment Guide.

Troubleshooting Tip

When troubleshooting Kerberos behaviour as root, you can assign a filename to the KRB5_TRACE environment variable. This will help you trace the various steps followed by Kerberos.

# export KRB5_TRACE=/dev/stdout
# kinit
[2878] 1451496694.41411: Getting initial credentials for root@EXAMPLE.COM
[2878] 1451496694.41547: Sending request (183 bytes) to EXAMPLE.COM
...

Additional Resources

You can also watch Andrew Mallett‘s video about setting up a KDC (23min/2015).
The chapter 11 of the RHEL 7 System-Level Authentication Guide deals with the KDC configuration.

1 Star2 Stars3 Stars4 Stars5 Stars (6 votes, average: 5.00 out of 5)
Loading...
45 comments on “RHEL7: Configure a Kerberos KDC.
  1. SkoolofManoovah says:

    Hi CertDepot,

    I have followed the process you’ve laid out here to setup KDC server and client, and afterwards I can run “kinit user” and enter my password, and then “klist” and see the tgt listed. But when I ssh from client into the server I still always need to enter my password to log in.

    Can you suggest anything I may have missed?

    • CertDepot says:

      Sorry, I don’t know.
      Update: In RHEL 7.1, this problem, that was only happening on the KDC, doesn’t seem to occur any more.

      • pomer says:

        I’m on 7.3 and the issue is when you add “GSSAPIDelegateCredentials yes” to /etc/ssh/sshd_config, the sshd service fails to load due to “config error.” I have enabled only on the /etc/ssh/ssh_config” and sshd load properly. However, it still requires me to login with password. Based on the verbose from when I ssh, it shows that It is not able to find a key via the different auth method. Lastly, it uses the local key, that I provide with my password. Not sure why. Any thoughts. Here is the verbose output.

        [root@ipa ~]# su – user01
        Last login: Wed Jun 14 23:23:32 EDT 2017 from ipa.example.com on pts/1
        [user01@ipa ~]$ ssh kbserver
        user01@kbserver’s password:
        Last login: Wed Jun 14 23:29:25 2017
        [user01@ipa ~]$ klist
        Ticket cache: KEYRING:persistent:1003:krb_ccache_Wd6qRIM
        Default principal: user01@EXAMPLE.COM

        Valid starting Expires Service principal
        06/14/2017 23:29:44 06/15/2017 23:29:33 krbtgt/EXAMPLE.COM@EXAMPLE.COM
        [user01@ipa ~]$ exit
        logout
        Connection to kbserver closed.
        [user01@ipa ~]$ ssh kbserver
        user01@kbserver’s password:
        Last login: Wed Jun 14 23:30:01 2017 from ipa.example.com
        [user01@ipa ~]$ exit
        logout
        Connection to kbserver closed.
        [user01@ipa ~]$ ssh -vvv kbserver
        OpenSSH_6.6.1, OpenSSL 1.0.1e-fips 11 Feb 2013
        debug1: Reading configuration data /etc/ssh/ssh_config
        debug1: /etc/ssh/ssh_config line 56: Applying options for *
        debug2: ssh_connect: needpriv 0
        debug1: Connecting to kbserver [192.168.245.100] port 22.
        debug1: Connection established.
        debug1: identity file /home/user01/.ssh/id_rsa type -1
        debug1: identity file /home/user01/.ssh/id_rsa-cert type -1
        debug1: identity file /home/user01/.ssh/id_dsa type -1
        debug1: identity file /home/user01/.ssh/id_dsa-cert type -1
        debug1: identity file /home/user01/.ssh/id_ecdsa type -1
        debug1: identity file /home/user01/.ssh/id_ecdsa-cert type -1
        debug1: identity file /home/user01/.ssh/id_ed25519 type -1
        debug1: identity file /home/user01/.ssh/id_ed25519-cert type -1
        debug1: Enabling compatibility mode for protocol 2.0
        debug1: Local version string SSH-2.0-OpenSSH_6.6.1
        debug1: Remote protocol version 2.0, remote software version OpenSSH_6.6.1
        debug1: match: OpenSSH_6.6.1 pat OpenSSH_6.6.1* compat 0x04000000
        debug2: fd 3 setting O_NONBLOCK
        debug3: load_hostkeys: loading entries for host “kbserver” from file “/home/user01/.ssh/known_hosts”
        debug3: load_hostkeys: found key type ECDSA in file /home/user01/.ssh/known_hosts:2
        debug3: load_hostkeys: loaded 1 keys
        debug3: order_hostkeyalgs: prefer hostkeyalgs: ecdsa-sha2-nistp256-cert-v01@openssh.com,ecdsa-sha2-nistp384-cert-v01@openssh.com,ecdsa-sha2-nistp521-cert-v01@openssh.com,ecdsa-sha2-nistp256,ecdsa-sha2-nistp384,ecdsa-sha2-nistp521
        debug1: SSH2_MSG_KEXINIT sent
        debug1: SSH2_MSG_KEXINIT received
        debug2: kex_parse_kexinit: curve25519-sha256@libssh.org,ecdh-sha2-nistp256,ecdh-sha2-nistp384,ecdh-sha2-nistp521,diffie-hellman-group-exchange-sha256,diffie-hellman-group-exchange-sha1,diffie-hellman-group14-sha1,diffie-hellman-group1-sha1
        debug2: kex_parse_kexinit: ecdsa-sha2-nistp256-cert-v01@openssh.com,ecdsa-sha2-nistp384-cert-v01@openssh.com,ecdsa-sha2-nistp521-cert-v01@openssh.com,ecdsa-sha2-nistp256,ecdsa-sha2-nistp384,ecdsa-sha2-nistp521,ssh-ed25519-cert-v01@openssh.com,ssh-rsa-cert-v01@openssh.com,ssh-dss-cert-v01@openssh.com,ssh-rsa-cert-v00@openssh.com,ssh-dss-cert-v00@openssh.com,ssh-ed25519,ssh-rsa,ssh-dss
        debug2: kex_parse_kexinit: aes128-ctr,aes192-ctr,aes256-ctr,arcfour256,arcfour128,aes128-gcm@openssh.com,aes256-gcm@openssh.com,chacha20-poly1305@openssh.com,aes128-cbc,3des-cbc,blowfish-cbc,cast128-cbc,aes192-cbc,aes256-cbc,arcfour,rijndael-cbc@lysator.liu.se
        debug2: kex_parse_kexinit: aes128-ctr,aes192-ctr,aes256-ctr,arcfour256,arcfour128,aes128-gcm@openssh.com,aes256-gcm@openssh.com,chacha20-poly1305@openssh.com,aes128-cbc,3des-cbc,blowfish-cbc,cast128-cbc,aes192-cbc,aes256-cbc,arcfour,rijndael-cbc@lysator.liu.se
        debug2: kex_parse_kexinit: hmac-md5-etm@openssh.com,hmac-sha1-etm@openssh.com,umac-64-etm@openssh.com,umac-128-etm@openssh.com,hmac-sha2-256-etm@openssh.com,hmac-sha2-512-etm@openssh.com,hmac-ripemd160-etm@openssh.com,hmac-sha1-96-etm@openssh.com,hmac-md5-96-etm@openssh.com,hmac-md5,hmac-sha1,umac-64@openssh.com,umac-128@openssh.com,hmac-sha2-256,hmac-sha2-512,hmac-ripemd160,hmac-ripemd160@openssh.com,hmac-sha1-96,hmac-md5-96
        debug2: kex_parse_kexinit: hmac-md5-etm@openssh.com,hmac-sha1-etm@openssh.com,umac-64-etm@openssh.com,umac-128-etm@openssh.com,hmac-sha2-256-etm@openssh.com,hmac-sha2-512-etm@openssh.com,hmac-ripemd160-etm@openssh.com,hmac-sha1-96-etm@openssh.com,hmac-md5-96-etm@openssh.com,hmac-md5,hmac-sha1,umac-64@openssh.com,umac-128@openssh.com,hmac-sha2-256,hmac-sha2-512,hmac-ripemd160,hmac-ripemd160@openssh.com,hmac-sha1-96,hmac-md5-96
        debug2: kex_parse_kexinit: none,zlib@openssh.com,zlib
        debug2: kex_parse_kexinit: none,zlib@openssh.com,zlib
        debug2: kex_parse_kexinit:
        debug2: kex_parse_kexinit:
        debug2: kex_parse_kexinit: first_kex_follows 0
        debug2: kex_parse_kexinit: reserved 0
        debug2: kex_parse_kexinit: curve25519-sha256@libssh.org,ecdh-sha2-nistp256,ecdh-sha2-nistp384,ecdh-sha2-nistp521,diffie-hellman-group-exchange-sha256,diffie-hellman-group-exchange-sha1,diffie-hellman-group14-sha1,diffie-hellman-group1-sha1
        debug2: kex_parse_kexinit: ssh-rsa,ecdsa-sha2-nistp256,ssh-ed25519
        debug2: kex_parse_kexinit: aes128-ctr,aes192-ctr,aes256-ctr,arcfour256,arcfour128,aes128-gcm@openssh.com,aes256-gcm@openssh.com,chacha20-poly1305@openssh.com,aes128-cbc,3des-cbc,blowfish-cbc,cast128-cbc,aes192-cbc,aes256-cbc,arcfour,rijndael-cbc@lysator.liu.se
        debug2: kex_parse_kexinit: aes128-ctr,aes192-ctr,aes256-ctr,arcfour256,arcfour128,aes128-gcm@openssh.com,aes256-gcm@openssh.com,chacha20-poly1305@openssh.com,aes128-cbc,3des-cbc,blowfish-cbc,cast128-cbc,aes192-cbc,aes256-cbc,arcfour,rijndael-cbc@lysator.liu.se
        debug2: kex_parse_kexinit: hmac-md5-etm@openssh.com,hmac-sha1-etm@openssh.com,umac-64-etm@openssh.com,umac-128-etm@openssh.com,hmac-sha2-256-etm@openssh.com,hmac-sha2-512-etm@openssh.com,hmac-ripemd160-etm@openssh.com,hmac-sha1-96-etm@openssh.com,hmac-md5-96-etm@openssh.com,hmac-md5,hmac-sha1,umac-64@openssh.com,umac-128@openssh.com,hmac-sha2-256,hmac-sha2-512,hmac-ripemd160,hmac-ripemd160@openssh.com,hmac-sha1-96,hmac-md5-96
        debug2: kex_parse_kexinit: hmac-md5-etm@openssh.com,hmac-sha1-etm@openssh.com,umac-64-etm@openssh.com,umac-128-etm@openssh.com,hmac-sha2-256-etm@openssh.com,hmac-sha2-512-etm@openssh.com,hmac-ripemd160-etm@openssh.com,hmac-sha1-96-etm@openssh.com,hmac-md5-96-etm@openssh.com,hmac-md5,hmac-sha1,umac-64@openssh.com,umac-128@openssh.com,hmac-sha2-256,hmac-sha2-512,hmac-ripemd160,hmac-ripemd160@openssh.com,hmac-sha1-96,hmac-md5-96
        debug2: kex_parse_kexinit: none,zlib@openssh.com
        debug2: kex_parse_kexinit: none,zlib@openssh.com
        debug2: kex_parse_kexinit:
        debug2: kex_parse_kexinit:
        debug2: kex_parse_kexinit: first_kex_follows 0
        debug2: kex_parse_kexinit: reserved 0
        debug2: mac_setup: setup hmac-md5-etm@openssh.com
        debug1: kex: server->client aes128-ctr hmac-md5-etm@openssh.com none
        debug2: mac_setup: setup hmac-md5-etm@openssh.com
        debug1: kex: client->server aes128-ctr hmac-md5-etm@openssh.com none
        debug1: kex: curve25519-sha256@libssh.org need=16 dh_need=16
        debug1: kex: curve25519-sha256@libssh.org need=16 dh_need=16
        debug1: sending SSH2_MSG_KEX_ECDH_INIT
        debug1: expecting SSH2_MSG_KEX_ECDH_REPLY
        debug1: Server host key: ECDSA 88:d3:f7:85:f5:ba:40:98:8b:23:20:2f:51:8c:25:95
        debug3: load_hostkeys: loading entries for host “kbserver” from file “/home/user01/.ssh/known_hosts”
        debug3: load_hostkeys: found key type ECDSA in file /home/user01/.ssh/known_hosts:2
        debug3: load_hostkeys: loaded 1 keys
        debug3: load_hostkeys: loading entries for host “192.168.245.100” from file “/home/user01/.ssh/known_hosts”
        debug3: load_hostkeys: found key type ECDSA in file /home/user01/.ssh/known_hosts:1
        debug3: load_hostkeys: loaded 1 keys
        debug1: Host ‘kbserver’ is known and matches the ECDSA host key.
        debug1: Found key in /home/user01/.ssh/known_hosts:2
        debug1: ssh_ecdsa_verify: signature correct
        debug2: kex_derive_keys
        debug2: set_newkeys: mode 1
        debug1: SSH2_MSG_NEWKEYS sent
        debug1: expecting SSH2_MSG_NEWKEYS
        debug2: set_newkeys: mode 0
        debug1: SSH2_MSG_NEWKEYS received
        debug1: SSH2_MSG_SERVICE_REQUEST sent
        debug2: service_accept: ssh-userauth
        # $OpenBSD: sshd_config,v 1.93 2014/01/10 05:59:19 djm Exp $

        # This is the sshd server system-wide configuration file. See
        # sshd_config(5) for more information.

        # This sshd was compiled with PATH=/usr/local/bin:/usr/bin

        # The strategy used for options in the default sshd_config shipped with
        # OpenSSH is to specify options with their default value where
        # possible, but leave them commented. Uncommented options override the
        # default value.

        # If you want to change the port on a SELinux system, you have to tell
        # SELinux about this change.
        # semanage port -a -t ssh_port_t -p tcp #PORTNUMBER
        #
        #Port 22
        #AddressFamily any
        #ListenAddress 0.0.0.0
        #ListenAddress ::

        # The default requires explicit activation of protocol 1
        #Protocol 2

        # HostKey for protocol version 1
        #HostKey /etc/ssh/ssh_host_key
        # HostKeys for protocol version 2
        HostKey /etc/ssh/ssh_host_rsa_key
        #HostKey /etc/ssh/ssh_host_dsa_key
        HostKey /etc/ssh/ssh_host_ecdsa_key
        HostKey /etc/ssh/ssh_host_ed25519_key

        # Lifetime and size of ephemeral version 1 server key
        #KeyRegenerationInterval 1h
        #ServerKeyBits 1024

        # Ciphers and keying
        #RekeyLimit default none

        # Logging
        # obsoletes QuietMode and FascistLogging
        #SyslogFacility AUTH
        SyslogFacility AUTHPRIV
        #LogLevel INFO

        # Authentication:

        “/etc/ssh/sshd_config” 154L, 4392C
        # GSSAPI options
        debug1: SSH2_MSG_SERVICE_ACCEPT received
        debug2: key: /home/user01/.ssh/id_rsa ((nil)),
        debug2: key: /home/user01/.ssh/id_dsa ((nil)),
        debug2: key: /home/user01/.ssh/id_ecdsa ((nil)),
        debug2: key: /home/user01/.ssh/id_ed25519 ((nil)),
        debug1: Authentications that can continue: publickey,gssapi-keyex,gssapi-with-mic,password
        debug3: start over, passed a different list publickey,gssapi-keyex,gssapi-with-mic,password
        debug3: preferred gssapi-keyex,gssapi-with-mic,publickey,keyboard-interactive,password
        debug3: authmethod_lookup gssapi-keyex
        debug3: remaining preferred: gssapi-with-mic,publickey,keyboard-interactive,password
        debug3: authmethod_is_enabled gssapi-keyex
        debug1: Next authentication method: gssapi-keyex
        debug1: No valid Key exchange context
        debug2: we did not send a packet, disable method
        debug3: authmethod_lookup gssapi-with-mic
        debug3: remaining preferred: publickey,keyboard-interactive,password
        debug3: authmethod_is_enabled gssapi-with-mic
        debug1: Next authentication method: gssapi-with-mic
        debug2: we sent a gssapi-with-mic packet, wait for reply
        debug1: Authentications that can continue: publickey,gssapi-keyex,gssapi-with-mic,password
        debug2: we sent a gssapi-with-mic packet, wait for reply
        debug1: Authentications that can continue: publickey,gssapi-keyex,gssapi-with-mic,password
        debug2: we did not send a packet, disable method
        debug3: authmethod_lookup publickey
        debug3: remaining preferred: keyboard-interactive,password
        debug3: authmethod_is_enabled publickey
        debug1: Next authentication method: publickey
        debug1: Trying private key: /home/user01/.ssh/id_rsa
        debug3: no such identity: /home/user01/.ssh/id_rsa: No such file or directory
        debug1: Trying private key: /home/user01/.ssh/id_dsa
        debug3: no such identity: /home/user01/.ssh/id_dsa: No such file or directory
        debug1: Trying private key: /home/user01/.ssh/id_ecdsa
        debug3: no such identity: /home/user01/.ssh/id_ecdsa: No such file or directory
        debug1: Trying private key: /home/user01/.ssh/id_ed25519
        debug3: no such identity: /home/user01/.ssh/id_ed25519: No such file or directory
        debug2: we did not send a packet, disable method
        debug3: authmethod_lookup password
        debug3: remaining preferred: ,password
        debug3: authmethod_is_enabled password
        debug1: Next authentication method: password
        user01@kbserver’s password:
        debug3: packet_send2: adding 64 (len 51 padlen 13 extra_pad 64)
        debug2: we sent a password packet, wait for reply

        • CertDepot says:

          The tutorials have been tested on CentOS 7.0, 7.1 and 7.2 but I’m not sure about 7.3, which could explain your problems. As there are almost no report of the exam using RHEL 7.2 and none with RHEL 7.3, do you think it’s a good idea to test the configurations with so recent versions?

    • iaskakho says:

      check that everything resolves correctly.
      in /etc/hosts 192.168.1.11 kbserver.example.com kbserver
      also enable debugging in sshd -d -d -d (/usr/lib/systemd/system/sshd.service)
      from client side you can use:
      $ KRB5_TRACE=/dev/stdout ssh -vvv kbserver.example.com
      on server side: # journalctl -xeu sshd

      if all is well in the log:
      Jul 02 16:22:29 kbserver sshd[7677]: Authorized to user01, krb5 principal user01@EXAMPLE.COM (ssh_gssapi_krb5_cmdok)
      Jul 02 16:22:29 kbserver sshd[7677]: Accepted gssapi-with-mic for user01 from 192.168.1.11 port 46943 ssh2

  2. FredSim says:

    Hi,

    Can i setup Kerbose, NFS and Domain server in one VM ‘Server’ as a whole? How do i do that? How to test out the user login when using NFS to authenticate by kerboros in that VM server. Thanks

  3. FredSim says:

    Hi,

    Can i setup Kerbose, NFS, Domain and Mail server in one VM ‘Server’ as a whole? How do i do that? How to test out the user login when using NFS to authenticate by kerboros in that VM server. Thanks

  4. twostep says:

    It is worth to mention that during generate the kdc database on the virtual machine via command:
    kdb5_util create
    due to insufficient entropy data:
    cat /proc/sys/kernel/random/entropy_avail
    the process will hang.
    The solution is to install package:
    yum install rng-tools
    and feed entropy via command:
    rngd -r /dev/urandom

  5. samuel.sappa says:

    hi CertDepot,
    is it ok both kerberos/ntp/dns in one server ?
    or can be done using ipaserver instead, my concern is when using ipaserver I will not get the same experience in the exam.

  6. hasanin says:

    Hello,
    Thanks for such great resources, hope you all the best.
    I have a question, is Installing and configuring a kdc kerberos server part of the exam objectives? according to Sander van Vugt it is not, then this tutorial is mainly for kerberos client testing purpose and I don’t need to memorize it for the exam purpose?
    One more question, according to the client tutorial I need to manually add the user account to the kdc client machine then he gets the single sign on, but that defeats the purpose of single sign on right? I mean you have to run “useradd newuser” on all the servers?
    Thanks again for this website.

    • CertDepot says:

      Concerning the installation and configuration of a KDC Kerberos server, this is not part of the exam: it’s only for testing purpose.
      About the requirement to create a user, you are also right, you shouldn’t need to create any. My tutorial requires a update on this point.

  7. Mike_ says:

    Do we really need to restart the sshd daemon after updating /etc/ssh/ssh_config (adding GSSAPI)? I thought ssh_config was the client configuration file, and sshd_config was the server configuration file, not sure why we would need to restart the server daemon after making a “client” change.

    Thank you, great site!

  8. Carl says:

    Quick funny note. I typed in the kerberos.xml file vs copy/paste and had ‘encoding’ typed in as ‘encodeing’. Starting the firewall didn’t report an error, it just loaded. But trying to connect would give me a password prompt but kick back with a connection error. It was a puzzle until I copy/pasted this xml file and did a diff to find the error. Doh!

  9. arober32 says:

    Should that be /etc/ssh/sshd_config instead of ssh_config?

  10. Peatross says:

    So something doesn’t make sense here. I followed this guide exactly, time, hosts file. I do ‘kinit’ and get a ticket but when I ssh it always asks for a password. So in doing more troubleshooting with ssh -vvv I see this error:

    debug1: Unspecified GSS failure. Minor code may provide more information
    Server host/kdc@EXAMPLE.COM not found in Kerberos database

    So the names are resolving differently, ssh or GSSAPI is trying to resolve the principle host/kdc@EXAMPLE.com when I type ssh kdc.example.com which isn’t there because when I added the principle with ‘addprinc -randkey host/kdc.example.com’ it added ‘host/kdc.example.com@EXAMPLE.COM’ as I can see with list_principles.

    So to resolve the problem I added the name that GSSAPI was trying to get to with ‘addprinc -randkey host/kdc’ since @EXAMPLE.COM is automatically appended, this generates the correct name and I could login finally without providing a password.

    • Sam says:

      Double check on your timing by using ntpq -p(assuming your using ntp) check for large time delays, or large jitter.

      I think your problem may be with the DNS settings. Try and ping the revelant both to/from server/client and make sure your ipaddress is correct.

      • Peatross says:

        Well, the KDC was also the NTP server and I had successful syncs from the client (chronyc sources). DNS is not configured, I’m using /etc/hosts my entries are correct as far as I know, example:

        192.168.122.1 kdc kdc.example.com
        192.168.122.83 server1 server1.example.com

        and the resolve correctly with ping.

        It just looks like everything I add into the kerberos database gets the appending @EXAMPLE.COM, which makes sense. But SSH/GSSAPI just doesn’t seem to be querying the correct principle. I’m not sure and still confused, I would maybe have to test with other services that use kerberos. But at the same time I would like to move on to the next topic.

        • CertDepot says:

          Your /etc/hosts file is not correct, the aliases have to be after the FQDNs:

          192.168.122.1 kdc.example.com kdc 
          192.168.122.83 server1.example.com server1

          This is clearly explained at the beginning of the tutorial.
          I don’t know if it’s the only cause of your problem, but you have to change that first.

          • Peatross says:

            Thanks for letting me know, I overlooked that. That might be it also it seems to be working with the right principal in the database now.

            I’m guessing since I had the alias first it was looking for the alias/principal in the database.. Interesting.

            Great site CertDepot and thanks for the help.

        • Sam says:

          In addition to Certdepot comments.

          Studying for the RHCE, I recommend setting up a local DNS. It is good to have that knowledge, but it is difficult to set up.

          With the host file method can have other issues.

          I am unsure if using a mixture of NTP and chronyc is wise. Someone with more experience may be able give a better comment on this one.

          • Peatross says:

            I’m still learning, obviously. But I think its being used by default now. I’m use this release: CentOS Linux release 7.3.1611 (Core)

            From what I’ve read chronyd is better than NTP for most situations. chronyc says I’m getting syncs, timedatectl says ntp enabled: yes, NTP synchronized: yes, and the time from timedatectl on both the client and the KDC look exactly the same.

            I agree about setting up a DNS server though, I will probably have to do that as I’m interested in setting one up anyways.

          • Sam says:

            I suspect you are going a little too fast through the tutorials. Take your time, and understand how to troubleshoot problems. Methods change between the different versions of the operating system, so prepare to adapt. The Operating System on the exam may be different from the version you are studying on. I haven’t used chrony so I can’t comment on it.

  11. Peatross says:

    adding GSSAPIDelegateCredentials yes to the sshd_config caused the service to fail to start, I think that this setting is required on the client and not on the server.

    • pomer says:

      Yeah, that is interesting. Journalctl shows config error as well. Let me try commenting it out.

      Unit sshd.service has begun starting up.
      Jun 14 23:00:11 ipa.example.com sshd[11559]: /etc/ssh/sshd_config: line 94: Bad configuration option: GSSAPIDelegateCredentials
      Jun 14 23:00:11 ipa.example.com sshd[11559]: /etc/ssh/sshd_config: terminating, 1 bad configuration options
      Jun 14 23:00:11 ipa.example.com systemd[1]: sshd.service: main process exited, code=exited, status=255/n/a
      Jun 14 23:00:11 ipa.example.com systemd[1]: Failed to start OpenSSH server daemon.

  12. benny says:

    Hi,

    do you think that setting up KDC is required in the exam for EX300k?

  13. solferatu says:

    Watch carefully how the SSH configurations might affect your system. The directive GSSAPIDelegateCredentials yes is an unknown specification on my CentOS 7.2 machine. The result was that SSHD then failed to run, taking down a number of services with it (I spotted this when nmap marked port 22 as closed, along with several others that had been working fine). I also noticed that sshd_config highlighted this entry slightly different in vim, telling me that it didn’t know what to do with this. On the client side, running kadmin and similar commands would return an error “kadmin: Cannot contact any KDC realm” for my domain. After commenting-out the GSSAPI directive and rebooting, everything worked. I believe newer deployments of SSH use a different value for what’s being accomplished here.

  14. kumarsegu05 says:

    Hi Admin,

    Thanks for the clear tutorial. I am doing a POC for an application.

    Can we install both Client and Server in same machine? If so, how to make entries in Host file. Please explain.

    Thanks in advance…

  15. Oxygen says:

    Hi CertDepot,

    Thanks for the article. A couple of things seem to be outdated:

    1) sshd_config doesn’t accept GSSAPIDelegateCredentials but everything is working fine without it
    2) now firewalld has a service for kadmin, so can use that

    Cheers

  16. mikeinsa77 says:

    I was able to get this to work on CentOS 7.2 using GSSAPIEnablek5users yes
    in /etc/ssh/sshd_config
    -Mike

  17. Pat says:

    Hi,
    Is there any reason i am getting this trying to add the root/admin princ?
    [root@ipa ~]# kadmin.local
    Authenticating as principal root/admin@RHCE.LOCAL with password.
    kadmin.local: addprinc root/admin
    WARNING: no policy specified for root/admin@RHCE.LOCAL; defaulting to no policy
    Enter password for principal “root/admin@RHCE.LOCAL”:
    Re-enter password for principal “root/admin@RHCE.LOCAL”:
    add_principal: Invalid argument while creating “root/admin@RHCE.LOCAL”.

  18. Mike_ says:

    At the step we are to add or modify /etc/ssh/sshd_config with “GSSAPIDelegateCredentials”, I noticed sshd fails to restart:

    Edit the /etc/ssh/sshd_config file and add/uncomment the following lines:

    GSSAPIAuthentication yes
    GSSAPIDelegateCredentials yes

    I think that entry should go in /etc/ssh/ssh_config to affect a client, rather than a server. That option or entry is only viable for /etc/ssh/ssh_config. e.g. See man page https://linux.die.net/man/5/sshd_config

Leave a Reply

Upcoming Events (Local Time)

There are no events.

RHCSA7: Task of the day

Allowed time: 15 minutes.
Get an iso image of CentOS 7 (or a DVD) and set up a local repository.

RHCE7: Task of the day

Allowed time: 10 minutes.
Set up a caching-only DNS server.

Follow me on Twitter

Poll for favorite RHEL 7 book

What is your favorite RHEL 7 book to prepare RHCSA & RHCE exams?

View Results

Loading ... Loading ...

Poll for most difficult RHCSA 7 topic

What do you think is the most difficult RHCSA 7 topic?

View Results

Loading ... Loading ...

Poll for most difficult RHCE 7 topic

What do you think is the most difficult RHCE 7 topic?

View Results

Loading ... Loading ...