Just to mention the main reason not to autogenerate a key is because if you already have keys that are published and shared it is a PITA to have to use another set. I have my keys for 4 different machines on Launchpad and people can use 'ssh-import-id lp:jameinel' to give me access to a machine. It is, in fact, how our team has access to the tarmac bot. So even if we *can* autogenerate, it should not be the default behavior.
John =:-> On Dec 5, 2013 10:02 AM, "Andrew Wilkins" <[email protected]> wrote: > On Thu, Dec 5, 2013 at 1:15 PM, John Arbash Meinel <[email protected] > > wrote: > >> -----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. >> > > If we were to auto-generate, I think they would go into either ~/.juju or > the .jenv file. > We already make assumptions about how things work in the ssh client, and > what flags it accepts. I don't think this is any more problematic is it? > > >> 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. >> > > So long as you have an ~/.ssh/id_rsa.pub. What about Windows users (that > don't have cygwin/openssh installed)? > Auto-generating means we can delete this page: > https://juju.ubuntu.com/docs/getting-started-keygen-win.html > > >> 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. >> > > Or an option to just start trying to SSH, rather than the initial direct > connection? Or just always do that? > > >> > >> > 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). >> > > Sure. I said PuTTY/plink because I perceive it to be the de facto standard > on Windows, but we should certainly give people the option of using an > alternative. > > >> 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. >> > > SGTM. It may even be viable to use go.crypto/ssh for non-interactive SSH > sessions. Although... proxies. > > >> >> >> > >> > 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 [email protected] Modify settings or unsubscribe at: https://lists.ubuntu.com/mailman/listinfo/juju-dev
