Updated on 24.5.2023

How to manage Linux user account security

Practising good control over your user accounts can be a big step toward a more secure cloud server. Follow the examples in this guide to find out how to perform some of the basic user account management tasks, and how to implement a few added security measures.

Adding a new user

One of the common security practices on any Linux machine is to avoid using the root account for day-to-day operations. If you have just deployed a new cloud server, of course, the only account on it will be root, so you will need to create a new username for yourself.

adduser <username>

Follow the user creation procedure to set a password and other information. On CentOS and other Red Hat variants, you will need to manually unlock the new account by setting the password with the next command.

passwd <username>

If you are going to be using this account for system management, give yourself sudo execution privileges. On Ubuntu servers, you can do this with the command below.

adduser <username> sudo

Adding sudo permissions to users on CentOS is a little different, use the following instead.

gpasswd -a <username> wheel

Debian users should note that the sudo access control system might not be installed by default. If it is missing, install it with the following.

apt-get install sudo

Once installed, use the same command as with Ubuntu above to add your username to the sudoers list.

Note that the group changes will only take effect after the next time the user logs in.

With sudo permissions, you can perform all the same operations as the root account can, but without compromising on security. In case you are going to have more users on your server than just yourself, it is much safer to give them sudo privileges instead of sharing the root password with everyone. Using sudo over the root account is generally considered good practice overall.

Disable root login

When you have your own account set up you should go ahead and disable SSH remote login for root. The OpenSSH server settings are defined in a configuration file, open it in an editor on Debian or Ubuntu with the next command.

sudo nano /etc/ssh/sshd_config

With CentOS and other Red Hat variants, or if you just prefer using vi instead.

sudo vi /etc/ssh/sshd_config

Search for the authentication options and change the root login permission by setting it to no like below.

PermitRootLogin no

Afterwards, just save the file and exit the text editor.

Making changes to the SSH configuration file will require you to restart the service, on CentOS cloud servers use the following.

sudo systemctl restart sshd

On systems running Ubuntu, the service is simply called ssh, the same will work with Debian.

sudo service ssh restart

Password policies

If your server has more remote users than just yourself, implement and enforce reasonable password policies with a Linux PAM module called pam_cracklib.so. The module will check user passwords against dictionary words to help prevent weak password usage. You can also use it to set the minimum requirements for a new password like length and complexity.

On Ubuntu and Debian systems, you need to install the module with the command below.

sudo apt-get install libpam-cracklib

CentOS and other Red Hat variants already have it installed by default.

With the module installed, open the configuration file in an editor on Ubuntu or Debian.

sudo nano /etc/pam.d/common-password

On cloud servers with CentOS, the file is stored under a different name, use the following.

sudo vi /etc/pam.d/system-auth

Installing the module on Ubuntu and Debian already pre-configures the password checks, so find the corresponding setting and edit it to look like the example below. On CentOS, depending on your version, you might need to add the whole following line to the configuration file.

password required pam_cracklib.so retry=3 minlen=8 difok=3 dcredit=1 ucredit=1 lcredit=1

The first parameter retry defines how many times the user gets to attempt again. The next minlen marks the minimum length of the password, while difok checks the maximum number of reused characters compared to the user’s old password. The last 3 parameters set requirements for the password complexity, dcredit is a number of numerals, ucredit for upper case characters, and finally, lcredit is a number of lower case characters.

Once you have set the password requirements to your liking, save the configuration file and exit the editor. Note that these policies only apply to regular user accounts, you as an administrator are still responsible for the root user password strength.

Restrict SSH to specific user group

OpenSSH servers can limit user connections by cross-checking that they belong to the allowed group. This can be useful if you have multiple users which should not need to remote with SSH, or you just want the added security for example when running a web service or database with separate users from your own.

Start by creating a new user group for this purpose, you can name the group whatever you wish, for this example, the group is called sshusers.

sudo groupadd sshusers

Next, add your own username to the same new group.

sudo gpasswd -a <username> sshusers

You can then check that your username was added to the group successfully.

groups <username>

The output will show all the groups the given username belongs to including a user group with the same name as the user.

user : user sudo sshusers

With this done you can specify the allowed group for OpenSSH. To do this, open the configuration file in an editor.

sudo nano /etc/ssh/sshd_config

If you do not have nano installed, or just prefer vi, use the following instead.

sudo vi /etc/ssh/sshd_config

You will need to add the line underneath the file, for example at the end.

AllowGroups sshusers

Make sure your new configuration option is not commented out with the # sign in front of it, then save the file and exit the editor.

Afterwards just restart your SSH server, on Ubuntu and Debian servers use this command.

sudo service ssh restart

With CentOS and other Red Hat variants, the same can be done using the following instead.

sudo systemctl restart sshd

With the new configuration, any user that does not belong to the allowed group will simply be denied access over SSH, even if their password was entered correctly. This will greatly reduce the chance of having a user password brute-forced, or guessed with dictionary lists, giving you a more secure cloud server.

Janne Ruostemaa


  1. Clifford Mathew


  2. Awesome !!!
    Thanks Janne.

  3. Now that ‘SSH keys only’ is the default login method, a good addition to this tutorial might be, that to use ssh-copy-id for a new user PasswordAuthentication needs to be changed to ‘yes’ momentarily. Or maybe show some other way to do it.

    For example one might turn PermitRootLogin off before copying ssh keys to a new user.

  4. Janne Ruostemaa

    Hi Markus, thanks for the suggestion. Using the SSH keys only option at Cloud Server creation does require you to add your SSH keys beforehand. Therefore, this manual method outlined in the tutorial isn’t required in that case but is helpful for including SSH keys to existing Cloud Servers.

  5. When the root Account Uses SSH Key Authentication, use rsync to add a copy of your local public key to your new user’s ~/.ssh/authorized_keys file.

    For example:
    rsync –archive –chown=sammy:sammy ~/.ssh /home/sammy

Leave a Reply

Your email address will not be published. Required fields are marked *

Back to top