Initial User Changes

Handling user accounts

If networking is already functional, then another great step to handle early on is to make sure that the machine can be effectively used by an administrator who does not have “superuser” permissions (which are the permissions generally associated with an account that is traditionally named “root”). However, that administrator should be able to become the superuser.

Log in

Since the operating system was just installed, you may need to log in as the traditional built-in administrator account, which for Unix is typically named “root”.

This may be the only time that the account named “root” is logged into. Even if another user account was created during the process of installing the operating system, there may be a need to log in as “root” because there may be something stopping the user from being able to acquire the elevated “superuser” level of permissions. (In Unix, this could occur if the user was not in the appropriate group, or if the /etc/sudoers doesn't yet allow the user to elevate.) Such problems can be changed pretty quickly, so this might be the only time that the “root” account gets created. However, until it is fixed, go ahead and log in with the necessary account.

Viewing users

See what users currently exist.

Viewing users in Unix

Although the official way to do that is to check through the data that stores user information (like the /etc/passwd.txt file), that isn't always the fastest way, especially in Unix. Many of the user accounts may actually be accounts designed for automated processes. Instead, checking for a home directory is often a good approach. The user named “root” may commonly have a directory located somewhere else, but the following will often show all of the other users on the system.

ls -l /home/
Other location
Or, another standard (believed to be older)...
ls -l /users/

Filesystem Heirarchy Standard version 2.3: section on /home/: User home directories indicates that locations such as /users/ should be widely supported by software.

Viewing users in Microsoft Windows




net user
Optional step

See if /etc/adduser.conf pre-exists. (On a brand new OpenBSD installation, where no users have been created except for whatever happened during the operating system's installation process, you will probably find that it does not.)

[#bkusrerl]: User data backup

As a standard practice, a common practice is to make a backup copy of files that are about to be changed. This is not actually recommended at this time, simply becasue of these two reasons:

  • The simple/standardized way, documented here, involves a fair amount of typing. If reasonable, it may be nicer to delay this process (of backing up the user database) until a “remote access” method allows for an ability to do this via “copy and paste”. (Also, having the the cpytobak program available will make the process a bit nicer, later.)
  • So few customizations are made that any problem, so far, is likely to be non-catastrophic. A backup can be made very soon, and will be nearly the same as the current state. Until then, if the entire virtual machine is completely destroyed, the amount of work that would be lost is rather small (compared to the work for replacing a typical machine that already has a lot more custom data on it).

Some people may be prone to accept that rationale. (Those who are lazy may be more prone to accept that rationale than people who won't need to do the typing themselves.)

For those who do want to perform a backup right now (instead of following the rationale that was just discussed), instructions are available here. See: backing up user data.

Making a new group
Rationale of doing this now

The process of creating a new user might provide an opportunity to create a new group.

Whether this is best to do now, or not, may vary based on which operating system is being used. There's no compelling reason to do this (creating a group) before the next step (of creating a user) unless it simply makes the most sense to do so (when using a specific operating system).

In the case of OpenBSD, the script to create a new user does not provide an option to create a new group. The easiest and most straightforward way to create a group and then to add a user to that group is to do things in that exact order: create the group first.

The plan here is to limit SSH access to only user(s) who need it. This is done by using a group. Although the concept is fairly standard, because OpenSSH is widespread and OpenSSH does support this, the concept does not seem to be widely used by default. (Not even OpenBSD, the operating system designed by the team who makes OpenSSH, and an operating system which is widely recognized for having security by default, has a default behavior of deploying a group for those purpose.)

Rationale of why to avoid doing this now

It might be the case, for some operating systems, that creating a new user account is a straightforward part of some other process (like installing the operating system). If that is the case, you might choose to delay creating the group until after the user account is created, simply because that is the easiest way to accomplish all of the necessary tasks (on some operating systems).

Currently, the following operating systems are documented to fit that description:

  • None are currently listed here.
Creating a group
  • If the “_sshok” user doesn't exist yet (which it won't, on a brand new system using defaults), then fix that. See the process at making initial group(s).
[#vmpriusr]: Adding a new user

Creating a new user, at this time, might not be necessary, or might be highly recommended.

What is desired

Have a standard user account which is:

  • NOT named “Administrator”
  • nor is it named “root”
  • Nor “user”, nor “Owner”, nor “admin”. (Many new computers, with pre-installed operating systems, have been known to come with default accounts using one of those names. So the administrator account should not use any of those specific names.)

(Having the username contain the word “root” is not necessarily preferred, but is typically acceptable. The username should not simply be just the word “root”.)

Adding a new user might not be needed if the operating system's installation process asked about creating a new user account. If that didn't happen, create an account that fits that description.

Ensure that there is an ability to log into the account without using a user account that is named “Administrator” (which is used by Microsoft Windows systems), nor an account named “root” (which is the traditional “superuser” account on Unix, and so is widely used).

Side notes

(You may ignore these. However, if you were wondering about the other accounts...)

Such default accounts will be disabled because many attacks are known to target those usernames. So, have another account which will be used to create a user account. If a new user account needs to be created in order to accomplish the goal, then do that.

While creating the new user, if there is an opportunity to specify what groups the user is a part of, then have the user be added to “wheel” and “_sshok”. Note that during the process of creating a user, there may be multiple questions. For instance, with OpenBSD, the standard process is to make a group that is named after the user. Then, a later question will ask if there are additional groups to add the user to. This later question is where the administrator would type “wheel _sshok”.

Depending on the operating system, creating a new user might be a task that is simply easiest to do before a custom group gets created. In that case, it is also possible that adding a user to the group named “_sshok” won't work because that group doesn't exist yet. That's fine; that simply means that a step cannot be easily skipped, but this will be taken care of shortly.

  • Determine if a new user needs to be made
    • If the operating system installation process involved creating an account with a customized name, there may be no need to create a new user.
  • Make a new user if needed.
    • (Details are described in the section about making a user.)
    • If a new user is created for the purpose of performing administration tasks on a computer, then that is probably going to be worthy of official documentation. Make sure to note the name of the user.
Placing user into some useful groups

If the _sshok group hasn't been made yet, go ahead and do so now. (The process is described by making initial group(s). The process may have been skipped earlier, but completing the task is probably sensible to do at this time.)

Now, make sure that the user is in the desired groups.

Adding user to group
Checking existing groups to start

Many operating systems contain a command to add a group to a user account's list of groups. With some operating systems, the same command can be used to remove the user from all groups except for the group(s) specified on the command line. (The different effect may happen based on a different option.) So, figure out the initial set of groups that a user is in, so that the user can be re-added to all of those groups if the user gets accidentally removed from one or more groups.

One step that may be helpful is to check what groups the user is in at the start. The following will work on many Unix systems.

grep -i "[\:,]usrname" /etc/group

(Customize the usrname. The account name that you specify would be a custom account that you've created.)

An example of the output may look like:


In the above example, it shows that there is a group named wheel has usrname as a member of the group, and a group named _sshok also has usrname as a member of that group.

On many operating systems, the default settings do not match the example that was just shown. Instead, the user will not be listed in the _sshok group. If that is the case, then fix the problem.

The process for changing groups is often the editing /etc/group file. However, differences may exist. This may be especially true for specialized tools that are designed with the focus on changing settings relating to user accounts and groups.

As an example, here is how to do this in OpenBSD.

Adding user to a group in OpenBSD

In this example, the account named boxruler is going to be added to the group named wheel and _sshok.

export ADMINUSR=$(ls /home/)
echo ${ADMINUSR}

The idea here is that one user account (which is not root) will exist in /home/ on a new OpenBSD installation that had a custom user created. So, the end result is that the variable will have the name of the directory that is named after the user. If that didn't work as intended, just specify the user account manually.

export ADMINUSR=boxruler

If you are using a different account name, make sure to specify the name of the account that you are actually trying to add to the groups.

echo ${ADMINUSR}

The following will report groups, and then set groups, in OpenBSD. Note that the second command line replaces the users' groups. (It doesn't just add the groups.) That is why it is so nice to report the current settings before adjusting them.

Here is some sample input and output. The name of the administrator, in this example, is “${ADMINUSR}”.

$ user info ${ADMINUSR} | grep ^groups
groups  ${ADMINUSR}
$ usermod -G ${ADMINUSR},wheel,_sshok ${ADMINUSR}
usermod: Program must be run as root
$ echo ${?}

The “echo ${?}” output a non-zero value, which is a common method of verifying that a problem occurred. Notice how much better this runs when trying to do that as root:

# echo ${ADMINUSR}
(Output verifies that environment variable is properly set.)
# usermod -G ${ADMINUSR},wheel,_sshok ${ADMINUSR}

Check the results.

# echo ${?}
# user info ${ADMINUSR} | grep ^groups
groups  ${ADMINUSR} wheel _sshok
Other operating systems

To add a user to a group, the exact process may vary between different Unix systems. For detailed information, for other operating systems, consider information from these guides:

[#elevtwhl]: Elevating wheel

First, as standard practice, make a backup copy of a file before editing it.

ls -lF /etc/sudoers*
[ -f /etc/sudoers.old ] || cp -pi /etc/sudoers /etc/sudoers.old
ls -lF /etc/sudoers*
Rationale of editor

We'll be using visudo, even if we won't be using vi. For those who are curious about this, there is a discussion available as further reference. Just know that this discussion was not originally written as part of this guide, so be careful to remember to return back to this guide after reading about that specific topic. (That guide will continue onto other topics.) The discussion is at: visudoed

Supporting wheel

In case the system runs vi when running visudo (which is expected if “visudo -V” indicates that the EDITOR variable gets ignored), knowing how to perform this action in vi can be handy.

There are some additional references available. Just know that these references were not originally written as part of this guide, so be careful to remember to return back to this guide after reading about a specific topic. (These references may continue to discuss several other topics.)

Use the vi tutorials, just mentioned, if necessary.

If easily doable, copy the commented line that permits the “wheel” group to run any command. (In the /etc/sudoers text file, group names start with a percent sign, so the line says “%wheel.)

Remove the comment character from the start of a line that supports the users.

If, by chance, there was no pre-existing line in the /etc/sudoers file, a sample of that line can be seen by Running comamnds as root: using vi-like interface to adjust sudoers to support wheel

Testing changes

Very often, the easiest (and, often, the most effective) way to test this is to simply try using the new permissions.

A user who has access to use sudo can also run “ sudo -ll ”. A user who has limitations can do this to see a brief report on what restrictions/limits that user may be subjected to.

Disable the root account

Use an account other than “root” to do this.


It is possible for the “root” account to disable the “root” account's ability to log in. This is NOT recommended. There may be too many potential problems with a new user being able to get elevated privileges:

  • The user account's name might have been mistyped
  • The password may have been mistyped, or remembered incorrectly
  • The user might not be part of the “wheel” group
  • The /etc/sudoers file might not have been successfully changed
  • If you were expecting to do this via remote access, there may be an issue with remote access. As examples, the new user might not have the necessary permissions to use the method to use the remote access, the computer might not have the expected IP address, the remote access connection might not be working because the server isn't running or a firewall blocks the connection.

In case any of these steps has an unexpected problem, the best way to disable the account named “root” is to use another account. Then, the process of being able to disable the account named “root” will effectively verify all of the necessary steps. Also, if there are problems with disabling the account named “root”, then that means that the account named “root” is still available, so that account can still be used to help fix the problem. That can be far more convenient than dealing with a situation where the password to the root account is lost.

If you are logged in, but only with the account named “root”, then log in with another account. This doesn't necessarily require logging out.

  • On many Unix-like systems, pressing Alt-F2 or Ctrl-Alt-F2 will provide another login prompt. You can get back to the initial login prompt by pressing Alt-F1 or Ctrl-Alt-F1, unless you came from a graphical environment, in which case a different numeric function key (like F5 for F6 for F7) might be the usual way to get back to the graphics mode.
  • On some virtual machines, using the “virtual machine” software to press Ctrl-Alt-F2 will not send those keystrokes to the virtual machine. For example, in Qemu, a way to do that is to use the Qemu monitor and issuing the “sendkey ctrl-alt-f2” command. Other “virtual machine” software may have a different process. The process to send that keystroke combination to the “virtual machine” may seem a bit inconvenient, but it is likely better than:
    • logging out of the root account,
    • then figuring out that there is a problem,
    • and realizing that this problem cannot be fixed as easily (since the user already logged out of the root account).

(An older bit of writing: Overview: Why the recommended approach is (logging in as, and) using a new account to disable the “superusers”)

  • Considering the discussion in that rationale statement, log in as a non-root user.
    • Don't try to use sudo or su, which may permit a person to log in without typing the new user's password. Either use another login screen, or initiate a new SSH session (if that's working already).
Backing up user data

Since we're making another change to the user account data, backing up that data can be done. Whether this feels like overkill (because data was just recently backed up), or not, might depend on how long it took to do other steps. Regardless, backing up data is frequently considered to be a good thing to do, as a general practice. This guide is simply going to refer to the earlier instructions/discussion: backing up user data early.

Here are some instructions to disable the account named root. Please follow these steps.

How to disable the account named root
Disabling root password


sudo -E vipw

(The “-E ” is optional, in this case. Normally the “-E ” is recommended to help make sure that sudo runs the desired text editor. In this case, no other text editor is likely configured to be the default, yet. Therefore, vi will likely be used. The reason to use the optional “-E ” is just for habit that is useful at other times when sudo gets used with visudo.)

For those who are curious about why vipw is recommended, there is a discussion available as further reference. Just know that this discussion was not originally written as part of this guide, so be careful to remember to return back to this guide after reading about that specific topic. (That guide will continue onto other topics.) The discussion is at: (For those who are wondering: whyvipw)

Insert an asterisk at the start of the password field of the “root” account.

  • If the “root” account is the first account, the faster way is to press “l (lowercase L) five times, and then press “i (lowercase I) once, and then type the asterisk.
  • Otherwise, if the text cursor is not at the start of the file yet, go to the beginning of the file by pressing 1G (the number one, and then the capital letter G). Then, press Ctrl-[ (or, on most systems, press the “Esc” key). Actually, do that again, so that pressing Ctrl-[ (or Esc) was done twice. Then type : (a colon), followed by s/^root:/root:*/g

To exit, start by pressing Ctrl-[ (or, on most systems, press the “Esc” key). Actually, do that again, so it was done twice. Then, if all went well, either:

  • Press “ZZ” (capital z, twice), which saves the file.
  • Or, type “:wq!” (enter command mode, write file, quit program, and do all that without unnecessary prompting) and press Enter. This also saves the file.
  • Or, if things got accidentally changed too horribly, type “:q!” (enter command mode, quit program, and do all that without unnecessary prompting) and press Enter. That does not save any changes.

(Some additional text that describes this topic is available at: Disabling Unix system user accounts by modifying login password/credential information.)

Fully disabling the root account may also require blocking any other authentication methods. These instructions presume that there are no installed SSH keys that will allow anyone to use for logging into the account named “root”. Therefore, based on that assumption, this task is likely done at this time.

[#dsbldfrt]: Disabled unwanted account name(s)

Check the list of users on a system, as needed, to see whether any of these accounts exist:

  • root
  • Administrator
    • or... administrator

If they do, use another account to make sure the accounts are disabled.

Also check for SSH key files. For example:

sudo ls -l ~root/.ssh/authorized_keys