SSH keys

[John Meinel]

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" <andrew.wilkins at canonical.com>
wrote:

> On Thu, Dec 5, 2013 at 1:15 PM, John Arbash Meinel <john at 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-----
>>
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.ubuntu.com/archives/juju-dev/attachments/20131205/a02c44d4/attachment.html>