-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 On 2013-12-05 8:15, 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. > > 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.
Writing stuff outside of ~/.juju isn't great behavior, but we could put the SSH key there. We could probably write the ssh private key into the .jenv and pull it out to hand off to the SSH subprocess. Though if we actually start getting into that, then whether you're using OpenSSH or SunSSH or Putty or any of a number of SSH implementations starts to complicate things. So *if* you don't configure anything (don't set non-standard SSH keys) we already just read your ~/.ssh/id_rsa.pub and set that as the SSH key and use it. Which SSH will just pick up and use when connecting to the machine. As such, I think auto-generating keys is *way* overkill. I think for ssh keys we can go with either: a) If you want to set a special authorized-key line, then you should configure ~/.ssh/config to match it (and if you don't set a special one, then we use your default pub key which should match your default private key.) b) We allow people to specify a private key file to use when connecting. There is also another problem in the synchronous bootstrap case, which is Canonistack. Most people have configured the bounce-via-chinstrap for it, so ssh actually JustWorks, but you *won't* be able to directly dial port 22 (or the API server, etc). In the past, what was common was to 'juju bootstrap' and then use 'sshuttle' *to the bootstrap node*. Otherwise what machine do you have to sshuttle forward for you? I think we might consider making it possible to configure a proxy command that can be run before we start trying to connect to the bootstrap machine. > > 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. It would be nice if you could use 'ssh' if it was available. *I* have it configured already with my keys, etc (openssh from cygwin). We had a bunch of discussions in Bazaar about this in the past. What we should have ended up (that I originally objected to, but I was wrong) was to use the bundled Paramiko (in-process ssh library) by default. So I'd like to see it something that a user could configure (Bazaar used BZR_SSH which could be a name like 'openssh' or a path to an executable), but had a sane built-in version. > > Cheers, Andrew > > John =:-> -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.13 (Cygwin) Comment: Using GnuPG with Thunderbird - http://www.enigmail.net/ iEYEARECAAYFAlKgC9wACgkQJdeBCYSNAANYbACeIpl2pwDL7jVwH75bzVK1OB9H cAQAmQHf2IFiVw5/Wrc9af9zduPvNp90 =Ix8d -----END PGP SIGNATURE----- -- Juju-dev mailing list Juju-dev@lists.ubuntu.com Modify settings or unsubscribe at: https://lists.ubuntu.com/mailman/listinfo/juju-dev
