On Thu, Dec 5, 2013 at 1:15 PM, John Arbash Meinel <j...@arbash-meinel.com>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 Juju-dev@lists.ubuntu.com Modify settings or unsubscribe at: https://lists.ubuntu.com/mailman/listinfo/juju-dev
