<div dir="ltr">Hello, just sharing my 2 cents here.<div><br></div><div>What about 2 separate options?<div><br></div><div>If the user that is running lxc-create have ~/.ssh/id_rsa.pub use that for root.</div><div><br></div>
<div>and</div><div><br></div><div>allow use an external id_rsa.pub as an argument in the command line?</div><div><br></div><div>In Vagrant, a tool used to create vm's in virtualbox/vmware, they have a public private/pub key, so all the machines can be accessed using vagrant's pub key, which for non-hardcore users is pretty convenient.</div>
</div><div><br></div><div>Now that lxc is going mainstream with vendor support, and tools like docker, if lxc include a private/pub key with the installation, I think will made the life easier to pack and share containers a la vagrant.</div>
<div><br></div><div>Alvaro.</div></div><div class="gmail_extra"><br><br><div class="gmail_quote">On Thu, Jan 2, 2014 at 6:50 PM, Serge Hallyn <span dir="ltr"><<a href="mailto:serge.hallyn@ubuntu.com" target="_blank">serge.hallyn@ubuntu.com</a>></span> wrote:<br>
<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div class="im">Quoting Michael H. Warfield (mhw@WittsEnd.com):<br>
</div><div class="im">> > Why not purely random?  I also liked the suggestion of putting the<br>
> > password in a file under $lxcpath/$lxcname - though chmod 600 owned<br>
> > by the calling user, not root.  I prefer not outputting it in<br>
> > stdout during create, but am not *strongly* against it.<br>
><br>
> I'm actually largely against "purely random" passwords, particularly<br>
<br>
</div>Well by purely random I of course meant using a reasonable char set.<br>
But I'm lazy and prefer to type (if I have to) 8 random chars to a bunch<br>
of boilerplate including mylongcontainername...  And realistically, if<br>
I'm not using ssh keys, and we have the pwd in a file, i'll be having a<br>
script fetch the pwd from the file for me on login.<br>
<div class="im"><br>
> when we're just trying to defeat a particular attack vector like this,<br>
> especially when combined with expiring the password.  I'm not sure<br>
> there's really anything significant left on the attack tree we need to<br>
> worry about (especially with the current state of affairs) and purely<br>
> random passwords are a significant PITA.  I think xkcd had it nailed<br>
> here:<br>
><br>
> <a href="https://xkcd.com/936/" target="_blank">https://xkcd.com/936/</a><br>
<br>
</div>OTOH for most of the containers I create I'll log in at most once, so<br>
memorable passwords are not useful.  Also your proposal still had some<br>
random chars, so at least with my throwaway approach to containers 2 or<br>
8 random chars makes no difference - I'll have to look it up.<br>
<br>
But it sounds like we may want to be able to pass a password template,<br>
i.e.  "lxc_${name}_XXX" (or if on private network then maybe "root")<br>
into the template.<br>
<div class="im"><br>
> I'm open to storing it in a file and, yeah, adding a chown 600 is fine.<br>
> Raises and issue though that a number of these templates will only run<br>
> as root and have not been adapted for running under a non-priv user.<br>
> That's another discussion that I think you and I and others need to<br>
> engage in.<br>
<br>
</div>Sadly some will never work as non-priv user.  Including 'ubuntu'.  At<br>
least until we get an in-kernel workaround enabling user namespaces to<br>
create some devices, which debootstrap insists on doing.<br>
<span class="HOEnZb"><font color="#888888"><br>
-serge<br>
</font></span><div class="HOEnZb"><div class="h5">_______________________________________________<br>
lxc-devel mailing list<br>
<a href="mailto:lxc-devel@lists.linuxcontainers.org">lxc-devel@lists.linuxcontainers.org</a><br>
<a href="http://lists.linuxcontainers.org/listinfo/lxc-devel" target="_blank">http://lists.linuxcontainers.org/listinfo/lxc-devel</a><br>
</div></div></blockquote></div><br></div>