freeipa

#7290 SSH public key authentication keeps working after keys are removed from ID view
Closed: duplicate Opened by plumbeo.

Closed: duplicate
Reopen Issue

Issue

I installed FreeIPA 4.5.0 on a CentOS 7.4 server and configured a trust between it and an AD domain server, using ID views in the the Default Trust View to override the users' loginShell and homeDirectory attributes sent to the ipa clients. Once configured, SSH authentication with a public key works even after the public key is removed.

Steps to Reproduce

  1. create a ID View on the Default Trust View and add a user override
  2. add an SSH public key to the user override
  3. login to a client, the password will not be requested
  4. remove the public key from the user override
  5. login to a client again, the password is not requested

Actual behavior

After I remove a key, either from the web GUI or the CLI, the user can still login with the old key.

Expected behavior

After removing a key the user shouldn't be able to login to the clients without using her password.

Version/Release/Distribution

ipa-server-4.5.0-21.el7.centos.2.2.x86_64
ipa-client-4.5.0-21.el7.centos.2.2.x86_64
389-ds-base-1.3.6.1-21.el7_4.x86_64
pki-ca-10.4.1-13.el7_4.noarch
krb5-server-1.15.1-8.el7.x86_64
sssd-1.15.2-50.el7_4.6.x86_64

freeipa-client-4.4.4-3ubuntu1
sssd-1.15.3-2ubuntu1

Additional info

'ipa idoverrideuser-show' on the server doesn't show the key attributes after I remove it, but I checked the output of 'sss_ssh_authorizedkeys username' on the clients and it looks like the server continues to serve the old key indefinitely.

Deleting the SSSD cache on the server and the clients doesn't remove the old key, nor it disappears if I remove and recreate the ID view. Replacing it with another key seems to work, the new key is sent instead of the old one.

I'll take a look on this (most likely) by the beginning of the next week.
I'd assign the bug to myself, but I don't have the rights to do so.

Metadata Update from @frenaud:
- Issue assigned to fidencio

Hi @fidencio
thank you for looking at this! I assigned you the issue as you kindly offered.

Sorry it took so long for me to test this.

Basically I kind of can reproduce the issue. Just after removing the SSH key from IPA I can still log in with the user, even after calling sss_cache -E ... which is exactly the expected behaviour otherwise authentication would fail in the offline case.

However, if I remove SSSD files (systemctl stop sssd; rm -rf /var/lib/sss/db/*; systemctl start sssd) I can't log in with the user anymore.

I'd like to ask the reporter whether they have followed the systemctl stop sssd; rm -rf /var/lib/sss/db/*; systemctl start sssd steps and also ask for sanitized SSSD logs with debug_level = 9 (keep in mind you'll have to restart SSSD after changing sssd.conf) in case they can log in with the user even after removing SSSD files and restart SSSD.

So far, I'm not cloning this bug to SSSD.
Edited by fidencio

Just talked with @sbose on #sssd channel and he said (about the behaviour being the expected one):
"14:20 fidencio, yes, but as soon as the entry and the overrides are re-read it should fail because the ssh-key should be removed from the cache. During PAM based authentication the entry is already refreshed before authentication. But sshd does not talk to SSSD during ssh-key authentication, the entry on only updated during the access control phase (PAM_SCCT_MGMT) but this happens after authentication. Maybe we should add a uncondition user refresh to the ssh responder if keys are looked up for a user as we do in the PAM responder?"

So, based on @sbose's thoughts I'm opening a new bug against SSSD in order to have it implemented.

Please, I'd like to still hear back from the reporter about removing SSSD's cache files.

Sorry it took so long for me to test this.
Basically I kind of can reproduce the issue. Just after removing the SSH key from IPA I can still log in with the user, even after calling sss_cache -E ... which is exactly the expected behaviour otherwise authentication would fail in the offline case.
However, if I remove SSSD files (systemctl stop sssd; rm -rf /var/lib/sss/db/; systemctl start sssd) I can't log in with the user anymore.
I'd like to ask the reporter whether they have followed the systemctl stop sssd; rm -rf /var/lib/sss/db/; systemctl start sssd steps and also ask for sanitized SSSD logs with debug_level = 9 (keep in mind you'll have to restart SSSD after changing sssd.conf) in case they can log in with the user even after removing SSSD files and restart SSSD.
So far, I'm not cloning this bug to SSSD.

Ah, one important info, the SSSD cache has to be deleted on IPA master side, not on the client side.

I have opened the issues https://pagure.io/SSSD/sssd/issue/3602 and https://pagure.io/SSSD/sssd/issue/3603 for SSSD and I strongly suggest the reporter to add himself as a watcher of those issues.

I'd like to suggest closing this one as this issue was "cloned" to SSSD as https://pagure.io/SSSD/sssd/issue/3602 and will be solved there.

Sorry, i couldn't do more tests till today. I can confirm that removing the SSSD files manually on the FreeIPA server, instead of using sss_cache -E, results in the expected behaviour, that is the users can't login using their SSH public keys any more.

I'm closing this issue and adding myself to SSSD issue 3602, thank you.

Metadata Update from @plumbeo:
- Issue close_status updated to: duplicate
- Issue status updated to: Closed (was: Open)
Metadata
None
None
None
None
Static archive. pagure.io was sunset in 2026; this is a read-only snapshot.
Red Hat Logo

Fedora is sponsored by Red Hat. Learn more about the relationship between Red Hat and Fedora »

© Red Hat, Inc. and others.