<html>
<head>
<meta content="text/html; charset=UTF-8" http-equiv="Content-Type">
</head>
<body bgcolor="#FFFFFF" text="#000000">
On 06/05/2012 04:38 PM, Jérôme Fenal wrote:
<blockquote
cite="mid:CABHQyQQ1jAbkbHFTDS7wLZCrJwYKT6QRe8dY9FUQC3N+y7wmVw@mail.gmail.com"
type="cite">2012/6/5 Sigbjorn Lie <span dir="ltr"><<a
moz-do-not-send="true" href="mailto:sigbjorn@nixtra.com"
target="_blank">sigbjorn@nixtra.com</a>></span><br>
<div class="gmail_quote">
<blockquote class="gmail_quote" style="margin:0 0 0
.8ex;border-left:1px #ccc solid;padding-left:1ex">
<div class="HOEnZb">
<div class="h5"><br>
<br>
On Fri, June 1, 2012 15:24, Simo Sorce wrote:<br>
> This is about Ticket 1978 (originally rhbz746036).<br>
><br>
><br>
> This RFE asks for storing private SSH Host Keys in
FreeIPA.<br>
><br>
><br>
> We have been triaging this ticket today, and I have
to admit I am biased<br>
> toward simply closing down the ticket.<br>
><br>
> However we want to reach out community and interested
parties that<br>
> opened the tick to understand if there are reasons
strong enough to consider implementing it.<br>
><br>
> The reason I am against this is that in FreeIPA we
already provide<br>
> public Key integration. This means that when the host
is re-installed new keys are loaded in IPA<br>
> and clients do not get the obnoxious warning message
that keys have changed, because enrolled<br>
> clients (with the appropriate integration bits) trust
FreeIPA so they do not need to ask the user<br>
> to confirm on a key change.<br>
><br>
> Storing Private Keys poses various liability issues,
in order to be able<br>
> to restore keys you need to give access to those keys
to an admin, as there is no other way to<br>
> authenticate just the host itself (it was just blown
away and reinstalled). This means any admin<br>
> account that can perform reinstalls need to have
access to *read* private keys out of LDAP, which<br>
> means that A) The central tenet of Asymetric
authentication is that private keys<br>
> are 'private'. B) keys are readable from LDAP to some
accounts, any slight error in<br>
> ACIs would risk exposing all private keys.<br>
> C) most probably low level (junior admin) accounts
will have read access<br>
> to pretty much all private keys, because those admins
are the one tasked with re-installs. However<br>
> those admins are also the ones less trusted, yet by
giving them access to private keys they are<br>
> enabled to perform MITM attacks against pretty much
any of the machines managed by FreeIPA.<br>
><br>
><br>
> For these reasons I am against storing SSH Private
Keys. I would like to<br>
> know what are the reasons to instead implement this
feature and the security considerations around<br>
> those reasons.<br>
>> From my point of view the balance between feature
vs security issues<br>
>><br>
> trips in disfavor of implementing the feature but I
am willing to be convinced otherwise if there<br>
> are good reasons to, and security issues can be
properly addressed with some clever scheme.<br>
><br>
<br>
<br>
</div>
</div>
I think there has been some confusion here. What I was looking
for was a way to prevent the users<br>
from receiving a message when ssh'ing into a host that's been
reinstalled, that the host's key has<br>
changed.<br>
<br>
I believe will become availabe in the future version IPA 2.2 /
RHEL 6.3?<br>
</blockquote>
<div><br>
So what you're looking for is an automatic deployment of
known_hosts in a centralised way (/etc/ssh) each time a new
machine is deployed in an IPA domain ?<br>
</div>
</div>
<br>
</blockquote>
<br>
No, I would like not having to update the existing known_hosts when
a host is re-installed. <br>
<br>
<br>
Rgds,<br>
Siggi<br>
<br>
</body>
</html>