Dne 4.2.2012 11:05, Jakub Hrozek napsal(a):
On Fri, Feb 03, 2012 at 11:29:52PM +0100, Jan Cholasta wrote:
> Hi,
>
> this is a set of patches implementing SSH support in SSSD.
>
> To test it, install a SSH-patched (patches are on freeipa-devel) IPA
> server, create a test user with SSH public keys ("ipa user-add
> someuser --sshpubkey=<blob>"), and then use the
> sss_ssh_authorizedkeys command to get the user's SSH public keys
> ("sss_ssh_authorizedkeys someuser" should output user's public keys
> in OpenSSH's authorized_keys format).
>
Is there a way to test these using an actual SSH client yet?
Set AuthorizedKeysCommand option in your sshd_config to
"<path>/sss_ssh_authorizedkeys".
> This is not a complete set of patches for SSH support, some work is
> still missing and will be posted soon (SSH host keys support in IPA
> provider, known_hosts client and documentation).
>
Also please remember to add the new options to the ConfigAPI.
OK, will do.
> [PATCH 1/9] UTIL: Provide base64 encoding and decoding functions
>
Can you add a DEBUG() message saying that sss_base64_{encode,decode} are
not implemented with libcrypto back end?
Sure.
I think the NSS back end sss_base64_{encode,decode} should call
nspr_nss_init() otherwise they are just relying on the NSS crypto
library being initialized.
OK.
> [PATCH 2/9] BUILD: Introduce a --with-ssh config option
>
ACK to the code, but this patch will likely need a rebase on top of the
similar sudo/autofs patches.
Yes, I expect that.
> [PATCH 3/9] LDAP: Add support for SSH user public keys
>
This patch should be rebased on top of Stephen's cache timeout patch
that is already acked on the list.
OK.
I don'really like the "continue" special case in sdap_save_user(). Why
not simply move SDAP_AT_USER_SSH_PUBLIC_KEY before
SDAP_FIRST_EXTRA_USER_AT?
I guess I didn't want to add new attributes in the middle of the user
map. I can easily change that.
> [PATCH 4/9] DP: Add auxiliary info handler
> This is used to handle non-NSS accounts, such as hosts.
>
> [PATCH 5/9] IPA: Add auxiliary info handler
I'm not a big fan of the auxilary handler, to be honest. While it saves
a lot of code duplication, how do you define what falls into the
auxiliary category and what needs its own provider type?
I can see you concern. Would it be OK to make a handler just for host
info then?
The rest is TBR, I'll continue later.
Thanks.
>
> [PATCH 6/9] DP: Add support for hosts in sss_dp_get_account
> Host requests are directed to the auxiliary info handler.
>
> [PATCH 7/9] SSH: Responder
>
> [PATCH 8/9] SSH: Common client code
>
> [PATCH 9/9] SSH: AuthorizedKeysCommand client
>
> Honza
>
--
Jan Cholasta