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:exampleRe-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":kerberosRe-enter password for principal "root/admin@EXAMPLE.COM":kerberosPrincipal "root/admin@EXAMPLE.COM" created.
Create the user01 principal:
kadmin.local: addprinc user01 Enter password for principal "user01@EXAMPLE.COM":user01Re-enter password for principal "user01@EXAMPLE.COM":user01Principal "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.
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?
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.
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
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?
There is no version 7.1 available for download. I can’t even download, since none of the official repo as it. The earliest version is 7.2. Any suggestions?
You can still find older CentOS versions at https://wiki.centos.org/Download under the Archived Versions section.
nvm, I found the 7.1, now I have to figure out how to downgrade it to that version without losing all of the configs.
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
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
Hi,
You are almost asking for a FreeIPA server -> http://www.certdepot.net/rhel7-configure-freeipa-server/.
At this time, it is not clear if all tasks related to Kerberos can be done through separate Kerberos, NFS, LDAP servers or through a unique FreeIPA server.
It’s a question to ask Red Hat representatives.
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
There is no secrets: follow the various tutorials and become good at RHEL system administration!
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
Yes, this could effectively happen.
I wrote a tutorial about this kind of problem (here).
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.
I think kerberos/ntp/dns in one server is fine.
Concerning ipaserver, I agree with you and I don’t have any additional information.
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.
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.
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!
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!
Should that be /etc/ssh/sshd_config instead of ssh_config?
You are perfectly right. Fixed. Thanks.
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.
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.
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.
Your /etc/hosts file is not correct, the aliases have to be after the FQDNs:
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.
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.
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.
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.
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.
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.
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.
Hi,
do you think that setting up KDC is required in the exam for EX300k?
It could be for training purposes (Kerberized NFS configuration) but not for the exam itself.
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.
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…
Yes, you can install both Client and Server on the same machine without any problem but the KDC should be on another machine.
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
Interesting. Thanks.
I was able to get this to work on CentOS 7.2 using GSSAPIEnablek5users yes
in /etc/ssh/sshd_config
-Mike
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”.
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
Which minor version of RHEL/CentOS are you using?
I try to maintain 7.0.1406 (CentOS) as I believe is used on the test.
I tried to enter it in sshd_config and it would not start. I looked in /var/logs/messages and it complained about that entry.
I’m going to change the tutorial according to your remark. Thanks.