Log in and switch users in multiuser targets

• Authentication (who you are) — often handled via passwords, keys, and frameworks such as PAM (Pluggable Authentication Modules).
• Access control (what you can do) — user and group permissions, file modes, ACLs, and mandatory access controls such as SELinux.
• Network and service protection — firewalling (iptables, nftables, firewalld), SSH hardening, and service isolation.
• Audit and accountability — centralized logs, sudo logs, and system accounting.

• PAM: https://www.linux-pam.org/
• SSH hardening: https://www.openssh.com/
• SELinux: https://selinuxproject.org/page/Main_Page

​

What is a user account?

• username
• password placeholder (usually an x in /etc/passwd, with the hashed password in /etc/shadow)
• UID (user ID) — unique integer
• primary GID (group ID)
• optional comment / GECOS (human-readable info)
• home directory
• default login shell

• /etc/passwd — account metadata and login shell/home
• /etc/shadow — encrypted password hashes (restricted)
• /etc/group — groups and group members

$ cat /etc/passwd
root:x:0:0:root:/root:/bin/bash
daemon:x:1:1:daemon:/usr/sbin:/usr/sbin/nologin
bin:x:2:2:bin:/bin:/usr/sbin/nologin
sys:x:3:3:sys:/dev:/usr/sbin/nologin
sync:x:4:65534:sync:/bin:/bin/sync
games:x:5:60:games:/usr/games:/usr/sbin/nologin
man:x:6:12:man:/var/cache/man:/usr/sbin/nologin
lp:x:7:7:lp:/var/spool/lpd:/usr/sbin/nologin
mail:x:8:8:mail:/var/mail:/usr/sbin/nologin
uucp:x:10:10:uucp:/var/spool/uucp:/usr/sbin/nologin
www-data:x:33:33:www-data:/var/www:/usr/sbin/nologin
bob:x:1000:1000:Bob Kingsley,,,:/home/bob:/bin/bash
michael:x:1001:1001::/home/michael:/bin/sh

$ cat /etc/group
ssh:x:118:
lpadmin:x:119:
scanner:x:120:saned
avahi:x:121:
saned:x:122:
colord:x:123:
geoclue:x:124:
pulse:x:125:
pulse-access:x:126:
gdm:x:127:
systemd-coredump:x:999:
bob:x:1000:
developers:x:1003:bob,michael

​

Account field breakdown (quick reference)

$ id michael
uid=1001(michael) gid=1001(michael) groups=1001(michael),1003(developers)

​

Account types

• User account — for a person who needs access.
• Superuser (root) — UID 0; unrestricted privileges.
• System accounts — created for OS services; often have low UIDs and no interactive shell.
• Service accounts — created for specific applications (e.g., nginx, mysql).

​

Useful user-related commands

$ id
uid=1000(michael) gid=1000(michael) groups=1000(michael)

$ who
bob      pts/2        Apr 28 06:48   (172.16.238.187)

$ last
michael  :1   :1        Tue May 12 20:00  still logged in
sarah    :1   :1        Tue May 12 12:00  still running
reboot   system boot 5.3.0-758-gen  Mon May 11 13:00 - 19:00 (06:00)

​

Switching users: su vs sudo

​

su (substitute user)

• su starts a shell as another user and typically requires the target user’s password.
• su - opens a login shell, loading the target user’s environment.
• Useful for interactive sessions, but less auditable because commands aren’t centrally logged by sudo.

$ su -
Password:
root@host:~#

$ su -c "whoami"
Password:
root

​

sudo (delegate privileges)

• sudo lets authorized users run commands as another user (commonly root) by authenticating with their own password.
• Sudo policies are configured in /etc/sudoers and in files under /etc/sudoers.d/.
• sudo provides better auditing and fine-grained privilege delegation.

michael@ubuntu-server:~$ sudo apt-get install nginx
[sudo] password for michael:

# /etc/sudoers - example entries
User privilege specification
root    ALL=(ALL:ALL) ALL
# Members of the admin group may gain root privileges
%admin ALL=(ALL) ALL
# Allow members of group sudo to execute any command
%sudo   ALL=(ALL:ALL) ALL
# Allow bob to run any command
bob     ALL=(ALL:ALL) ALL
# Allow sarah to reboot the system
sarah   localhost=/usr/bin/shutdown -r now
# See sudoers(5) for more information on "#include" directives: https://man7.org/linux/man-pages/man5/sudoers.5.html
#includedir /etc/sudoers.d

• Grant full root access to a user: username ALL=(ALL:ALL) ALL
• Grant a group limited privileges: %developers ALL=(ALL) /usr/bin/systemctl restart myservice

​

Best practice: avoid direct root logins

• Disable direct root SSH access (set PermitRootLogin no in /etc/ssh/sshd_config).
• Encourage administrators to use sudo for privilege escalation. This enables accountability, because sudo logs which user ran which command.

​

Summary and next steps

• User and group accounts are the foundation of Linux access control. Their metadata lives in /etc/passwd and /etc/group.
• Use id, who, and last to inspect accounts and sessions.
• Prefer sudo over su for privilege escalation because sudo is auditable and configurable.
• Edit sudoers only with visudo to avoid syntax errors.
• Practice creating users, placing them in groups, and configuring sudo policies in a lab environment.

• Kubernetes Basics (for context on multiuser environments)
• PAM (Pluggable Authentication Modules)
• Sudoers manual (man 5 sudoers)
• SELinux Project

• Create two users, add them to a shared group, and verify file permissions for group members.
• Configure a sudo rule that allows a non-root user to run a single administrative command.
• Disable direct root SSH access and confirm you can still perform administrative tasks using sudo.