Take the 2-minute tour ×
Server Fault is a question and answer site for professional system and network administrators. It's 100% free, no registration required.

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.

share|improve this question
    
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? –  chutz Nov 8 '12 at 14:33
    
@chutz I added some further info to my question. –  Banjer Nov 8 '12 at 15:28

4 Answers 4

As @ryan-fisher mentioned in his reply, the host needs a keytab file in order for it to be able to retrieve a TGT for preauth.

The reason the message isn't seen for root is because that user is local (does not need Kerberos for authentication). When using SSH authorized-keys, you also circumvent Kerberos, so there will be no error regaring missing keytab there either.

Now, what you need to do is to make sure that /etc/krb5.keytab contains the keys for the principal host/domain.name.of.host for the machine. Assuming the reverse DNS is correctly set up, you will then be able to log in using ssh without typing a password assuming you have a valid TGT.

share|improve this answer
    
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 –  Ryan Apr 22 at 20:45
up vote 1 down vote accepted

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.

share|improve this answer

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.

share|improve this answer

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 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 TGT's, but that is for when you want your host to act as a client for a kerberized 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.

share|improve this answer

Your Answer

 
discard

By posting your answer, you agree to the privacy policy and terms of service.

Not the answer you're looking for? Browse other questions tagged or ask your own question.