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..