[Freeipa-devel] About private ssh host keys in IPA

Stephen Gallagher sgallagh at redhat.com
Fri Jun 1 13:34:38 UTC 2012


On Fri, 2012-06-01 at 09:24 -0400, Simo Sorce wrote:
> This is about Ticket 1978 (originally rhbz746036).
> 
> This RFE asks for storing private SSH Host Keys in FreeIPA.
> 
> We have been triaging this ticket today, and I have to admit I am biased
> toward simply closing down the ticket.
> 
> However we want to reach out community and interested parties that
> opened the tick to understand if there are reasons strong enough to
> consider implementing it.
> 
> The reason I am against this is that in FreeIPA we already provide
> public Key integration. This means that when the host is re-installed
> new keys are loaded in IPA and clients do not get the obnoxious warning
> message that keys have changed, because enrolled clients (with the
> appropriate integration bits) trust FreeIPA so they do not need to ask
> the user to confirm on a key change.
> 
> Storing Private Keys poses various liability issues, in order to be able
> to restore keys you need to give access to those keys to an admin, as
> there is no other way to authenticate just the host itself (it was just
> blown away and reinstalled).
> This means any admin account that can perform reinstalls need to have
> access to *read* private keys out of LDAP, which means that
> A) The central tenet of Asymetric authentication is that private keys
> are 'private'.
> B) keys are readable from LDAP to some accounts, any slight error in
> ACIs would risk exposing all private keys.
> C) most probably low level (junior admin) accounts will have read access
> to pretty much all private keys, because those admins are the one tasked
> with re-installs. However those admins are also the ones less trusted,
> yet by giving them access to private keys they are enabled to perform
> MITM attacks against pretty much any of the machines managed by FreeIPA.
> 
> For these reasons I am against storing SSH Private Keys. I would like to
> know what are the reasons to instead implement this feature and the
> security considerations around those reasons.
> >From my point of view the balance between feature vs security issues
> trips in disfavor of implementing the feature but I am willing to be
> convinced otherwise if there are good reasons to, and security issues
> can be properly addressed with some clever scheme.


For the record, I am also in favor of just closing the ticket. It's much
safer and wiser to require re-provisioning of the public key in the
FreeIPA server than it is to try storing the private key. I suspect that
when we had the original conversation on IRC, it was before we had
decided that FreeIPA would be managing public keys. I am firmly against
ever storing host private keys in a central location.
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 198 bytes
Desc: This is a digitally signed message part
URL: <http://listman.redhat.com/archives/freeipa-devel/attachments/20120601/ee9afc78/attachment.sig>


More information about the Freeipa-devel mailing list