[Freeipa-users] OpenSSH integration - authorized_keys

Jan Zelený jzeleny at redhat.com
Tue Nov 8 17:39:27 UTC 2011


Hello everyone,
this is a follow-up on the email on OpenSSH integration - known_host. It 
describes another scenario we want to address in the process of integrating 
OpenSSH to SSSD-IPA infrastructure - user public keys and their central 
management. As in the previous email, we would also like to know your opinion.

Note that this is just shortened version to make it easier to read. It doesn't 
contain every bit of information about the design. For full version see 
https://fedorahosted.org/freeipa/wiki/SSH-FreeIPA-Integration


Problems:
=========
* how to distribute keys for new users / regenerated keys through the domain. 
The authorized_keys is probably not an option, we also want to cover use case 
when home directories are remote and not mounted on the server.
* user may want to log on to the remote server using different account. We need 
to determine if he is allowed to impersonate that account


Solution:
=========
Similarly to openssh-lpk, the solution is to centrally manage and store user 
public keys in the IPA server and deliver them to the host for validation when 
user accesses that host.

In the central server provide a way to define which account can do 
impersonation of which other accounts. Optionally add a way to represent 
special service accounts that are not full user accounts but can be logged as 
via ssh (stretch goal).
    
    
What would change on IPA:
=========================
* user entry will have additional multi-valued attribute for storing public 
keys. Unlike in openssh-lpk, this attribute will store what keys the user has, 
not who can impersonate him.
* user entry would also have a multi-valued attribute containg DNs of users he 
can impersonate
* new mechanisms to work with account public keys and impersonation via UI and 
CLI
* HBAC rules would be extended to cover impersonation
* provide an LDAP  control to get a list of ssh keys that correspond to 
accounts that can impersonate a particular account in one operation.


On the client side:
===================
* SSSD would fetch (and cache?) user public keys from IPA
* new SSSD client would fetch user public keys from SSSD
* use SSH agent feature to get user public key from an output of the SSSD 
client


-- 
Thank you
Jan Zeleny

Red Hat Software Engineer
Brno, Czech Republic
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 836 bytes
Desc: This is a digitally signed message part.
URL: <http://listman.redhat.com/archives/freeipa-users/attachments/20111108/724368c1/attachment.sig>


More information about the Freeipa-users mailing list