Creating an OS User on Ubuntu: A Step-by-Step Guide

In the modern realm of server administration, creating a dedicated OS User is a fundamental step to enhance security and streamline various processes. By isolating services and users, you minimize the "blast radius" of potential security breaches. In 2026, as automated threats and sophisticated exploits become more prevalent, moving away from shared accounts or root access is no longer just a best practice; it is a critical necessity for compliance and system integrity.

Beyond simple access control, a dedicated OS User allows for granular auditing, precise resource allocation via cgroups, and the implementation of Zero Trust principles at the local system level. Whether you are deploying a microservice, hosting a web application, or setting up a CI/CD runner, ensuring each process runs under its own OS User ensures that a single vulnerability does not compromise your entire infrastructure. In this article, we will guide you through the process of creating an OS User on an Ubuntu server, updated for 2026 security standards, including modern SSH hardening and directory permission protocols.

Step 1: Generate an RSA Key Pair Locally for the OS User

Start by generating an RSA key pair on your local machine. While Ed25519 is often preferred in 2026 for its speed and shorter key lengths, RSA remains a robust standard for broad compatibility across legacy systems and modern cloud environments. By generating these keys locally, you ensure that the private portion of the OS User credentials never traverses the network, adhering to the "private keys stay private" security pillar.

Code:-

Code

$ ssh-keygen -t rsa -f my-key
            

Replace my-key with any name you would like, such as the name of the specific OS User or the server's hostname. Note that we specify -b 4096 to ensure the OS User has a strong encryption level; in 2026, the standard 2048-bit RSA keys are increasingly viewed as the bare minimum, making 4096-bit the recommended choice for future-proofing against brute-force advancements.

When prompted for a passphrase, leave it blank for simplicity in this example, though in production environments, adding a passphrase provides an extra layer of "Two-Factor" protection for the OS User. This command creates two distinct files: my-key (the private key, which you must protect) and my-key.pub (the public key, which will be uploaded to the server).

Step 2: Log in to Your Server and Create the OS Use

Now, it's time to log in to your Ubuntu server via your primary administrative account to provision the new environment. Choosing a descriptive and unique identifier for your OS User is vital for maintaining clear audit logs and process tracking. In the landscape of 2026, many administrators use functional names (e.g., web-deployer or db-monitor) to clearly define the scope of the OS User.

Code:

Code

$ USERNAME=<your-username>
            

Code

Code

$ sudo adduser --home /home/$USERNAME --shell /bin/bash --disabled-password
            

Code

Code

$ USERNAME
            

By using the --disabled-password flag, you are implementing a "Key-Only" authentication policy for the OS User. This is a significant security upgrade as it mitigates the risk of brute-force password attacks, which remain a top threat vector in 2026. This command does more than just add a name to a list; it initializes a secure home directory, sets up environment profiles, and assigns a dedicated UID (User ID) and GID (Group ID) to ensure the OS User remains isolated from other system entities.

Follow the prompts to provide any additional information, such as the full name or room number, to associate with the new OS User. While these fields are optional, they provide valuable metadata for large teams managing hundreds of ephemeral cloud instances. This structured approach ensures that every OS User on your Ubuntu system has a predictable, clean, and secure starting point.

Step 3: Configure the OS User with the Generated Key Pair

Switch to the newly created OS User and configure it to use the RSA key pair generated in Step 1. This stage is critical because it establishes the cryptographic handshake between your local machine and the server. In 2026, manual configuration of these files requires strict adherence to permission standards, as modern SSH daemons will reject keys stored in directories with overly permissive "read/write" access for other users.

Code

Code

$ sudo su - $USERNAME
            

Code

Code

$ cd ~ && mkdir .ssh && touch .ssh/authorized_keys
            

By using mkdir -p and chmod 700, you ensure the .ssh directory is accessible only by the OS User, preventing other non-privileged users on the system from even listing the directory contents.

Code

Code

$ PUBKEY="<copy the contents of public key github-actions.pub>"
            

