You can already (with some templates at least) specify an ssh key to inject. I think defaulting to using ~/.ssh/id_rsa.pub is bad, or at least better left for a lxc-create wrapper which can always default to that, though I could be swayed on that.
It's not for lxc-create itself to do, since there may not be a root account, or root's home may be under /home/root, etc. The templates better know where to plop the ssh keys. Also, as I believe Michael has pointed out, ssh isn't the only way of connecting. Many people use lxc-console or the lxc-start console to connect, and may not even have a nic in the container. -serge Quoting Alvaro Miranda Aguilera ([email protected]): > Hello, just sharing my 2 cents here. > > What about 2 separate options? > > If the user that is running lxc-create have ~/.ssh/id_rsa.pub use that for > root. > > and > > allow use an external id_rsa.pub as an argument in the command line? > > 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. > > 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. > > Alvaro. > > > On Thu, Jan 2, 2014 at 6:50 PM, Serge Hallyn <[email protected]>wrote: > > > Quoting Michael H. Warfield ([email protected]): > > > > Why not purely random? I also liked the suggestion of putting the > > > > password in a file under $lxcpath/$lxcname - though chmod 600 owned > > > > by the calling user, not root. I prefer not outputting it in > > > > stdout during create, but am not *strongly* against it. > > > > > > I'm actually largely against "purely random" passwords, particularly > > > > Well by purely random I of course meant using a reasonable char set. > > But I'm lazy and prefer to type (if I have to) 8 random chars to a bunch > > of boilerplate including mylongcontainername... And realistically, if > > I'm not using ssh keys, and we have the pwd in a file, i'll be having a > > script fetch the pwd from the file for me on login. > > > > > when we're just trying to defeat a particular attack vector like this, > > > especially when combined with expiring the password. I'm not sure > > > there's really anything significant left on the attack tree we need to > > > worry about (especially with the current state of affairs) and purely > > > random passwords are a significant PITA. I think xkcd had it nailed > > > here: > > > > > > https://xkcd.com/936/ > > > > OTOH for most of the containers I create I'll log in at most once, so > > memorable passwords are not useful. Also your proposal still had some > > random chars, so at least with my throwaway approach to containers 2 or > > 8 random chars makes no difference - I'll have to look it up. > > > > But it sounds like we may want to be able to pass a password template, > > i.e. "lxc_${name}_XXX" (or if on private network then maybe "root") > > into the template. > > > > > I'm open to storing it in a file and, yeah, adding a chown 600 is fine. > > > Raises and issue though that a number of these templates will only run > > > as root and have not been adapted for running under a non-priv user. > > > That's another discussion that I think you and I and others need to > > > engage in. > > > > Sadly some will never work as non-priv user. Including 'ubuntu'. At > > least until we get an in-kernel workaround enabling user namespaces to > > create some devices, which debootstrap insists on doing. > > > > -serge > > _______________________________________________ > > lxc-devel mailing list > > [email protected] > > http://lists.linuxcontainers.org/listinfo/lxc-devel > > > _______________________________________________ > lxc-devel mailing list > [email protected] > http://lists.linuxcontainers.org/listinfo/lxc-devel _______________________________________________ lxc-devel mailing list [email protected] http://lists.linuxcontainers.org/listinfo/lxc-devel
