On Tue, 2011-11-08 at 17:57 -0500, Dmitri Pal wrote:
> On 11/08/2011 02:56 PM, Dan Scott wrote:
> > 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?
> When we start to support Cross Realm Kerberos Trusts for IPA to IPA I
> think this would be doable but then I do not think the ssh host keys
> will be used (needed). Simo, am I correct?

We do not have the GSSAPI key exchange patches in OpenSSH. With those
the ssh host key is not necessary when using GSSAPI auth, even in the
same realm.

But when you want to use ssh host keys, across realm kerberos trust is
not going to help.

In order to validate keys from different realms I guess we could use
DNSSEC where the signatures of one realm are trusted by the other.
Then by storing ssh host keys as DNS fields a different domain could
still trust those keys. This works only for enrolled hosts though, I
guess. Or at least only for hosts in DNS domains that are controlled by
IPA. For hosts in other DNS domains we cannot distribute keys through
If that is necessary then we would have to define some sort of protocol
to allow fetching of keys from one domain to the other.
We could use a mechanism similar to what we will need to implement for
sid2name resolution for windows domain trusts. Where the IPA server
becomes a proxy to request host keys from other domains.

Bottom line, we can come up with something but it is not scoped yet. And
needs some more thinking so that we put in place something that scales


Simo Sorce * Red Hat, Inc * New York

Freeipa-users mailing list

Reply via email to