On Tue, 2011-11-08 at 20:45 -0500, Dan Scott wrote:
> On Tue, Nov 8, 2011 at 18:35, Simo Sorce <s...@redhat.com> wrote:
> > 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.
> I don't quite understand this. What trust is required, other than the
> cross-realm authentication of kerberos tickets? Surely each realm
> would manage its own host keys. All I'm looking for is an
> authenticated cross-realm key lookup so that my client can pre-cache
> entries in the known_hosts file. Wouldn't this just be an LDAP lookup?
Well in 2-way trusts you could do that. But in general you do not want
to have any client in realm1 to contact any server in realm2. They might
be geographically very far and use high latency/low bandwidth links.
So, for a first implementation, we could do what you say, but I rather
think it through and see how to cache/transfer information making
clients go through their IPA server rather than trying to connect
directly to a remote one.
Simo Sorce * Red Hat, Inc * New York
Freeipa-devel mailing list