How to Switch User in Ubuntu

Any Linux distribution, including Ubuntu, is a system that often finds itself at the intersection of interests, as the same server can serve developers, administrators, CI/CD processes, service accounts, and sometimes business users. The picture can be just as complex on a workstation, with the existence of a primary user, service accounts, temporary accounts, and test environments.

One of the most common tasks is how to switch between users correctly in Ubuntu.

If you think about it, this is not a matter of "enter a command and forget about it". It's about security, convenience, control of the environment, and a clear understanding of who is currently working in the system and in what context. In this article, we have attempted to provide you with a detailed practical analysis of all the main ways to switch between users in Linux, their differences, and the pitfalls of using each method. Every engineer or administrator must understand the differences between these methods and have a deep understanding of how they work in order to prevent system compromise.

 

 

 

 

Why switch between users at all?

If you have been working with Linux for more than a day, then you are already familiar with the basic idea: one user - one area of responsibility. But in practice, switching between users is not just a formality, and certainly not a relic of old Unix traditions.

In modern systems, such as Ubuntu, users are not only people, but also processes, services, automation pipelines, containers, deployment and monitoring agents, etc. Each of them lives in its own context, with its own rights, environment variables, home directory, access keys, and command history. And when this context is disrupted, problems arise that are difficult to diagnose and even more difficult to reproduce.

The wrong user executing a particular command can lead to subtle access rights errors, broken dependencies, strange application behavior, and security vulnerabilities. This is especially common on servers and VPS, where several roles run on the same system.

That's why the ability to consciously switch between users is a basic skill not only for system administrators, but also for developers, DevOps engineers, and anyone who works with production systems. We are talking about control, predictability, and responsibility, not just the convenience of a single command in the terminal.

 

Now let's take a look at why this is necessary in practice and what tasks can be solved by correctly separating users.

• Separation of access rights between regular users and administrators;
• Working with service accounts (deployment, CI/CD, cron, systemd);
• Testing applications on behalf of another user;
• Support for multi-user environments on a server or VPS;
• Minimizing risks when working with sensitive commands.

 

Ubuntu is quite liberal with sudo access by default, but that is precisely why it is especially important to understand what you are doing and in what context, rather than just executing commands “automatically". This model is convenient for getting started and everyday work, but it easily blurs the line between regular users and administrators.

Over time, this leads to commands with elevated privileges being executed without proper analysis of the consequences, for example, file owners are changed, artifacts with incorrect permissions are created, environment isolation is violated, etc. In small systems, this may go unnoticed, but in a server or multi-user environment, such minor issues quickly turn into real problems.

Therefore, it is important not just to have sudo access, but to manage it consciously, choosing the appropriate switching method depending on the task, rather than out of habit or convenience.

 

Practical scenarios where switching is critical

• Checking file access rights on behalf of www-data;
• Running database migrations on behalf of the application user;
• Diagnosing bugs that depend on environment variables;
• Working on a server with multiple administrators;
• Debugging problems that only occur for a specific user.

 

 

 

 

 

Switching users in the Ubuntu graphical interface

So, let's move on to practice and start with the most obvious option - switching users via the Ubuntu graphical interface. This method is familiar to most users and is most often used on personal computers, workstations, and laptops, where the system runs in interactive mode.

GUI switching is perceived as something simple, familiar, and therefore safe, but behind its external clarity and simplicity lies a fully-fledged session management mechanism. Each user is allocated their own space, consisting of a separate set of processes, environment variables, desktop configurations, and access rights. From the system's point of view, this is not a simplified mode, but the same isolated user contexts as when logging in via a terminal or SSH.

It is important to understand in advance that graphical switching is not a way to “temporarily become another user", but rather the creation of a parallel user session. That is why this option is great for local work, but is rarely used in a server environment, where there is no graphical shell and priority is given to terminal access.

 

In the standard Ubuntu (GNOME) environment:

1. In the upper right corner of the screen, a system menu opens, combining network, sound, and power indicators. This is a single control panel for the session and system status.
2. Select Switch User from the menu, after which the current desktop is hidden and the system returns the user to the login screen.
3. The current user session is not terminated, and all running applications, processes, and open files remain active and continue to run in the background.
4. The new user logs in as usual, by entering a password or using a configured authentication method.
5. After logging in, a separate, completely isolated session is created with its own set of processes, environment variables, and user settings.
6. Access rights are not inherited, meaning that if a new user is not part of the sudogroup, they will not receive administrative rights, even if the previous session had them.
7. Multiple active user sessions can exist simultaneously in the system, and you can switch between them without losing your state.

