... covers simple account creation and deletion, setting passwords and configuring SSH key-based access


Creating an account on a Linux machine is really simple, but the recommended practice for NeCTAR virtuals is to use SSH keys rather than passwords for user authentication, and that requires some extra configuration.  The instructions below are tailored for the (normal NeCTAR) case where you do your administration tasks using Linux command-line tools.

Creating an account

Let us assume that we want to create a login 'fred' for someone called 'Fred Smith'.  The recommended way to do this from the command line is to run the "useradd" utility as follows:

$ sudo useradd fred -m -c "Fred Smith"

The '-m' option says to create a home directory and populate it with initial "rc" files fro the default shell.

The '-c "Fred Smith"' sets the "comment" field for the user entry.  This is conventionally the user's full name.

By default on modern Linux systems, the "useradd" utility will automatically create a private "group" for each user (with the same name as the user) and make that the new user's primary group.

There are numerous other options for the "useradd" command.  See the manual entry for details.

Enabling SSH key-based access

To enable SSH key-based access for a user, you need to put the user's public key into their "~/.ssh/authorized_keys" file, as follows:

  1. Copy their public key to a file on the machine.
  2. Create the ".ssh".

    sudo mkdir ~fred/.ssh
  3. Copy or append the public key to the ".ssh/authorized_keys" file.

    cat file_containing_keys >> ~/.ssh/authorized_keys
  4. Make sure that the directories and file have the correct ownership and access.

    sudo chown -R fred ~fred/.ssh
    sudo chmod 700 ~/fred/.ssh
    sudo chmod 500 ~/fred/.ssh/*

Note that it is important to get the access and ownership of the .ssh files correct, because the SSH daemon will refuse user login if it thinks that the .ssh directory is not properly secured.

Setting an account password

Unless you need to (for example, for "sudo") it is advisable not to set a password on an account.  But if you need to, the commands for doing this are straightforward:

  • To set or reset another user's password:

    $ sudo passwd fred
    Enter new password: ********
    Reenter password: *******
  • A user can reset their own password as follows:

    $ passwd
    Enter old password: **********
    Enter new password: ********
    Reenter password: *******

There is a catch though.  It is not possible for an (unprivileged) user to set their first password. (In the general case, that would entail creating a user account which anyone could login to ... if they knew the account name.  Really bad idea.)  So the best practice solution is to do one of the following:

  • Get the new user to come to your office (or wherever).  Then run 'sudo passwd fred' on the virtual from your PC, and get them to type in their preferred password ... and confirm it.
  • Set the new user's password to a randomly generated password string, tell them what it is, and recommend to them (strongly!) that they change it.  It is best practice to NOT use email to tell them what the random password is, because email is typically insecure, and the user's email box could be insecure too ... depending on how careful they are!  Instead, give them the password on piece of paper, or dictate it over the phone.

Finally, remember that password-based authentication is useless if the user chooses a low quality password, if the user "lends" his password to someone else, or if they enter it on a machine that has a hardware or software "keystroke sniffer" attached to it.  And users often have the bad habit of using the same password on multiple systems.  Problems like this are the basis of the NeCTAR recommendation ... to only use SSH keys for SSH access into your virtuals.