On Thu, Aug 20, 2015 at 12:40:07PM +0200, Davor Vusir wrote:
Hi!
We store our public ssh keys in AD user account (altSecurityIdentities). Red Hat release 6.6/sssd 1.11.6. Adding
~~~~~~~~~~~~~~~ 6.7 is out for some time with quite some enhancements.
subdomains_provider = none
Why would you expect disabling subdomains provider to have any effect on public keys retrieval?
alone ends in not being able to get the public key but are asked for our AD user accounts password. Adding
ldap_groups_use_matching_rule_in_chain = True ldap_initgroups_use_matching_rule_in_chain = True
makes the logon time so long that it seems that SSSD forgets the content of the attribute altSecurityIdentities and we are asked for our AD user accounts password.
So why do you add them?
In general, neither subdomains_provider nor the matching rules have anything to do with SSH keys whatsoever.
But logging on immediatly again we are asked for public key verification.
You're asked for verification of /user/ keys?
Red Hat release 7.1/sssd 1.12.2. . Adding
subdomains_provider = none
alone ends in not being able to get the public key but are asked for our AD user accounts password. Adding
ldap_groups_use_matching_rule_in_chain = True ldap_initgroups_use_matching_rule_in_chain = True
gives the same result. AD user accounts password only. But not the extended logon time.
How come?
You didn't paste any logs or configuration, so it's hard to tell. But you should first make sure the backend is configured to point to your pubkey attribute with ldap_user_ssh_public_key, then see if sshd is contacting the ssh responder and if the ssh responder is retrieving the keys from cache.
btw pubkey integration with AD is not something we test, so there might be dragons..