Important! Specific steps may vary depending on the OS version and specific build.

 

These are parallel sessions, each with its own processes, environment variables, and desktop. This is very convenient for a local machine, but almost useless on servers where there is simply no graphical environment.

 

 

 

 

 

The su command is a Unix classic

The su command is one of the oldest ways to switch users in Unix-like systems.

By default:

• su without parameters switches to root;
• the target user's password is required;
• the environment is partially changed.

And this is where the confusion begins.

If you use just su, you change the user, but you don't completely change the environment. The working directory, environment variables, and PATH may remain from the previous user. Sometimes this is convenient, but more often than not, it is a source of elusive errors.

 

Therefore, in practice, login mode is almost always used:

su - username # or su --login username 

 

The difference between su and su --login

Command	User changes	Environment	Profile files loaded	Session type
su	yes	partial	no	non-login
su -	yes	full	yes	login
su --login user	user	full	yes	login

 

 

 

 

 

Command sudo su- a quick but dangerous way

If suis a Unix classic, then sudo sucan truly be called its dark side. Formally, the command looks harmless, but in essence it bypasses several important principles on which the Ubuntu security model is based.

From a technical point of view, the following happens:

• you use sudo, confirming that you have the right to execute privileged commands;
• the system gives you root privileges based on your sudo access;
• an interactive shell is launched on behalf of root, within which you continue to work.

At the same time, the root user password is not required at all, and your own sudo access is used. On Ubuntu servers, root is often locked by default or does not have a password set, which makes sudo su such a popular way to quickly become root.

The problem is that this approach blurs the line of responsibility. When you run sudo su, you stop working as a specific user and switch to an implicit root context, where it becomes difficult to clearly determine who executed the commands and with what intentions.

And this is where the serious nuance that is often ignored until the first incident occurs comes into play: sudo su violates audit transparency and complicates control over actions in the system.

Why sudo su breaks auditing

• It is difficult to track who exactly executed the commands in the logs;
• The command history gets mixed up;
• Transparency of actions is lost when there are multiple administrators;
• Incident investigation becomes more difficult.

That is why in a professional environment, sudo su is either used very consciously or not at all.

 

 

 

 

The sudo -i command is the correct way to become root

If you need root access, not just a temporary user switch, then sudo -i is rightly considered the gold standard in Ubuntu and most modern Linux distributions.

Unlike sudo su, this command initiates a full root user login session, as close as possible to a real login. The standard root user configuration files are loaded, the working environment is initialized correctly, and a separate command history is formed.

Why this is so important in practice:

• A full root login session is created, rather than a temporary shell without an explicit context.
• The environment and variables are initialized predictably and identically on each login.
• The command history remains clean and logically associated with a specific session.
• System logs retain accurate information about who gained root access via sudo and when.

 

That is why sudo -i is considered the most secure and transparent way to work as root, especially on servers, VPS, and in production environments where control, auditing, and reproducibility of actions are important.

 

 

 

 

The sudo -u command as a one-time execution on behalf of another user

Sometimes there is really no need to “become” another user and change the entire working context. Much more often, you need to execute one specific command on behalf of the desired user without leaving your session and without disrupting the environment.

For such tasks, there is the sudo -ucommand, which allows you to run processes on behalf of another user. For example:

sudo -u www-data ls /var/www

sudo -u deploy ./deploy.sh

sudo -u postgres psql

 

In all these cases, the command is executed with the privileges of the specified user, but you do not switch to their shell or create a separate session.

Typical scenarios for using the sudo -ucommand:

• running scripts on behalf of a service user or application user;
• executing migrations and maintenance commands in the correct context;
• checking access to files and directories without changing owners;
• working with services, daemons, and their data.

 

The key advantage of sudo -u is that you remain in your user session, the system environment is not broken, and exactly the action you need is performed. Thanks to this, sudo -u is considered a precise and almost surgical tool and is widely used by DevOps engineers and administrators in production environments, where it is important to minimize side effects and maintain transparency of actions.

 

 

 

 

Switching users via SSH

On servers and VPS, everything is simpler and at the same time stricter than on desktops. Terminal access is almost always used here, and any user actions are clearly tied to a specific session and context.

In the SSH model, each user is a separate point of entry into the system. Switching between users does not mean changing roles within an existing session, but establishing a new SSH connection. This automatically creates a new context for executing commands, taking into account their own environments, variables, access rights, and activity history.

