ssh authorized_keys and known_hosts

Scott Moser smoser at
Wed Oct 19 18:22:35 UTC 2011

On Wed, 19 Oct 2011, William Reade wrote:

> On Tue, 2011-10-18 at 11:47 -0400, Scott Moser wrote:
> >
> > 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.
> Noted; thanks for pointing this out. Is this a general objection to
> passwordless keys, or would they be a reasonable solution when
> pre-existing ones cannot be found?

passwordless keys are not deplorable, but you likely have some keys
available, and you likely have access to the public key portion of those
also by running:
   ssh-add -L

> > > 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
> > securely.
> Sadly, I'm pretty certain that (at the moment) we *can't* post them
> securely; I didn't examine the whole chain of interactions :-/. And it
> seemed like such a good idea at the time...

You can... heres a trick i came up with with some help from someone that I
don't remember, so I'll just fail to give them credit.  Anyway..

Getting a secret into an ec2 instance is not that hard. Especially if its
on that only has meaning once.  Just post it in in cloud-init.  That is
really the same thing that Dustin is doing.

Heres how we decided we could securely communicate instance-generated keys
with the help of key value store somewhere (which can be anonymous).

 - launch instance with:
   - secret: "foobar"
   - post-keys-location: some-server/RANDOMHASH
 - instance boots, creates public/private keys
 - instance posts keys to:
    That post looks like this:
       sh-dss AAAAB....f0= root at brickies
     checksum: 59aa4d11473e5722b5789d803703646b
 - The checksum is created by appending the secret (foobar) with the
   content and checksumming the result.
 - user checks some-server/RANDOMHASH/keys and verifies the checksum

At this point you have a secure communication channel with the launched
instance.  Only someone that knew the secret 'foobar' could spoof you.

You can re-generate keys if you'd like, but theres no real need to.  You
subsequently do not use that secret for anything.

It is vulerable to some brute for DOS on some-server by populating all
possible RANDOMHASH with garbage.

> Regardless, it's not going to work -- and anything we do in this space
> still has to solve the fundamental problem of getting secrets onto EC2
> instances securely. Given that, Dustin's two-key solution does strike me
> as a good way forward, for when we actually start work on this; does
> anyone disagree with this?

The two key solution works, I wont suggest it doesnt.  But it is not
necessary if you have a key/value store that you can stuff the keys into,
or a way that the instance can "call home" on boot.  Both of which I think
can be accomplished.


More information about the Juju mailing list