[SSSD] bug in sss_ssh_authorizedkeys

Franky Van Liedekerke liedekef at telenet.be
Fri Jul 13 15:18:05 UTC 2012


That seems weird to me, as the code clearly specifies

"case SSS_SSH_FORMAT_RAW:"
and
"case SSS_SSH_FORMAT_OPENSSH:"

in src/util/sss_ssh.c
And everywhere else SSS_SSH_FORMAT_OPENSSH is used as the format 
(doesn't seem to be possible to change this via an option).
So imho the code does support it just fine (as I've proven with my 
little patch), but has been incorrectly adapted to work for base64 
encoded keys while the format stays SSS_SSH_FORMAT_OPENSSH.
My guess is: the format should be made configurable and then for 
openssh just return what's in ldap ...

Franky

On 2012-07-13 16:55, Jan Cholasta wrote:
> Hi,
>
> you have the public keys in LDAP in wrong format. SSSD SSH support is
> currently limited only to IPA, which stores only the raw public key
> blob (see RFC 4253 section 6.6), as opposed to OpenSSH-LPK, which
> stores public keys in OpenSSH format ("[options] <public key 
> algorithm
> name> <base-64 encoded raw public key blob> [comment]", see sshd(8)).
>
> So, you can either have public keys in LDAP in IPA format (you can
> set them using "ipa user-mod" and "ipa host-mod" commands) and use
> SSSD to provide the OpenSSH-LDAP link, or you can have public keys in
> LDAP in OpenSSH format and use ssh-ldap-wrapper to provide the
> OpenSSH-LDAP link. Anything else is not supported ATM.
>
> Honza
>
> Dne 13.7.2012 15:25, liedekef at telenet.be napsal(a):
>> Btw,
>>
>> I managed to get things working by making sure the function
>> "sss_ssh_format_pubkey" just returns the value of the found public 
>> key,
>> not base64 encoded (which it should not be for openssh formatted 
>> keys).
>> So there the "return pubkey->data" statement worked just fine, 
>> skipping
>> the whole sss_ssh_get_pubkey_algorithm logic and all. I wonder why 
>> the
>> pubkey algoritm should be searched for anyway, ssh is capable of
>> interpreting this all by itself.
>>
>> Franky
>>
>> On 2012-07-13 15:10, liedekef at telenet.be wrote:
>>> Hi,
>>>
>>> I'm trying to use the experimental feature "sss_ssh_authorizedkeys"
>>> on a up-to-date fedora 17. Now it seems everytime I call that 
>>> binary,
>>> it returns the non-descriptive error "Not enough memory".
>>> Using my basic C-skills, I downloaded the latest SSSD sources 
>>> (1.8.4)
>>> and recompiled them myself: the result was the same.
>>> Adding some print-statements, I stumbled upon this function
>>> sss_ssh_get_pubkey_algorithm in src/util/sss_ssh.c:
>>>
>>> char *
>>> sss_ssh_get_pubkey_algorithm(TALLOC_CTX *mem_ctx,
>>>                              struct sss_ssh_pubkey *pubkey)
>>> {
>>>     size_t c = 0;
>>>     uint32_t algo_len;
>>>     char *algo;
>>>
>>>     SAFEALIGN_COPY_UINT32(&algo_len, pubkey->data, &c);
>>>     algo_len = ntohl(algo_len);
>>>
>>>     algo = talloc_zero_array(mem_ctx, char, algo_len+1);
>>>     if (!algo) {
>>>         return NULL;
>>>     }
>>>
>>>     memcpy(algo, pubkey->data+c, algo_len);
>>>
>>>     return algo;
>>> }
>>>
>>>
>>> ==> it seems I always end up in the "return NULL" statement, which
>>> seems very weird to me. Current SSH setups can get their authorized
>>> keys from LDAP just fine (using "AuthorizedKeysCommand
>>> /usr/libexec/openssh/ssh-ldap-wrapper" in sshd_config), so my keys 
>>> are
>>> just fine in LDAP.
>>> I believe the call to SAFEALIGN_COPY_UINT32 is either wrong or has
>>> the wrong arguments, since algo_len is a bizare huge number ...
>>> Trying to change the
>>>    return NULL
>>> in
>>>    return "ssh-dss
>>> resulted in better effects (but still my key wasn't being accepted,
>>> maybe another issue). The result (a bit obfuscated):
>>>
>>> ./sss_ssh_authorizedkeys MYUSER
>>> ssh-dss c3NoXXXXXXXXX MYUSER at default
>>>
>>> Also, fixing algo_len to "7" seemed to have an effect, but resulted
>>> in another output:
>>> dss AAA c3NoXXXXXXXXX MYUSER at default
>>>
>>>
>>> So, there seems something wrong here, but I can't figure it out. 
>>> Any
>>> tips?
>>>
>>> Franky
>>> _______________________________________________
>>> sssd-devel mailing list
>>> sssd-devel at lists.fedorahosted.org
>>> https://fedorahosted.org/mailman/listinfo/sssd-devel
>>
>> _______________________________________________
>> sssd-devel mailing list
>> sssd-devel at lists.fedorahosted.org
>> https://fedorahosted.org/mailman/listinfo/sssd-devel




More information about the sssd-devel mailing list