This is why this approach is considered the gold standard for server environments. It is indeed:

• Secure — each user is authenticated separately;
• Transparent — the logs clearly show who connected and when;
• Ideal for production — eliminates implicit context switching.
•  

Recommendations for secure work with users via SSH

In real infrastructure, the following principles are usually followed:

• Use SSH keys instead of passwords for all administrative users.
• Disable PermitRootLoginto prevent direct login as root.
• Create a separate account for each administrator or engineer.
• grant sudo access only where it is really necessary;
• clearly separate roles and responsibilities between users.

You can read more about configuring SSH on a server here.

This approach may seem less convenient than a quick su or sudo su, but it is precisely this approach that ensures maximum system manageability and predictability. It is no coincidence that many administrators refuse to use su on servers, preferring separate SSH users and keys.

This is slightly slower in everyday work, but in the long run it is much more reliable, especially in multi-user and production environments.

 

 

 

 

Common mistakes and unexpected effects

Even experienced Ubuntu users regularly make the same mistakes, especially when working with users becomes routine and is done “automatically”:

• Working as root without real need Increases the risk of accidental changes to the system and makes it more difficult to find the source of the problem if something goes wrong.
• Confusion with the environment when using su without the login flag. Commands are executed on behalf of another user, but with the variables and paths of the previous session, which leads to difficult-to-explain application behavior.
• Forgotten background processes of another user Services, scripts, or tasks continue to run after switching sessions, consuming resources and creating unexpected side effects.
• Incorrect file permissions after sudoFiles and directories suddenly belong to root or a service user, causing applications to stop working properly.
• Unobvious context mixing Commands are run at the right time but by the wrong user, which is especially critical for deployment, migrations, and data operations.

Linux does not forgive carelessness, but it almost always shows the consequences honestly. If something goes wrong, in most cases the problem is not with Ubuntu as a system, but with the context and user name under which the command was executed. That is why conscious user and session management is not a simple formality, but an important part of reliable system operation.

 

 

 

 

Frequently asked questions

 

Can I always work as root?

Technically, yes, the system does not prohibit this. In practice, it is highly discouraged. Constant work as root increases the risk of accidental errors, makes many actions irreversible, and significantly complicates the search for the cause of a problem. In addition, when working as root, audit transparency is lost: it becomes more difficult to understand who executed certain commands and why, especially in a multi-user environment.

 

How is sudo -i better than sudo su?

sudo -i creates a full root user login session with a correctly initialized environment, correct variables, and clear logging. Unlike sudo su, this method does not blur the context and fits better into the Ubuntu audit model. That is why sudo -i is considered the preferred option for administrative tasks.

 

Is it dangerous to use su?

su itself is not dangerous if used consciously. It is recommended to use su --login or su - to get a full session of the target user with the correct environment. The main danger arises when using su without the login flag, when the user changes but the environment remains the same.

 

Do you need to know the root password in Ubuntu?

In most cases, no. By default, Ubuntu uses the sudo access model, where the root password is either not set or locked. The system is managed through sudo, which allows you to maintain control, audit, and flexibility of access rights.

 

What is best to use in production?

For production systems, the optimal model is considered to be one with separate users, SSH keys, the minimum necessary privileges, and the use of sudo -i only when root access is really needed. This approach increases security, simplifies auditing, and makes system behavior more predictable.

 

Can different switching methods be combined?

Yes, and in practice this is almost always done. For example, sudo -uis used for everyday tasks, sudo -iis used for administrative tasks, and access to the server is organized through SSH users. The main thing is to understand in what context and for what purpose each method is used.

 

When is graphical user switching a bad idea?

Graphical switching is not suitable for servers, VPS, and any production environments without a GUI. In addition, it does not replace administrative tools and does not provide additional privileges. It is a convenient mechanism for local work, but not for system administration.

 

 

 

 

Conclusions

So, switching between users in Ubuntu is not just a set of commands or a convenient technique for everyday work, but a reflection of the basic principles of Linux, such as a clear separation of roles, minimal necessary privileges, and conscious control over the context of command execution.

And the deeper you dive into working with the system, whether it's server administration, DevOps practices, application development, or production infrastructure operations, the more important it is to understand at every moment which user you are acting on behalf of and in what environment. Mistakes here rarely seem critical at first, but they are often the cause of inexplicable failures and security issues.