In our previous posts we’ve explored some of the many ways of hardening the security of our server. One of the methods we explored was using SSH keys for root login, and disabling password authentication for root. In case we want to disable root login completely, we have to create a new user with root-level privileges so we still have control over the server.

Why use an alternate SSH user

As with everything in life, there are pros and cons to this kind of setup. First and foremost – root account is omnipotent – it can do everything and anything, which is not ideal for day-to-day operations, as it introduces plenty of room for potentially fatal mistakes (like typos which are bound to happen to everyone). Having root login enabled also increases the attack surface, if you’re using password authentication.

Having alternate users is especially benefical for auditing. If you have multiple people all logging in as root, you most likely won’t be able to figure out who exactly did what, as all logs will say ‘root ran this command’. Linux auditing daemon distinguishes between real UID and effective UID, so if a user bob runs something with sudo, the audit logs will reflect that.

In a sense, having alternate users provides security through obscurity, as attackers now have to guess the username along with the password. It also makes it easy do revoke access to a specific user – just remove it completely or disable access to it.

Lastly, it enforces accountability, especially if you have more than one user, as even though you can still escalate to root, you’ll see what was the original user that logged in.

The audit trail will only work if all users actually log in as their specified user. It’s still possible to bypass this audit trail. Additionally, if a user with root-level privileges gets compromised, it will be (almost) the same as root itself got compromised. Also, if a running process gets compromised, it won’t matter if it was run with sudo or not, as privileges can still be escalated in various other ways.

Creating the alternate user

We’ll start by logging in as root, of course. We’ll have to create the user, set up it’s password, add it to wheel group, and lastly, disable root login.

First, let’s create the new user. For the purpose of this tutorial, we’ll name it sshuser. We’ll use useradd  command for this step. Depending on the options we use, useradd will create a home directory for sshuser, and will create a new group for this user by default.

To create a new user, with all the default options, just use useradd username :

[root@vpscheap-blog ~]# useradd sshuser

The account will be created in a locked state, i.e. you won’t be able to log in as that user yet. If you try and input a blank password, you’ll just get ‘access denied’. So, we’ll use the passwd  command to set up a password. The basic sytax is passwd username :

[root@vpscheap-blog ~]# passwd sshuser
Changing password for user sshuser.
New password:
Retype new password:
passwd: all authentication tokens updated successfully.

When we added the user with useradd, it’s entry was automatically added to /etc/passwd file, and should look something like this:

[root@vpscheap-blog ~]# grep sshuser /etc/passwd

In case you’re not familiar with that file, there are seven colon-separated fields in it:

  • Username
  • Password – x is just a placeholder, the actual password is saved in encrypted form in /etc/shadow file
  • User ID (UID)
  • Group ID (GID) – this is the ID of the primary group
  • User info – this field is optional, and can be used to add any additional information to the user, which can then be checked with the finger command
  • Absolute path to the user’s home directory
  • Default login shell

This user still doesn’t have root-level privileges. If you try to run anything requiring root-level access, you’ll be met with the following message:

[sshuser@vpscheap-blog ~]$ cat /etc/shadow
cat: /etc/shadow: Permission denied

And if you try this with sudo , you’ll see something like the following:

[sshuser@vpscheap-blog ~]$ sudo cat /etc/shadow

[sudo] password for sshuser:
sshuser is not in the sudoers file. This incident will be reported.

What we need to do now is add the user to wheel group – this is the default sudoers group on CentOS systems. We’ll use usermod  command for this. The syntax for adding a user to an additional group is usermod -aG group username :

[root@vpscheap-blog ~]# usermod -aG wheel sshuser

We could actually skip this step by using -G option when we first created the user with useradd. The syntax here will be useradd -G group1,group2… username  :

[root@vpscheap-blog ~]# useradd -G wheel sshuser2

[root@vpscheap-blog ~]# grep sshuser2 /etc/group

You can check in which groups a user belongs by checking the /etc/group file, or with groups  command when logged in as that user:

[root@vpscheap-blog ~]# grep sshuser /etc/group

At this point, feel free to log in as the new user and test out if sudo is working as intended. If everything is in order, the last step would be to disable root access. We’ll have to edit the /etc/ssh/sshd_config file. It’s good practice to back up all configuration files before editing them:

[root@vpscheap-blog ~]# cp -a /etc/ssh/sshd_config{,.bak}

Now open the file in your favorite editor (we’ll use vim here), and find a line that says PermitRootLogin:

[root@vpscheap-blog ~]# vi /etc/ssh/sshd_config

It will most probably be commented out, so remove the # sign from the beginning of that line, and change ‘yes’ to ‘no’:

The line should look like this – PermitRootLogin no

Save the file, and restart SSH daemon to apply this change. On CentOS 6 and below (sysVinit):

[root@vpscheap-blog ~]# service sshd restart

And on CentOS 7 (systemd):

[root@vpscheap-blog ~]# systemctl restart sshd.service

In case you need to log in (or escalate) to root user, you can use the su –  command. You’ll be prompted for root’s password. Make sure you add the to the command so that your path settings to various programs are correct (root’s instead of the other user’s):

[sshuser@vpscheap-blog ~]$ su -
[root@vpscheap-blog ~]#


This kind of setup is considered best-practice, and for a reason. To reiterate, having an alternate SSH user reduces the attack surface, makes auditing easier, and reduced the chances of making a fatal mistake that could cost you all of your data, among other things. Keep in mind that this approach to security, as any other, isn’t 100% secure – there are still plenty of ways your machine can get compromised, so read, learn and keep track of latest industry standards if you want to keep your server as secure as possible.
And remember, an account should only have as much access as it needs, meaning not every user account needs to have root-level privileges!