On 2015-08-26 21:36, Lukas Slebodnik wrote:
On (26/08/15 13:09), Davor Vusir wrote:
> On 2015-08-25 20:25, Lukas Slebodnik wrote:
>> On (25/08/15 19:35), Davor Vusir wrote:
>>> Lukas Slebodnik skrev den 2015-08-25 11:51:
>>>> On (22/08/15 15:32), Davor Vusir wrote:
>>>>> Jakub Hrozek skrev den 2015-08-20 22:23:
>>>>>> quick top-post
>>>>>>
>>>>>> I'll be on vacacation starting tomorrow and the whole next
week. I hope
>>>>>> some of the other sssd developers can help you out.
>>>>>>
>>>>>> tl;dr the public key should be set in ldap_user_ssh_public_key
>>>>>>
>>>>> It is.
>>>>>
>>>>>> See
>>>>>>
https://jhrozek.wordpress.com/2015/08/19/performance-tuning-sssd-for-larg...
>>>>>> for some performance tips.
>>>>>>
>>>>> Thank you. The tips did make difference.
>>>>>
>>>>>> Sorry for being terse.
>>>>>>
>>>>> Not at all.
>>>>>
>>>>> But I'm really curious about the reasons behind SSSD failing to
retrieve the
>>>>> public key when deactivating subdomains_provider. In our case, as we
don't
>>>>> have subdomains but forest trusts which SSSD doesn't support,
we've got no
>>>>> reason having subdomains_provider activated to enumerate them (the
trusted
>>>>> forests). It would be interesting to know why forest trusts are
enumerated in
>>>>> the first place.
>>>>>
>>>> In previous mail, you provided log files from ssh responder, which just
tried
>>>> to look up cached ssh key in sssd cache
>>>> But we would need to see a different log file to confirm whether public
ssh key
>>>> was retrieved from LDAP/AD.
>>>>
>>>> Please:
>>>> * clear old log files and sssd cache
>>> rm /var/log/sssd/sssd_ad.example.org
>>>
>>>> * increase debug_level in domain section to 9
>>>> * restart sssd
>>> service sssd stop && rm -Rf /var/lib/sss/db/* && rm -Rf
/var/lib/sss/mc/* &&
>>> service sssd start
>>>
>>>> * call "getent passwd user_with_ssh_key_in_ad"
>>> myloginid:*:10051785:10000513:Davor Vusir:/home/myloginid:/bin/bash
>>>
>>>> * provide log files from domain section.
>>>>
>>> I guess that this is the part you are interested in:
>> exactly :-)
>>
>>> (Tue Aug 25 18:29:50 2015) [sssd[be[ad.example.org]]]
[sdap_get_primary_name]
>>> (0x0400): Processing object myLoginID
>>> (Tue Aug 25 18:29:50 2015) [sssd[be[ad.example.org]]] [sdap_save_user]
>>> (0x0400): Processing user myLoginID
>>> (Tue Aug 25 18:29:50 2015) [sssd[be[ad.example.org]]] [sdap_save_user]
>>> (0x2000): Adding originalDN [CN=Davor
>>> Vusir,OU=Admins,OU=CT,DC=ad,DC=example,DC=org] to attributes of [myLoginID].
>>> (Tue Aug 25 18:29:50 2015) [sssd[be[ad.example.org]]] [sdap_save_user]
>>> (0x0400): Adding original memberOf attributes to [myLoginID].
>>> (Tue Aug 25 18:29:50 2015) [sssd[be[ad.example.org]]]
>>> [sdap_attrs_add_ldap_attr] (0x2000): Adding original mod-Timestamp
>>> [20150817101423.0Z] to attributes of [myLoginID].
>>> (Tue Aug 25 18:29:50 2015) [sssd[be[ad.example.org]]] [sdap_save_user]
>>> (0x0400): Adding user principal [myLoginID(a)AD.EXAMPLE.ORG] to attributes of
>>> [myLoginID].
>>> ...
>>> (Tue Aug 25 18:29:50 2015) [sssd[be[ad.example.org]]]
>>> [sdap_attrs_add_ldap_attr] (0x2000): Adding sshPublicKey
[c3NoLXJzYSBaPUFaRjNOemFDMXljMkVBQUFBREFRQUJBQUFCQVFETEw0MTZHQzFaVFBzVXpjS01Zbm5QSjNaZG1xWUZLTDArQ05adTQyT0U4ZDZKNFlNR1I0YmcwWUpuVFhhRUI1NWRvazJMV2tBKzlka0R5SFFJSzVxVEk4N09rSzZERWxNSGpPVDhESWlvNVVBUGo3Y1BYNGs4TjJYM0VlaS9FM0o3c1pyeDM5bWtZOSsrNkJXRGJMa084VlJOejhFT2JhUVZEK3pUTy9HWUltTmpFWHhwMzVCd3BES2xEa21BdXVud21KK1RNU2RHWWVEaFp6N25Nd0dVTmh2YmloTkU1N3IrcDhXS2MxVExDQW1TN3IyTE9jNWZPaUp4QmVFRENrVHlvamRQWkl1dkZudzBkZ25UMkRuaFBZcXVNeGJSU0F1WVVhYVpVNUFVUWlPQW1HRGlKVG5IVjczYzY0N09xWnJjbktZSTJ1SEJ6R1BGZXA3dWJ6Q2Y=]
>>> to attributes of [myLoginID].
>> Ok, the correct ldapt attribute is stored as ssh public key into sssd cache for
that user.
>>
>>
>>> (Tue Aug 25 18:29:50 2015) [sssd[be[ad.example.org]]]
>>> [sdap_attrs_add_ldap_attr] (0x2000): authType is not available for
>>> [myLoginID].
>>> (Tue Aug 25 18:29:50 2015) [sssd[be[ad.example.org]]]
>>> [sdap_attrs_add_ldap_attr] (0x2000): Adding altSecurityIdentities
[c3NoLXJzYSBStUFStjNOemFDMXljMkVBQUFBREFRQUJBQUFCQVFETEw0MTZHQzFaVFBzVXpjS01Zbm5QSjNaZG1xWUZLTDArQ05adTQyT0U4ZDZKNFlNR1I0YmcwWUpuVFhhRUI1NWRvazJMV2tBKzlka0R5SFFJSzVxVEk4N09rSzZERWxNSGpPVDhESWlvNVVBUGo3Y1BYNGs4TjJYM0VlaS9FM0o3c1pyeDM5bWtZOSsrNkJXRGJMa084VlJOejhFT2JhUVZEK3pUTy9HWUltTmpFWHhwMzVCd3BES2xEa21BdXVud21KK1RNU2RHWWVEaFp6N25Nd0dVTmh2YmloTkU1N3IrcDhXS2MxVExDQW1TN3IyTE9jNWZPaUp4QmVFRENrVHlvamRQWkl1dkZudzBkZ25UMkRuaFBZcXVNeGJSU0F1WVVhYVpVNUFVUWlPQW1HRGlKVG5IVjczYzY0N09xWnJjbktZSTJ1SEJ6R1BGZXA3dWJ6Q2Y=]
>>> to attributes of [myLoginID].
>> This one is casued by following option
>> ldap_user_extra_attrs = altSecurityIdentities:altSecurityIdentities
>>
>> And should not have any effect to ssh <-> sssd integration.
> I realized that while going through the log. The attribute is unnecesseraly
> cached . Will remove.
>
>>> (Tue Aug 25 18:29:50 2015) [sssd[be[ad.example.org]]]
>>> [sysdb_attrs_get_aliases] (0x2000): Domain is case-insensitive; will add
>>> lowercased aliases
>>> (Tue Aug 25 18:29:50 2015) [sssd[be[ad.example.org]]] [sdap_save_user]
>>> (0x0400): Storing info for user myLoginID
>>>
>> Now you can test with command line utility sss_ssh_authorizedkeys
>> wheter ssh responder is correctly configured.
>> ("ssh" should be listed in option services; in sssd section)
>> If the public key is returned then you need to check
>> sshd configuration files for proper integration.
>>
>> @see more details in man sss_ssh_authorizedkeys
> [root@client-1 ~]# sss_ssh_authorizedkeys myLoginID
> ssh-rsa AAAAB3NzaC1yc2EAAAADAQABAA...
>
> [myLoginID@client-1 ~]# sss_ssh_authorizedkeys myLoginID
> ssh-rsa AAAAB3NzaC1yc2EAAAADAQABAA...
>
> Seems to work. But as soon as I put "subdomains_provider = none" either
sshd
> or sssd (I believe it's sssd) bypasses the ssh public key check. It
> recognizes that it should check for the password to unlock the private key,
> but doesn't care what I'm typing. It solely check for the kerberos password.
>
Does sss_ssh_authorizedkeys returns public key with "subdomains_provider =
none"?
Please try with empty cache.
Is this the correct procedure?
1.
Logged in as "nonPublicKeyUser" su-ing to root in one terminal:
[root@server-1 ~]# service sssd stop
Redirecting to /bin/systemctl stop sssd.service
[root@server-1 ~]# rm -f /var/log/sssd/sssd*
[root@server-1 ~]# vi /etc/sssd/sssd.conf
[root@server-1 ~]# service sssd stop && rm -Rf /var/lib/sss/db/* && rm
-Rf /var/lib/sss/mc/* && service sssd start
Redirecting to /bin/systemctl stop sssd.service
Redirecting to /bin/systemctl start sssd.service
[root@server-1 ~]#
2.
In another terminal from client-1:
PublicKeyUser@server-1 ~
$ ssh
server-1.subdomain.example.org
Enter passphrase for key '/home/PublicKeyUser/.ssh/id_rsa': <- No
password given. Just pressed <return>.
Password:
Last login: Wed Aug 26 12:56:21 2015 from
client-1.subdomain2.example.org
[PublicKeyUser@server-1 ~]$ sss_ssh_authorizedkeys PublicKeyUser
ssh-rsa AAAAB3NzaC1yc2EAAA...
[PublicKeyUser@server-1 ~]$ exit
3.
Back to the first terminal:
[root@server-1 ~]# service sssd stop && rm -Rf /var/lib/sss/db/* && rm
-Rf /var/lib/sss/mc/* && service sssd start
Redirecting to /bin/systemctl stop sssd.service
Redirecting to /bin/systemctl start sssd.service
[root@server-1 ~]# sss_ssh_authorizedkeys PublicKeyUser
ssh-rsa AAAAB3NzaC1yc2E...
[root@server-1 ~]#
> As soon as I comment out "subdomains_provider = none"
user accounts with
> public key uses this type of authentication only and user accounts with
> Kerberos password uses Kerberos authentication only. Which, of course, is the
> goal.
>
> I don't expect you to comment on the sshd_config but here are relevant parts
> of both sshd_config and sssd.conf. Both "ct-linuxuberadmins" and
> "ct-linuxservicesadmins" in sshd_config are AD-groups with corresponding
> sudoers-files.
>
> sssd.conf:
> [
domain/ad.example.org]
> debug_level = 6
> id_provider = ad
> auth_provider = ad
> access_provider = ad
> chpass_provider = ad
>
> subdomains_provider = none
> # subdomain_enumerate = none
> ignore_group_members = True
>
> enumerate = False
>
> ldap_page_size = 1000
> ldap_id_mapping = False
> ldap_purge_cache_timeout = 0
> ldap_user_ssh_public_key = altSecurityIdentities
> ldap_use_tokengroups = True
>
> dyndns_update = False
> dyndns_update_ptr = False
>
> cache_credentials = true
> krb5_store_password_if_offline = true
>
> sshd_config:
> PubkeyAuthentication yes
> PasswordAuthentication no
> PermitEmptyPasswords no
> ChallengeResponseAuthentication yes
>
> UsePAM yes
>
> Match Group ct-linuxuberadmins
> AuthorizedKeysCommand /bin/sss_ssh_authorizedkeys
> AuthorizedKeysCommandUser svcCTSSHDbind
>
> Match Group ct-linuxservicesadmins
> PubkeyAuthentication no
>
Maybe I'm wrong but you might miss some groups with disabled subdomain_provider.
Please try with empty cache
So sshd will not get to the section with AuthorizedKeysCommand.
After step 3 above:
[root@server-1 ~]# getent group ct-linuxuberadmins
ct-linuxuberadmins:*:10287220:
[root@server-1 ~]# service sssd stop && rm -Rf /var/lib/sss/db/* && rm
-Rf /var/lib/sss/mc/* && service sssd start
Redirecting to /bin/systemctl stop sssd.service
Redirecting to /bin/systemctl start sssd.service
[root@server-1 ~]# getent group ct-linuxservicesadmins
uuct-gg-linuxservicesadmins:*:10287637:
[root@server-1 ~]#
Regards
Davor
LS