3.2 Log In and Switch Users in Multiuser Targets

Red Hat Certified System Administrator RHCSA

Track your progress as you read

Finished sections get a check mark.

1 Introduction & Exam Overview

1.1 Current Exam Facts 1.2 Lab Setup & Performance-Based Study Strategy

2 Essential Tools: Shell, Redirection & Text Analysis

2.1 Shell Prompt and Command Syntax 2.2 Input-Output Redirection and Pipes 2.3 grep and Regular Expressions for Text Analysis

3 Essential Tools: Remote Access, Users & Text Editing

3.1 Access Remote Systems Using SSH 3.2 Log In and Switch Users in Multiuser Targets 3.3 Create and Edit Text Files

4 Essential Tools: Files, Links & Archives

4.1 Create, Delete, Copy, and Move Files and Directories 4.2 Hard and Soft Links 4.3 Archive and Compress with tar, gzip, and bzip2

5 Essential Tools: Permissions & System Documentation

5.1 List, Set, and Change Standard ugo/rwx Permissions 5.2 System Documentation: man, info, and /usr/share/doc

6 Manage Software: RPM and Flatpak

6.1 Configure Access to RPM Repositories 6.2 Install and Remove RPM Software Packages 6.3 Configure Access to Flatpak Repositories 6.4 Install and Remove Flatpak Software Packages

7 Create Simple Shell Scripts

7.1 Conditional Execution: if, test, and [] 7.2 Looping Constructs for Files and Input 7.3 Process Script Inputs ($1, $2, and Beyond) 7.4 Process Shell Command Output in Scripts

8 Operate Running Systems: Boot and Recovery

8.1 Boot, Reboot, and Shut Down a System Normally 8.2 Boot Systems into Different Targets Manually 8.3 Interrupt the Boot Process to Gain Access

9 Operate Running Systems: Processes and Tuning

9.1 Identify and Kill CPU/Memory Intensive Processes 9.2 Adjust Process Scheduling 9.3 Manage Tuning Profiles

10 Operate Running Systems: Logs, Services & File Transfer

10.1 Locate and Interpret System Log Files and Journals 10.2 Preserve System Journals 10.3 Start, Stop, and Check Status of Network Services 10.4 Securely Transfer Files Between Systems

11 Configure Local Storage: Partitions and LVM

11.1 List, Create, and Delete Partitions on GPT Disks 11.2 Create and Remove Physical Volumes 11.3 Assign Physical Volumes to Volume Groups 11.4 Create and Delete Logical Volumes

12 Configure Local Storage: Mounting and Expansion

12.1 Mount File Systems at Boot by UUID or Label 12.2 Add Partitions, Logical Volumes, and Swap Non-Destructively

13 Create and Configure File Systems: Local FS and Permissions

13.1 Create, Mount, and Use VFAT, ext4, and XFS File Systems 13.2 Extend Existing Logical Volumes 13.3 Diagnose and Correct File Permission Problems

14 Create and Configure File Systems: NFS and autofs

14.1 Mount and Unmount Network File Systems Using NFS 14.2 Configure autofs

15 Deploy and Maintain: Scheduling, Services & Targets

15.1 Schedule Tasks with at, cron, and systemd Timers 15.2 Start, Stop, and Enable Services at Boot 15.3 Configure Systems to Boot into a Specific Target

16 Deploy and Maintain: Time, Software Updates & Bootloader

16.1 Configure Time Service Clients 16.2 Install and Update Software from CDN, Remote Repos, and Local Files 16.3 Modify the System Bootloader

17 Manage Basic Networking

17.1 Configure IPv4 and IPv6 Addresses 17.2 Configure Hostname Resolution 17.3 Configure Network Services to Start Automatically at Boot 17.4 Restrict Network Access Using firewalld and firewall-cmd

18 Manage Users and Groups

18.1 Create, Delete, and Modify Local User Accounts 18.2 Change Passwords and Adjust Password Aging 18.3 Create, Delete, and Modify Local Groups and Memberships 18.4 Configure Privileged Access

19 Manage Security: Firewall, umask & SSH Keys

19.1 Configure Firewall Settings with firewall-cmd and firewalld 19.2 Manage Default File Permissions 19.3 Configure Key-Based Authentication for SSH

20 Manage Security: SELinux Modes and Contexts

20.1 Set Enforcing and Permissive Modes for SELinux 20.2 List and Identify SELinux File and Process Contexts 20.3 Restore Default File Contexts

21 Manage Security: SELinux Ports and Booleans

21.1 Manage SELinux Port Labels 21.2 Use Boolean Settings to Modify SELinux Settings

3.2 Log In and Switch Users in Multiuser Targets

Key Takeaways Explain This Topic AI

multiuser.target is the typical multi-user, networked, non-graphical default on RHEL servers; graphical.target adds a GUI session stack on top of multi-user services.

whoami and id show your effective identity; who and w list logged-in users and sessions on the system.

su username switches user but often keeps much of the prior environment; su - username (or su -l) starts a login shell that more fully loads the target user's profile and home.

Virtual consoles (tty1, tty2, …) and remote SSH sessions both provide logins into the same multiuser environment when the system is running a multi-user target.

Default boot target is persistent: systemctl get-default / set-default control which target is reached after reboot.

Last updated: August 2026

