Hide Forgot
OpenSSH in RHEL supports centralized management of SSH user keys (https://bugzilla.redhat.com/show_bug.cgi?id=455350), but there is no support for centralized management of SSH host keys. In FreeIPA and SSSD there is ongoing work to support management of SSH public keys for both users and hosts (https://fedorahosted.org/freeipa/ticket/754, https://fedorahosted.org/sssd/ticket/610). Without support in OpenSSH, centralized management of SSH host keys cannot be fully implemented. There is a related feature request in upstream bugzilla: https://bugzilla.mindrot.org/show_bug.cgi?id=1777
I'd like to see this first in upstream, at least in Fedora. On the other hand, Miroslav Trmac suggested that FreeIPA could start managing the /etc/ssh/ssh_known_hosts file (either refreshing it, say, once per hour, or, if possible, refreshing it whenever a host key is changed) and this is possible today without changes to ssh
Updating known_hosts periodically is not very scalable approach. It could work well in a small domain, but in a large domain with thousands of users and computers the load on IPA servers would be enormous. However, there is one approach that could work without patching OpenSSH: using a custom ProxyCommand to acquire host keys for the SSH server from IPA before connecting to it, update known_hosts file and then estabilish the connection.
I'm not approving a solution that needs patching ssh and is not accepted in upstream. Setting devel NACK on Upstream. Steve, could you please clarify if there is any violation with our certifications? Is there any problem with the approach suggested by Jan? I mean the "custom ProxyCommand". What I like is that it does not touch ssh source code.
We should explore two directions: one that does not touch SSH and can be delivered pretty quickly but might have some roughness and then have a proper functionality accepted upstream and brought into RHEL in a later major version.
Since RHEL 6.3 External Beta has begun, and this bug remains unresolved, it has been rejected as it is not proposed as exception or blocker. Red Hat invites you to ask your support representative to propose this request, if appropriate and relevant, in the next release of Red Hat Enterprise Linux.