2. Verify your user status

If logged as root you will need to create a new unprivileged user account.

2.1. Check if You Are Root

Run the following command to check your current username:

whoami

If the output is root, you are logged in as the root user.
Alternatively, you can check your user’s UID (User ID) by running:

id

If the UID is 0, you are logged in as the root user.

2.2. Verify Root Privileges for a Non-Root User

If you are not logged in as root, check if your user is already part of the sudo group by running:

groups

This will display a list of groups that your user belongs to. If sudo is included in the list, then your user has administrative (privileged) rights.

Alternatively, you can verify by running a command that requires sudo privileges. For example:

sudo whoami

If you are prompted for a password and then successfully see the output root, it means your user has sudo access.

2.2.1 What to do based on the results

Case 1: Your User Is Root (whoami output = root or id shows UID 0)
- Create a new unprivileged user account
- Log out from the root account and use the newly created account for further activities.
Case 2: Your User Has Non-Privileged Access (Not in the sudo group)
- You can ask the system administrator to provide you with sudo privileges or log in as root to add your user to the sudo group (if you have root credentials).
Case 3: Your User Is Already in the sudo Group
- You can proceed with your work as you already have administrative access without being the root user directly.

This process will ensure you safely start working on the server while following best practices for user privilege management.

2.3. Create a new unprivileged user account

In Linux systems, managing root privileges is an essential part of user administration. There are two common ways to grant root privileges: using the visudo command or the usermod command.

When to Use visudo vs. usermod

Use visudo for detailed and secure configurations.

Use usermod for simple and fast group-based privilege management.

2.3.1. Using the `usermod` Command

The usermod command is a straightforward way to add a user to the sudo (or other administrative) group. It’s ideal for cases where the system configuration allows group-based privileges.

To add the user to the sudo group, use the following command:

sudo usermod -aG sudo username

Replace username with the actual username of the user you want to add to the sudo group.
The -a flag ensures the user is added to the group without removing them from other groups.
The -G flag specifies the group to which the user is being added (sudo in this case).

sudo adduser username

You have to provide a password for the new account. Then you are prompted to enter details for the new user, which is optional.

Create a new user account (replace username with the actual name of the user account):

sudo adduser username

Add the new user account to the sudo group:

sudo usermod -aG sudo username

You can verify group membership with the following command:

groups username

Example :

groups ubuntu

ubuntu sudo users

The new user account is now a sudo user and can execute all commands.

This is configured by the default setting for the sudo group:

# Allow members of group sudo to execute any command
%sudo   ALL=(ALL:ALL) ALL

2.3.2. Using the visudo command

Here’s how you can add root privileges for a user using visudo:

Open the sudoers file:

sudo visudo

This command ensures that the sudoers file is checked for syntax errors before saving, which prevents potential misconfigurations. 2. Add the User with Full Privileges: Locate the section in the file where user privileges are defined. To grant a user (username) full root privileges, add the following line:

username ALL=(ALL:ALL) ALL

Replace username with the actual username.
This line allows the user to execute any command as any user or group, with root privileges.

Save and Exit
- If using vim as the default editor, press Esc, type :wq, and hit Enter to save and close.
- For nano, press Ctrl+O to save, then Ctrl+X to exit.

2.4 Understanding Passwordless `sudo` Configuration

2.4.1. The `NOPASSWD` Option in `sudoers`

If your user or group (e.g., sudo) is configured with the NOPASSWD option, sudo commands can be executed without entering a password. These configurations are defined either in the main sudoers file or in files within the /etc/sudoers.d directory.

This setup can be intentional for automation purposes or convenience but should be used with caution to avoid compromising security. Always review and modify sudo configurations responsibly.

2.4.2. Re-enable password prompts

To re-enable password prompts for sudo commands, follow these steps:

