SSH keys and users

[specing]

I was just preparing to commit my SSH key support: -k /path/to/key.pub or SSH_ROOT_KEY=/path/to/key.pub

when I thought about making the whole script more flexible with regard to users:

e.g. modifying root: -A "root:passphrase:/path/to/key.pub" -A "root::/path/to/key.pub" -A "root:passphrase" and adding user joe: -A "joe" -- only adds the user, for use with "# su user" from root -A "joe:passphrase" -- adds the user and enable logins to it -A "joe::/path/to/key.pub" -- adds the user and only enable keyed logins to it -A "joe:passphrase:/path/to/key.pub" -- all of the above

maybe if the passphrase field equals "ask", ask for it? maybe if the key field starts with a space, generate a key passing the rest of the field as options to genkey? maybe if the user field starts with the name and is followed by a space and other text, pass that text as options to useradd?

While im more inclined towards the first implementation (I only want this script to prepare the VM for use with orchestration software), it would be a nice thing to have for one-off VMs.

thoughts? @globalcitizen

[globalcitizen]

Cool. Definitely a useful line of thinking.

Before adding too much user-level authentication logic to the script, it might be useful to consider the full range of deployment paradigms.

Some people want no SSH running. Some people may want not only custom SSH authorized_keys on a per user basis, but potentially other per-user home filesystem configuration tweaks. Some people may want keys generated ahead of time (perhaps for adding host identities in $HOME/.ssh/known_hosts to other systems)

We already have custom stage3 support, which could potentially support any configuration that people want to achieve.

Perhaps for file related configuration within a per-user home, we should take a similar 'specify a tarball or path to overlay' approach?

That would remove the /path/to/key stuff from the scope of this issue, so user to create and user:pass to create with password would be adequate (and more familiar to most users) while keeping things simple.

[specing]

The overlay method brings in a different set of problems,

say that someone wants to add .ssh key-based auth to root, he would have to create /root/.ssh/authorized_keys in an overlay directory/tarball

But what if he forgets to make /root mode 700? and in the other direction, what if he wants /foo/bar have a different mode?

And if they want a one-off VM, they can just modify the original tarball I think this is best left to be handled by orchestration software, while having the ability to add some users (and atleast their keys) would still be useful in this script.

Here is one more version of the command line interface for doing it: -A -A .pass= -A .pass=ask -A .key= -A .key=gen,<path/to/place/generated/in> -A .useradd= this is better as it supports adding multiple keys and doesen't suffer from cryptic syntax as the one above. Additionally, it could be read straight from a configuration file (but I am sailing away from the purpuse here).

Ah well, I think I'll just stop writing here and instead Just Do It (tm).

[globalcitizen]

Tarballs can store file modes without problems.

I agree that there's clearly an argument for things being left out of scope to other software.

I would still be keen to consider extra features for user creation, though, if you want to volunteer to create them!

Regarding your proposed syntax, perhaps a reasonable default would be to simply auto-generate a key in the standard ${home}/.ssh/id_rsa{.pub} location for each user created? Exceptions should be rare, and it spares the clunkier/error-prone syntax of passing in long relatively-absolute paths from the host (where these mean something different). Otherwise, how would your syntax handle adding a user with both a key path and a password?

I am worried that this is already getting SSH specific and/or wrapping useradd functionality (likely already known and familiar to our users) therefore this is sort of ringing out of scope warning bells.

[specing]

I agree, adding users is way out of scope.

Additionaly to that, I think the support for setting a root password (rougly 20 lines for a one line job) should be removed (and replaced with support for adding a public key). Why?

1. There is no need for most of containers to have a root password: I would assume (based on myself) that most people use it either via the autologin root terminal or with ssh (pubkeys).
2. This functionaly would be better suited for a VM->machine migration script (which would be seperate).

[globalcitizen]

I like your thinking here, for the majority of use cases. Unfortunately it doesn't work in some cases ... for example non-networked containers or containers that are not interested in deploying a particular network login solution. Therefore I don't think it makes sense to change the default configuration.

However, if you're really keen and would like to implement root keys instead of root passwords as an optional feature, feel free to plunge ahead.

Personally I don't use lxc-gentoo to instantiate authentication but rather use another script to modify the results to my liking. I think most people are doing that, and with good reason (since lots of small changes people will want are probably impossible to predict) and we can probably just leave this out of scope.