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