SSH keys

[Aaron Bentley]

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

On 13-12-04 11:15 PM, Andrew Wilkins wrote:
> So, synchronous bootstrap broke CI. The reason for this is that
> we're now using SSH as part of the process; I can see in the CI
> logs that a non-default identity file is being used with "juju
> scp". That explains why "juju ssh" (during bootstrap) is failing --
> it just tries the default keys.

So the first thing is, it seems messy to require more than one set of
credentials for a machine.  Until this point, only the ca-cert and
ca-private-key were required.  authorized_keys was a helper for ssh
and scp, which are not really part of the juju abstraction-- they're
ways to escape the juju abstraction and mess with the machine
directly.  Which is why CI hasn't had this issue until now.

Now, I personally would love it if you solved this by ditching the
ca-cert and ca-private-key and just use SSH everywhere, because on
canonistack and presumably, other private clouds, SSH is the only
realistic way to access machines:
https://bugs.launchpad.net/juju-core/+bug/1224057

But it's worth pointing out that SSH is a complicated beast, and
wrapping everything just right is challenging.  For example, bootstrap
just emitted the "IT IS POSSIBLE THAT SOMEONE IS DOING SOMETHING
NASTY!" message on CI:
http://162.213.35.54:8080/job/canonistack-upgrade-deploy/112/console

So an alternate option is to replace SCP with an API operation.  More
code perhaps, but less fragility that way.

> To workaround, CI could specify the key in ~/.ssh/config (see
> https://bugs.launchpad.net/juju-core/+bug/1257371/comments/9). To 
> fix the problem for good, we can do a couple of things: - Add yet
> more configuration to Juju to specify which key to connect with, or
> (and/or?) - Auto-generate an SSH key for each new environment at
> bootstrap.
> 
> The second option is far more user-friendly IMHO; the less
> configuration the better. Is there any reason why we should not do
> this? If we did this, then "authorized-keys" would be changed to
> implicitly include the auto-generated public key.

If you're doing the second, please do the first.  We want to be able
to pass around environments.yaml files for environments managed by
teams[1].  I don't think that's hard-- everything that's valid in a
jenv seems to work in environments.yaml so far.

Another option is to auto-generate the credentials, but stick them in
the control-bucket.  That way, they can be used automatically by
anyone with access to the bucket, and no one has to worry about
getting SSH keys to their teammates.

> On a related note, it occurred to me that the Windows CLI won't be
> able to bootstrap anymore. We're going to need to update the code
> to use the plink executable from PuTTY.

[1] I know it's a goal to be able to pass .jenv files around.  That's
great, but there are problems.  It doesn't work yet, because juju
still requires an entry in environments.yaml.  But more importantly,
it doesn't get us reproducible bootstraps, where if I tear down an
environment and stand it up again, my teammates can use their existing
config to access the new version of the environment.
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.14 (GNU/Linux)
Comment: Using GnuPG with Thunderbird - http://www.enigmail.net/

iEYEARECAAYFAlKgmSgACgkQ0F+nu1YWqI3D0QCfQm74ipXEZpmRFNrghDsaGCCL
yTAAni1xn5RA4oWg4/KP5FdmouimWWUY
=p5PL
-----END PGP SIGNATURE-----