ssh authorized_keys and known_hosts

Scott Moser smoser at
Tue Oct 18 15:47:10 UTC 2011

On Tue, 18 Oct 2011, Dustin Kirkland wrote:

> On Tue, Oct 18, 2011 at 4:26 AM, William Reade
> <william.reade at> wrote:
> > Hi all

> Have a look at the implementation here:
>  *
> > 1) Juju should generate and store an environment-specific SSH key when
> > it bootstraps, and should always authorise that key, and use it whenever
> > it connects (either when tunnelling to ZK, or when just 'juju ssh'ing).
> +1, and those should be per-machine unique too.  Having discussed this
> with Kees, Jamie, and Marc on the Security team, I think it best to do
> the 2-key generation described above.  Locally and securely generate

I admit to not knowing what juju does, but I +1 Dustin's suggestion.
There should be 1 set of keys that my system uses to authenticate to
zookeeper with, and one set of keys that the juju node uses to
authenticate to other systems.  Keys are supposed to be

Since I already have ssh keys on my system that are password protected, and
already have those loaded into my ssh-agent, I'd hope you can re-use those
for local-system -> zookeeper.  It would *not* be an improvement to
generate a new set of passwordless keys and use them.

> two host keys, install both to a separate, known_hosts.juju file.
> Install the first key on the system via metadata/cloud-init.  Replace
> that key as soon as possible with the second key, transmitted over
> ssh.  Oh, and prune the fingerprints when you're done with them (ie,
> when you destroy the environment).

The benefit that JuJu has here is that they have a place where the
instance can post its keys to.  Your solution works well, but the 2 sets
of keys are not necessary if the instance itself can post its public keys

Ie, if the EC2 console wasn't 4 minutes behind, then you'd never have gone
down that path.  You would have just scraped the public keys from the
console (an out-of-band encrypted channel) and populated your known hosts
from that.

>  - This is a more secure solution for several reasons.  For one thing,
> the fingerprints are in fact *validated*, even though you're not just
> typing 'yes' (which, unless you look at ec2-get-console, you're just
> doing blindly).  Moreover, your local physical machine has more
> entropy and therefore keys you generate there are more secure than
> ones that some cloud instances (which is nearly identical to a million
> other cloud instances) generates.

I don't think you have any actual data that indicates entropy on instances
in a cloud is any less secure than on our local system.  Generally I think
people suspect that on-boot key generation could be less secure than done
elsewhere, but there have not been any attacks or actual data posted that
I know of (admittedly I haven't gone looking).

More information about the Juju mailing list