error reading keytab file krb5.keytab

Question

I've noticed these kerberos keytab error messages on both SLES 11.2 and CentOS 6.3:

sshd[31442]: pam_krb5[31442]: error reading keytab 'FILE: / etc/ krb5. keytab'

/etc/krb5.keytab does not exist on our hosts, and from what I understand of the keytab file, we don't need it. Per this kerberos keytab introduction:

A keytab is a file containing pairs of Kerberos principals and encrypted keys (these are derived from the Kerberos password). You can use this file to log into Kerberos without being prompted for a password. The most common personal use of keytab files is to allow scripts to authenticate to Kerberos without human interaction, or store a password in a plaintext file.

This sounds like something we do not need and is perhaps better security-wise to not have it.

How can I keep this error from popping up in our system logs? Here is my krb5.conf if its useful:

banjer@myhost:~> cat /etc/krb5.conf
# This file managed by Puppet
#
[libdefaults]
        default_tkt_enctypes = RC4-HMAC DES-CBC-MD5 DES-CBC-CRC
        default_tgs_enctypes = RC4-HMAC DES-CBC-MD5 DES-CBC-CRC
        preferred_enctypes = RC4-HMAC DES-CBC-MD5 DES-CBC-CRC
        default_realm = FOO.EXAMPLE.COM
        dns_lookup_kdc = true
        clockskew = 300

[logging]
        default = SYSLOG:NOTICE:DAEMON
        kdc = FILE:/var/log/kdc.log
        kadmind = FILE:/var/log/kadmind.log

[appdefaults]
pam = {
        ticket_lifetime = 1d
        renew_lifetime = 1d
        forwardable = true
        proxiable = false
        retain_after_close = false
        minimum_uid = 0
        debug = false
        banner = "Enter your current"
}

Let me know if you need to see any other configs. Thanks.

EDIT

This message shows up in /var/log/secure whenever a non-root user logs in via SSH or the console. It seems to only occur with password-based authentication. If I do a key-based ssh to a server, I don't see the error. If I log in with root, I do not see the error. Our Linux servers authenticate against Active Directory, so its a hearty mix of PAM, samba, kerberos, and winbind that is used to authenticate a user.

Solution 1

To disable keytab validation and hence suppress these log messages, add the no_validate option to your PAM settings. For example:

auth        sufficient    pam_krb5.so use_first_pass no_validate

On my CentOS 6 servers, I made this change anywhere I saw pam_krb5.so being referenced in these two files:

/etc/pam.d/password-auth-ac
/etc/pam.d/system-auth-ac

I'm sure SLES is similar, but we're phasing that OS out, so I don't plan on testing it there.

Solution 2

If you don't have a keytab on the host, you really aren't using Kerberos properly and are wide open to a relatively simple attack if the attacker can poison your DNS caches.

Kerberos is a shared secret system and to work effectively any server that accepts Kerberos tickets needs to have a local copy of the shared secret that the Kerberos Key Distribution Center (KDC) also has. This is what a keytab is, a local copy of the shared secret for that service.

A keytab can also be used as a cache for obtaining Kerberos Ticket-Granting-Tickets (TGTs), but that is for when you want your host to act as a client for a Kerberos server, not as a server.

pam_krb5 uses the keytab to verify that the password typed is the actual password in the KDC. If you don't have a keytab to allow this, then all you're verifying is that some machine somewhere responded to a Kerberos protocol request.

Solution 3

This might be an old one, but I had the same problem and wanted to get rid of the message. I followed these instructions from ArchLinux and solved it.

https://wiki.archlinux.org/index.php/Active_Directory_Integration#Creating_a_machine_key_tab_file

Just typed in this:

net ads keytab create -U administrator

It might depend on your setup, though.

Solution 4

You can disable validation to avoid the message in the log as suggested by Banjer, but the purpose of the validation step is to prevent an attack where a bad guy sets up their own bogus KDC. In other words you need a host principal to validate the TGT given by the KDC is authentic.

View more solutions

Comments

[chutz]

Does this happen when you restart sshd or when you try to login over ssh? Do you also see the message when you log in from the console?

[Ryan]

The first sentence is plain wrong. The host doesn't obtain a TGT. The user obtains a TGT. Also a TGT isn't used for preauth. Instead, preauthentication may be required in order to obtain a TGT. See kerberos.org/software/tutorial.html

[jap1968]

In my case (RHEL 6.10 authenticating with a corporate AD server) I had to change just one line in the file /etc/pam.d/password-auth-ac: auth sufficient pam_krb5.so use_first_pass no_validate