On Tue, 2006-08-29 at 16:11 +0100, Mark McLoughlin wrote: > This doesn't make much sense to me. > > - If the server automatically signs the temporary certificates, then > what's stopping an attacker from having a temporary cert signed and > obtaining the client's SSH keys and puppet cert? If puppet knows about a cert for a given host, then it will not allow a connection with a cert (temporary or otherwise) other than the one the puppet server already knows about for the given host. The other aspect of this is preventing a bad guy with a valid cert for host A from accessing bits for host B. That's something David L. is working on with the fileserver config fixes. > Is it that puppet will only generate a single temporary cert for a > given hostname, so the attacker would have to get in before the > client? You can certainly generate more than one temporary cert -- for example you need a second one if you are re-imaging a client after its disk got wiped out by a can of pepsi. Of course in the reimaging case you have to get a sysadmin to explicitly allow conection with the temp cert, otherwise it would be unsecure from the kind of attack you're talking about above. > > - If the server doesn't automatically sign the temporary cert, but > rather a human is involved, then why is it only a temporary cert? Just an added layer of security. > The general problem here is that when a client is provisioned a human > must be involved in verifying and recording that the credentials cached > on the local disk do correspond to the client identity. > > If a human isn't involved in that process, then it's vulnerable to > attack, surely? A human is involved at the very beginning of the process to say "expect a connection with a temporary cert from host X, allow the connection" jeff