Code

Code

$ echo $PUBKEY | tee -a ~/.ssh/authorized_keys
            

Code

Code

$ chmod 600 ~/.ssh/authorized_keys
            

The chmod 600 command is a vital security hardening step for the OS User; it restricts the authorized_keys file so that only the owner can read or write to it. This prevents "lateral movement" attacks where a compromised user might attempt to inject their own keys into another user's profile.

Code

Code

$ exit
            

These commands switch to the new OS User, create the necessary directory structure with hardened permissions, and configure the authorized keys file for secure SSH authentication. By completing this step, you have moved from password-based vulnerability to a robust, identity-based access model for your OS User.

Step 4: Optional - Granting sudo Access to the OS User

If you require administrative privileges for this OS User, you can grant sudo access. In the infrastructure landscape of 2026, granting elevated privileges is often necessary for automation tasks, such as running Docker commands, managing systemd services, or performing package updates via script. However, this power should be granted following the "Principle of Least Privilege" (PoLP) to maintain a secure environment.

Code

Code

 $ echo "$USERNAME ALL=(ALL) NOPASSWD:ALL" | sudo tee -a /etc/sudoers
            

This command adds the OS User to the sudoers file, allowing them to execute commands with elevated privileges without a password prompt. While the NOPASSWD configuration is highly efficient for CI/CD pipelines and automated deployments where an interactive prompt would stall the process, it requires the OS User's private SSH key to be guarded with extreme care.

By using tee -a, we ensure that we append to the configuration rather than overwriting existing permissions, preserving the access rights of other administrative accounts. In a modern 2026 security workflow, it is also recommended to create a specific file for the OS User in /etc/sudoers.d/ instead of editing the main file, which ensures cleaner system upgrades and easier auditing of which OS User has been granted high-level access.

Step 5: SSH into the Server as the New OS User

To demonstrate the OS User ability to SSH into the server, use the following command from your local terminal. This final step verifies that the cryptographic handshake is functioning correctly and that the permissions set in the previous steps allow for a secure connection. In the connectivity standards of 2026, verifying your identity through a private key is the gold standard for preventing "Man-in-the-Middle" (MITM) attacks.

Code

Code

$ ssh -i <path-to-my-key><your-username>@<your-server-ip-or-hostname>
            

Replace <path-to-my-key> with the actual path to the private key created in Step 1 (e.g., ~/.ssh/my-key). Replace <your-username> with the specific OS User name you chose in Step 2, and replace <your-server-ip> with the actual IP address or hostname of your server.

Upon execution, your local SSH client presents the private key to the server. The server then uses the public key stored in the OS User authorized_keys file to challenge the client. Because the OS User was created with a disabled password, this key-based entry is the only gateway, providing a robust defense against automated botnets. Once the connection is established, you should see the Ubuntu command prompt, confirming you are now logged into the server as the newly created OS User, leveraging the full security of modern SSH key authentication.

Conclusion: Securing Your Infrastructure with a Dedicated OS User

Mastering the creation and management of a dedicated OS User is more than a technical hurdle; it is a foundational pillar of modern cybersecurity. By following this guide, you have moved beyond risky root-level operations and implemented a high-security, key-only authentication workflow. In the fast-evolving landscape of 2026, where cloud-native environments and automated deployment pipelines are the norm, these practices ensure your Ubuntu servers remain resilient against unauthorized access and lateral movement threats.

Maintaining a secure environment requires constant vigilance and expert oversight. If you are looking to scale your infrastructure or need specialized expertise to build and manage your cloud environments, you can Hire Software Development experts from our team to streamline your DevOps and server hardening processes. We specialize in comprehensive OS User management and infrastructure automation to keep your digital assets safe and compliant.

Ready to Secure Your Servers?

At Zignuts, we help businesses build robust, scalable, and secure digital foundations. If you have questions about server security or need assistance with complex Ubuntu configurations, our team is ready to assist you. Contact Zignuts today to speak with our technical experts and take your server administration to the next level!