RHEL is a multiuser operating system: many users and services can be active at once. The RHCSA objective to log in and switch users in multiuser targets means you must understand systemd targets that define the system’s operating mode, how interactive logins work, and how to change identity with su (and related tools) without losing track of environment, home directory, and privileges.

Multiuser Targets vs Graphical Targets

systemd boots the machine into a target —a synchronization point that pulls in a set of units (services, sockets, mounts).

Target Typical use What you get
multiuser.target Servers, most exam VMs Multi-user networking, text logins, no full GUI stack required
graphical.target Desktop/workstation style Multi-user features plus display manager / GUI
rescue.target / emergency.target Recovery Minimal environment for repair (covered more under boot objectives)
On many RHEL servers the default target is multiuser.target . Confirm with: systemctl get-default
Change the persistent default (survives reboot): sudo systemctl set-default multiuser.target
sudo systemctl set-default graphical.target
Switch the running system without permanently changing the default: sudo systemctl isolate multiuser.target

Isolating is immediate operational change; set-default is what EX200 cares about when the grader reboots. Remember the exam rule: if the requirement is “after reboot the system comes up multi-user without a GUI,” set-default multiuser.target is the durable fix—not only a temporary isolate.

multiuser.target still allows multiple simultaneous logins: local virtual terminals, serial consoles, and SSH sessions. “Multiuser” does not mean “only one person at a time”; it means the system is fully up for concurrent users and services.

Logging In
Local text logins

On a console, a getty presents a login prompt on a tty (for example tty1). Enter username, then password. A successful login starts a shell according to the account’s settings in /etc/passwd (shell field) and profile files.

Switch virtual consoles with Ctrl+Alt+F1 , Ctrl+Alt+F2 , and similar combinations on physical or many hypervisor consoles (exact key mapping can depend on the virtualization client). Each tty can host a different logged-in user—classic multiuser behavior.

Remote logins

SSH logins (previous section) also land you in the multiuser environment. From the system’s point of view, an SSH session is another login session associated with a pseudo-terminal (pts), visible in tools like who and w .

Identifying who you are
Always verify identity before changing system files: whoami # current effective username
id # uid, gid, and supplementary groups
id student # inspect another account without switching
Session inventory: who # logged-in users, terminals, login times
w # who + load and what each session is running
logname # original login name in some session types

These commands prevent costly mistakes—editing as the wrong user, writing into the wrong home directory, or assuming you still have root when you do not.

Switching Users with su

su (“substitute user” / “switch user”) changes the active user of your shell session. Default with no username is to switch to root (password required unless already root).

su username vs su - username
This distinction is exam-critical: su student
su - student
su -l student # same idea as su - student (login shell)

Form Shell type (typical) Environment / cwd behavior
su student Non-login shell Often keeps much of the prior environment; may stay in previous directory

su - student or su -l student Login shell Loads target user’s login profile; home and env closer to a real login

When you need the target user’s full login environment —correct $HOME , path, and profile scripts—use su - . Administrators who only run su without the dash sometimes see missing variables, wrong cwd , or tools not on PATH , then waste time debugging “broken” software that is really an environment problem.

Examples: su - # become root with login shell (root password)
su - bob # become bob with login shell
su -c 'id' alice # run one command as alice, then return

Exit the switched shell with exit to return to the previous user.

Password prompts

Switching to root with su generally requires the root password (unless policy/tools differ).

Switching to another ordinary user requires that user’s password when you are not already privileged.

sudo (covered more under security/user admin topics) can allow permitted commands as another user using your password and sudoers policy—different mechanism from su .

For this objective, master su / su - behavior and know when a login shell is required.

Root vs Ordinary Users and Home Directories

Account Typical home Notes
Regular user /home/username Owned by the user; SSH keys under ~/.ssh
root /root Not /home/root on RHEL; configs and keys for root live here

The shell expands ~ to the current user’s home. After su - alice , ~ is alice’s home. After su - to root, ~ is /root . Writing “into home” while still in an old directory or wrong user is a frequent source of “file not found” and permission errors.

Check: echo $HOME
pwd
ls -ld ~
Why Multiuser Targets Matter for Admin Work

In multiuser.target :

Network services (including sshd when enabled) can run
Multiple users can log in and switch identities to test permissions
You can validate that a service runs without relying on a GUI

RHCSA labs often assume text-mode multiuser operation. If a system is stuck in a rescue-like target or failed units prevent multiuser, logins and network services may be incomplete—tie that mental model to later boot-troubleshooting objectives.

Practical Workflows for the Exam

Confirm default target: systemctl get-default → set if the task requires multiuser or graphical after reboot.

Verify with whoami / id before editing restricted paths.

Switch to root or another account with su - when you need a proper login environment.

Run the administrative task; exit nested shells cleanly so you know which identity is active.

Reboot only when required—and ensure default target and enabled services match the specification so the state persists .

Common Pitfalls
Using su without - and then wondering why $HOME or PATH is wrong
Assuming root’s home is under /home
Changing the running target with isolate but forgetting set-default when persistence is required
Losing track of nested su sessions (run whoami often)
Expecting graphical tools when the system is correctly left on multiuser.target

If you can log in locally and remotely, prove identity, switch users with correct login-shell semantics, and set a default multiuser target that survives reboot, you have met this objective’s intent.