Hi,
This is a great feature. It feels like I'm always re-installing VMs
and having to remove old SSH keys and re-accept new ones.
One feature I'd like is to have this working cross-realm. We have 2
IPA realms here and it would be great if I could configure SSSD to
check the local realm if I'm SSHing to a local PC and to check the
other IPA server(s) if my SSH target is part of the other realm. Even
better if it could do this without explicit configuration.
Do you think it would be possible to do this securely?
Dan
On Tue, Nov 8, 2011 at 12:38, Jan Zelenı wrote:
> Hello everyone,
> there is a new effort in IPA and SSSD teams and that is SSH key integration in
> both parts of SSSD-IPA infrastructure. We've put together some basic plans and
> now we would 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:
> =
> * the known_hosts file becomes outdated as machines get new host keys (e.g.
> re-
> installed systems in virtualized environment)
> * the user accepts any host key of the remote host without validating its
> authenticity
>
>
> Solution:
> =
> Instead of checking stale known_hosts file, provide a dynamic mechanism to
> lookup and deliver the public ssh key of the remote host to the client and use
> it for validation of the remote host identity. The dynamic mechanism would
> imply that no action is needed from the user because the source of the
> retrieved key is trusted.
>
>
> Limitations:
>
> It is out of scope of this work to solve the problem in general. We propose a
> solution for following use case:
>
> Client host is a managed host meaning that it has SSSD installed and it is
> joined an IPA domain. It also has OpenSSH patched to interact with SSSD to get
> the information about the remote host
>
> Other UNIX machines or Windows machines as SSH clients are out of the scope of
> the current project. For the client hosts that can not be managed but can
> access IPA via the standard LDAP tools we will provide documentation on how to
> construct the content of the known_hosts file by querying LDAP server and
> saving the results.
>
> The remote host can be a managed (joined IPA domain via SSSD) or an unmanaged
> host. IPA server needs to provide a way to create entries for any managed and
> unmanaged hosts and store public keys for those hosts in that entries.
>
> What would change in IPA:
> =
> * external host would have entries with the possibility of storing their
> public keys
> * new mechanism to work with keys through UI and CLI
> * host key fingerprints would be stored in SSHFP DNS records for each host
> joined in IPA domain
>
> What would change on the client:
>
> * SSSD would fetch and cache host public keys from IPA
> * joining to IPA domain would upload host public key
> * ssh client would communicate with SSSD, probably through ssh-agent, to check
> if the remote host is known
>
> It is still a question whether the solution is sufficient enough to address
> the
> needs and pains of the real deployments or other technologies outside the
> proposed should be used later (or instead).
>
> --
> Thank you
> Jan Zeleny
>
> Red Hat Software Engineer
> Brno, Czech Republic
>
> ___
> Freeipa-users mailing list
> Freeipa-users@redhat.com
> https://www.redhat.com/mailman/listinfo/freeipa-users
>
___
Freeipa-users mailing list
Freeipa-users@redhat.com
https://www.redhat.com/mailman/listinfo/freeipa-users