Edit the sudoers File Safely using visudo:
```
sudo visudo
```
Locate and Remove/Modify the NOPASSWD Rule:
- Find any lines with NOPASSWD. For example:
```
username ALL=(ALL) NOPASSWD:ALL
```

Replace NOPASSWD:ALL with ALL. The updated lines will look like:
```
username ALL=(ALL) ALL
```

Save and Exit

2.5. Check and configure the `PermitRootLogin`

Steps to Check and Set PermitRootLogin to no

2.5.1. Locate the SSH Configuration File

The main configuration file for SSH is typically located at /etc/ssh/sshd_config.

To check the current behavior of PermitRootLogin, run: bash sudo grep PermitRootLogin /etc/ssh/sshd_config

If the output is commented (# PermitRootLogin ...), then the default system behavior is applied (often yes).

2.5.2. Edit the SSH Configuration

Open the file in an editor:

sudo nano /etc/ssh/sshd_config

Search for the PermitRootLogin directive. If it’s present but commented (preceded by #), uncomment it by removing the #. Change the line (or add it if not present) to:

PermitRootLogin no

This disables root login via SSH.

Check Included Folder for Additional Configurations
- Many distributions support including extra configuration files from a folder. For example:
```
Include /etc/ssh/sshd_config.d/*.conf
```
- To check whether additional configuration files are included, look for an Include directive in sshd_config:
```
grep -i include /etc/ssh/sshd_config
```
- SSH reads the configurations in order:
  1. The main file (/etc/ssh/sshd_config) is read first.
  2. Any configurations in the included folder files (like /etc/ssh/sshd_config.d/*.conf) are read next.
  3. Conflicting settings: The last read line takes precedence.
- This means if both the main configuration file and included files specify PermitRootLogin, the value in the last processed file (or line) will apply. Example: If /etc/ssh/sshd_config has:
```
PermitRootLogin yes
```
  and /etc/ssh/sshd_config.d/custom.conf has:
```
PermitRootLogin no
```
  Then the system will apply PermitRootLogin no, as it is read later.
- See Appendix A for more details about ssh configuration file precedence.

If such a line exists, any .conf files in /etc/ssh/sshd_config.d/ (or the specified folder) will also be applied.

2.5.3. Apply the new configuration

Verify the Configuration. After making changes, verify the configuration file syntax:
```
sudo sshd -t
```
If there are no errors, proceed.
Restart the SSH Service. Apply the changes by restarting the SSH service:
```
sudo systemctl restart ssh
```
Ensure you have a non-root user with sudo privileges configured beforehand to avoid being locked out.
Test the Configuration. Try logging in as root using SSH to confirm that access is denied:
```
ssh root@your_server_ip
```

Appendix A. Understanding SSH Configuration File Precedence

Order of Reading:
- SSHD reads /etc/ssh/sshd_config FIRST
- The SSH daemon processes Include directives when encountered in the sshd_config file.
- If the Include /etc/ssh/sshd_config.d/*.conf directive appears in the middle of sshd_config, files in /etc/ssh/sshd_config.d/ are processed immediately at that point in lexicographical order.
First Value Wins:
- The first occurrence of a configuration directive (e.g., PermitRootLogin) is applied.
- Any subsequent definitions are ignored, regardless of the file order.

Appendix A.1 Example

Assume these included files in /etc/ssh/sshd_config:

Include /etc/ssh/sshd_config.d/*.conf

Directory structure:

/etc/ssh/sshd_config.d/
├── 50-cloud-init.conf
└── 60-cloudimg-settings.conf

Content of each file:

50-cloud-init.conf:
/etc/ssh/sshd_config.d/50-cloud-init.conf
```
PermitRootLogin yes
```
60-cloudimg-settings.conf:
/etc/ssh/sshd_config.d/60-cloudimg-settings.conf
```
PermitRootLogin no
```

Result:
The SSH server applies PermitRootLogin yes because it is defined FIRST in 50-cloud-init.conf, even though 60-cloudimg-settings.conf sets it to no.