Server Fault is a question and answer site for system and network administrators. Join them; it only takes a minute:

Sign up
Here's how it works:
  1. Anybody can ask a question
  2. Anybody can answer
  3. The best answers are voted up and rise to the top

I followed the standard documentation to install FreeIPA server and client on hosts 'SRV' and 'CLT' respectively. I then added a user 'X' to FreeIPA using Web UI. Now when i try to SSH as X to CLT, i get a 'Permission denied, please try again.' error. I check '/var/log/messages' on the client, and saw this - '[sssd[krb5_child[3277]]]: Decrypt integrity check failed'.

I reset the password multiple times, but that didn't solve the problem. Then I came across these -

Sounds like removing the '/etc/krb5.keytab' file from SRV and CLT and then recreating them will solve the problem.

  1. How should I go about doing this keytab reset?
  2. Should I first un-provision/remove CLT from FreeIPA inventory?
share|improve this question
Do you have a valid ticket? Check klist – Michael Hampton Mar 18 '14 at 12:48
Yes. And just to be sure, i ran 'kinit admin' and 'kinit X' commands again on SRV. Then verified valid tickets were present using 'klist' command on SRV and CLT. Then tried SSH again, got the same error. – Quest Monger Mar 18 '14 at 12:52
up vote 3 down vote accepted

Which SSH authentication method are you using? Are you typing in your password, or trying to use Kerberos ticket-based authentication (gssapi-with-mic or gssapi-keyex)?

The “decrypt integrity check failed” message could come from two sources. If you give it the wrong password (your password doesn’t match the keys for your principal in the KDC), you’d get that. You’d also get it if your password is fine, but the keytab on the server is out of date; this would happen with both ticket and password authentication (because with a password, the server obtains a ticket for its own host principal after doing kinit, to authenticate the KDC).

Sounds like removing the ’/etc/krb5.keytab’ file from SRV and CLT and then recreating them will solve the problem.

The keytab on the client is irrelevant; it’s not part of this scenario. The likely problem here is that the keytab on the server is out of sync with the KDC (the Kerberos authentication server, or "Key Distribution Center," which is part of FreeIPA). With Kerberos, all identities (or "principals") in the system have keys they share with the KDC. A user’s keys are generated from his password. The keys for a software service like sshd are randomly generated, and stored in a file called a keytab (for "key table") so the service can access them. This sounds like the keys for the SSH principal have been changed in the KDC, but the keytab hasn’t been updated to match. Your principal name is of the form user@REALM. The principal name for the SSH service is of the form host/hostname@REALM. Try:

$ ipa-getkeytab -s <FreeIPA server> -p host/<hostname>@REALM -k <keytab file>.

... to extract the current keys for the SSH service principal into a new keytab. You can use klist -ek <keytab> to view the contents of the old and new keytabs. If you have a key mismatch, it should show up as the keys for the same principal having different key version numbers (or “kvno”). You might see something like:

# look at the system keytab
$ sudo klist -ek
KVNO Principal
---- --------------------------------------------------------------------------
   1 host/ (AES-256 CTS mode with 96-bit SHA-1 HMAC)

# look at the new keytab
$ klist -ek <new keytab>
KVNO Principal
---- --------------------------------------------------------------------------
   2 host/ (AES-256 CTS mode with 96-bit SHA-1 HMAC)
share|improve this answer
I apologize for not responding earlier. I am using the password method to authenticate. I added a user account to FreeIPA inventory using their web interface. then added client. My entire IPA setup runs on one server. Which means DS, KDC, KPASSWD, MEMCACHE, HTTP, CA all run on one server(SRV). Keeping that in mind, i tried to run the above ipa-getkeytab command on the IPA server. it looked like this - ipa-getkeytab -s <SRV> -p host/<CLT>@<REALM> -k /etc/krb5.keytab i got this error message - 'Kerberos User Principal not found. Do you have a valid Credential Cache?' – Quest Monger Apr 2 '14 at 21:15
issue was resolved. i had a messed up sshd_config. still dont know how to make kadmin work though. – Quest Monger Apr 6 '14 at 4:58
You haven't mentioned kadmin before. Do you mean kadmin, or ipa-getkeytab? For the latter, it looks as if you need to kinit a principal authorized for IPA administrative access. – Richard E. Silverman Apr 6 '14 at 18:32
i got ipa-getkeytab to work. yes it required admin kinit. i was trying to use kadmin to reset the keytab. it didnt work. freeipa documentation could use a serious rewrite/redo. – Quest Monger Apr 14 '14 at 17:25

On client I deleted /etc/krb5.keytab On server I deleted host ipa host-del

I uninstall ipa client software.

I reinstall ipa client

BUT, the client doesnt work.

At Last, I had to restart ipa-server ipactl restart and ...

The client work fine. I suppose that the kdc server o similar had something in cache about client keys.


share|improve this answer

Your Answer


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.