If that is the case, why am I entering that code section when reading
keys from LDAP? Maybe it is not the intention, but
sss_ssh_authorizedkeys.c uses that section.
Franky
On Fri, 13 Jul 2012 17:22:18 +0200
Jan Cholasta <jcholast(a)redhat.com> wrote:
This code is for writing public keys, not for reading them from
LDAP.
Dne 13.7.2012 17:18, Franky Van Liedekerke napsal(a):
> 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
>> name> 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(a)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(a)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@default
>>>>
>>>> Also, fixing algo_len to "7" seemed to have an effect, but
>>>> resulted in another output:
>>>> dss AAA c3NoXXXXXXXXX MYUSER@default
>>>>
>>>>
>>>> So, there seems something wrong here, but I can't figure it out.
>>>> Any tips?
>>>>
>>>> Franky
>>>> _______________________________________________
>>>> sssd-devel mailing list
>>>> sssd-devel(a)lists.fedorahosted.org
>>>>
https://fedorahosted.org/mailman/listinfo/sssd-devel
>>>
>>> _______________________________________________
>>> sssd-devel mailing list
>>> sssd-devel(a)lists.fedorahosted.org
>>>
https://fedorahosted.org/mailman/listinfo/sssd-devel
>
> _______________________________________________
> sssd-devel mailing list
> sssd-devel(a)lists.fedorahosted.org
>
https://fedorahosted.org/mailman/listinfo/sssd-devel