Add Sudo user, during install, with passwordless ssh access

[betweenbrain]

First of all, thanks for the awesome script! I've been wanting to jump into NGINX, and this has really helped. Hopefully I can contribute to its awesomeness.

This PR will add a new sudo user with key based SSH access. Since root login is no longer allowed after running install.sh, this solves the issue when people like me add a new user, but forget to make that new user a sudoer.

I've tested this on Ubuntu 12.04 and Debian 6.0. It's actually ported from an older server build script that I wrote at https://github.com/betweenbrain/ubuntu-web-server-build-script/blob/master/build.sh, and has been used by a few folks.

If you like this idea, what do you think about taking it one step further and disable SSH password authentication all together, like at https://github.com/betweenbrain/ubuntu-web-server-build-script/blob/master/build.sh#L140?

Thanks again!

[Mins]

Thanks for this! I agree that key based authentication for SSH should be used whenever possible. However, there are a few potential issues that I can foresee.

1. Sudo is not installed by default in most minimal OS templates/ISOs.
2. Users that prefer using "su" instead of "sudo" (myself included) to gain root will have to reverse the changes.
3. Users must remember that the AllowUsers option is now set in sshd_config.
4. The current implementation suggests a one time setup. Its probably better to prompt for user input instead of storing the user's password/pubkey in options.conf. This way, passwords won't be exposed if options.conf is not secured as per install instructions. In this regard, "adduser" is a better choice compared to "useradd".

Furthermore, I'm not sure if imposing such an opinionated config is a good idea. As it currently is, I feel that the minimal SSH tweaks caters better for most server installs. Advanced sysadmins will prefer a clean base config, so they can easily configure their preferred authentication setup.

Perhaps this can be added as a additional function or script?

[betweenbrain]

Thanks for the detailed, and educational, response. These are all very good points.

1 & 2) You're absolutely right about sudo and su. In retrospect, it is best to leave it alone and up to the end user if they want to install sudo.

3. Can you expand on this? Would you disable password authentication in favor of using a key file? If so, how would you do it? Maybe combine it with an adduser script and prompt for the key?

4. It's ironic that you mention the one time setup / prompt. That is the original approach as originally used at http://www.cyberciti.biz/tips/howto-write-shell-script-to-add-user.html

Hopefully these aren't all issues that you've thought about before.

[Mins]

For point 3, its simply a minor inconvenience that each new user that requires SSH access must be added to the AllowUsers directive. Otherwise, its a good security measure.

I'm with you on using pub key authentication due to the added security, although admittedly, its not something I use all the time.

I too am wondering how this can be implemented in a practical way in setup.sh (usually executed only once), since the following are to be automated:-

1. Disable/enable password authentication + reload sshd
2. Create files and folders for new or existing users + set permissions ( /home/user/.ssh/authorized_keys )
3. Append keys to authorized_keys ( prompt for input? )

Given the number of features, some of which may be invoked multiple times (points 2 and 3), I'd probably implement this as a new script. This script can then be added into an "Extra_scripts" folder under the tuxlite package.

[betweenbrain]

It seems like we're thinking along the same lines here. What I did with my older script was to execute points 1-3 during the one time setup, mostly to ensure that ssh access would be possible as root login was disabled, and to also have a separate script available for points 2 & 3 for additional users, since point 1 was already taken care of.

I'll see if I can work up some code along these lines and revise the pull request.