4

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?
2
  • Do you have a valid ticket? Check klist Mar 18, 2014 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. Mar 18, 2014 at 12:52

4 Answers 4

5

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/[email protected] (AES-256 CTS mode with 96-bit SHA-1 HMAC)

# look at the new keytab
$ klist -ek <new keytab>
KVNO Principal
---- --------------------------------------------------------------------------
   2 host/[email protected] (AES-256 CTS mode with 96-bit SHA-1 HMAC)
4
  • 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?' Apr 2, 2014 at 21:15
  • issue was resolved. i had a messed up sshd_config. still dont know how to make kadmin work though. Apr 6, 2014 at 4:58
  • 2
    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. Apr 6, 2014 at 18:32
  • 1
    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. Apr 14, 2014 at 17:25
1

I also resolved this problem. because ccache contained a old key for the IPA server from the previous installation just need delete /var/lib/sss/db/ccache_* file

more detail in ticket: https://fedorahosted.org/sssd/ticket/2781

1

Occasionally IPA clients arent able to retrieve update host keytabs before expiry for reasons such as DNS or network connectivity. Because of this a manual update of the keytab may be necessary to get the server back into sync with IPA.

On the client, login with kinit to get a kerberos ticket-granting-ticket for a user on the KDC with privileged access to get a new host keytab (admin will work)

kinit admin

Update the keytab for the host from the KDC where

  • ipahostname.mydomain.com is the fully qualified domain name of the IPA server
  • host/[email protected] is the service principal for the host ipahostname.mydomain.com in the mydomain.com realm
  • /etc/krb5.keytab is the location of the system keytab being used. This path is the default for many installations.
ipa-getkeytab -s ipahostname.mydomain.com -p host/[email protected] -k /etc/krb5.keytab

Once completed successfully - restart SSSd for it to start using the new keytab

systemctl restart sssd
5
  • 2
    Explain what this is supposed to do.
    – Sven
    Nov 27, 2018 at 15:12
  • kinit admin is for login into the kerberos realm as admin so you can execute the next statement. the ip-getkeytab will get the last keytab from ipaserver. And you have to reset sssd daemon to enable the change.
    – wyzeman
    Nov 27, 2018 at 18:54
  • ran into an issue that removing keytab and restart sssd does'nt work as I cannot login into kerberos realm with kinit admin. Just ran systemctl restart krb5kdc have fix the bug.
    – wyzeman
    Jan 10, 2020 at 13:48
  • 1
    Not sure why this was downvoted as this was my exact fix for an IPA server with an expired keytab causing preauth fails with sssd. Thanks @wyzeman
    – IT_User
    Sep 2, 2020 at 15:31
  • 1
    Agreed with @IT_User, this answer saved my butt. I didn't need to restart SSSD, but I renewed a keytab to /tmp, made sure it was valid, then moved it to /etc/krb5.keytab and my keytab preauth issues went away!!!
    – Neurax
    Mar 11, 2021 at 1:50
-2

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

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.

Regards.

You must log in to answer this question.

Not the answer you're looking for? Browse other questions tagged .