Skip to main content

Create a new server user

Create a New User​

Running a server as root all the time is dangerous because root has unrestricted access to the entire operating system.

Instead, we should create a regular user and give that user sudo access so root privileges are only used when necessary.

A. Why We Should Avoid Running as Root​

root is the highest permission level on a Linux system.

It can modify or delete almost anything without asking for confirmation.

For example, a destructive command executed as root may be allowed to run without stopping you.

The safer approach is:

This follows the principle of keeping permissions as limited as possible.

B. What Is sudo?​

sudo stands for superuser do.

It allows a regular user to execute a specific command with root privileges.

Instead of operating as root all the time:

<command>

we elevate permissions only when necessary:

sudo <command>

The idea is:

Default → Regular user
Temporary → Root privileges with sudo

C. Create a New User​

Create a new Linux user with:

adduser <username>

For example:

adduser jem

Linux will ask you to create a password and may request additional information such as:

  • Full Name
  • Room Number
  • Work Phone
  • Home Phone
  • Other

These additional fields are optional and can usually be left blank.

Creating the user also creates a home directory:

/home/<username>

For example:

/home/jem

D. Give the User Sudo Access​

The new user is a regular user by default.

To allow the user to execute commands with root privileges, add it to the sudo group:

usermod -aG sudo <username>

For example:

usermod -aG sudo jem

This allows the user to use sudo when elevated permissions are required.

E. Switch to the New User​

We can switch users with su:

su - <username>

For example:

su - jem

The - starts a login shell, so the new user's home directory, environment, and shell settings are loaded.

Conceptually:

If we later run:

exit

we return to the previous shell rather than necessarily disconnecting from the server.

F. Verify Sudo Access​

Before relying on the new user, verify that sudo actually works.

One way is to access a file that normally requires elevated permissions:

sudo cat /var/log/auth.log

The system should ask for the user's password.

If the command succeeds, the new user has working sudo access.

This verification is important before making further security changes.

G. Prepare SSH Login for the New User​

Eventually, we want to stop relying on direct root login.

Before doing that, the new user needs its own working SSH authentication.

SSH public keys for a user are stored in:

~/.ssh/authorized_keys

When an SSH connection is attempted:

The server checks whether the connecting computer has the private key corresponding to an authorized public key.

H. Create the .ssh Directory​

Move to the new user's home directory:

cd ~

~ represents the current user's home directory.

Check whether .ssh already exists:

ls -la

If it does not exist, create it and restrict access to the current user:

mkdir -p ~/.ssh
chmod 700 ~/.ssh

Because these commands are run after switching to the new user, that user owns the directory. If .ssh was accidentally created as root, correct its ownership explicitly:

sudo chown -R <username>:<username> /home/<username>/.ssh

Then enter the directory:

cd .ssh

The structure should now look like:

/home/<username>/
└── .ssh/

I. Create authorized_keys​

Inside .ssh, create the authorized_keys file:

touch authorized_keys
chmod 600 authorized_keys

The structure becomes:

/home/<username>/
└── .ssh/
    └── authorized_keys

This file contains the public keys that are allowed to authenticate as this user. The 600 permission allows only its owner to read or modify it.

J. Get the Public SSH Key​

On the local computer, display the public key:

cat <key-name>.pub

For example:

cat full-stack-front-end.pub

Copy the output.

Make sure you copy the public key, not the private key.

A public key normally comes from a file ending in:

.pub

The private key should never be copied to the server.

K. Add the Public Key to authorized_keys​

Log back into the server and switch to the new user.

Then edit:

vi ~/.ssh/authorized_keys

Paste the public key into the file and save it.

The relationship is now:

The public key lives on the server.

The corresponding private key remains on the local computer.

L. Test SSH Login as the New User​

Before disabling root login, test whether the new user can actually connect through SSH.

Exit the current SSH sessions and reconnect using:

ssh <username>@<server-ip>

For example:

ssh jem@<server-ip>

If the connection succeeds, SSH authentication for the new user is working.

The flow is now:

M. Troubleshooting SSH Login​

If SSH login with the new user does not work, check a few common problems.

First, verify that the filename is spelled correctly:

authorized_keys

Then make sure you copied the public key, not the private key.

Also make sure you are connecting with the correct username:

ssh <new-username>@<server-ip>

The username matters because every user has its own SSH configuration and authorized_keys file.

N. SSH Keys and Users​

An SSH key is not necessarily tied to only one server user.

The same public key can be added to multiple users' authorized_keys files.

For example:

As long as the corresponding public key has been added to a user's authorized_keys, the local private key can be used to authenticate as that user.

SSH keys are therefore primarily associated with the computer or identity holding the private key rather than being permanently tied to one server user.

O. One SSH Key or Multiple Keys?​

It is possible to reuse one SSH key for multiple purposes.

For example, the same key could potentially be used for:

It is also possible to create separate keys for different servers or services.

There is no requirement in this section to create a unique SSH key for every server instance.

The choice depends on how you want to manage your SSH keys:

You can make it complex, you can make it simple.

Complete Flow​

Key Takeaway​

The goal is to move away from using root as the normal server account.

Create a regular user:

adduser <username>

Give it sudo access:

usermod -aG sudo <username>

Then configure SSH authentication:

~/.ssh/authorized_keys

Finally, verify that the new user can successfully connect:

ssh <username>@<server-ip>

This gives us a regular user that can log in through SSH and temporarily obtain root privileges with sudo when necessary.