Linux User and Group Administration Questions

Administration of user accounts and groups on Linux systems, covering the full user lifecycle including creation, modification, deletion, and archiving. Topics include command line management with useradd, usermod, userdel, groupadd and groupdel; understanding and managing /etc/passwd, /etc/shadow, /etc/group, and /etc/gshadow; UID and GID planning; default shells and home directory configuration; password policies and aging; sudoers configuration and fine grained privilege escalation; SSH access management including key based authentication, ssh agent usage and ssh configuration; file and directory permissions (user, group, other), symbolic and octal chmod notation, chown, umask; access control lists, setuid, setgid, and the sticky bit; SELinux or AppArmor basics and how they affect access; and enterprise integration points such as LDAP, Active Directory, or RADIUS for centralized authentication. Emphasis is on secure, least privilege practices and scalable account lifecycle management for production environments.

HardTechnical

143 practiced

An attacker has replaced a user's ~/.ssh/authorized_keys across multiple servers to maintain persistent access. Describe how you would identify which keys were added and when, what logs and artefacts you would inspect across systems (including auditd, filesystem timestamps, configuration management), and how you would coordinate an automated, auditable rotation of that user's keys across the fleet.

Sample Answer

**Identify added keys and timing**

- Create a known-good baseline: collect current authorized_keys content and compute hashes and per-line fingerprints.- Compare against backups/CM repo (if present) or previous config-management commits to spot new entries and diffs.- Use filesystem metadata to get timestamps:

bash

stat -c "mtime:%y ctime:%z inode:%i" /home/USER/.ssh/authorized_keys
ls -li /home/USER/.ssh

- If inode changed, file was replaced; record mtime/ctime and host.

**Logs & artefacts to inspect**

- auth logs for SSH logins and key-based auth:

bash

# Debian/RedHat
grep "Accepted publickey" /var/log/auth.log /var/log/secure

- auditd: look for rules covering authorized_keys, sshd and user homedir writes; search audit logs for writes/creat/unlink:

bash

ausearch -f /home/USER/.ssh/authorized_keys
ausearch -m PATH -k authkeys_mod

(If no rule existed, add for future: auditctl -w /home/USER/.ssh/authorized_keys -p wa -k authkeys_mod)- Shell history and process execs: /home/USER/.bash_history, /var/log/secure for sudo/ssh-keygen/ssh-copy-id/scp/rsync/ssh, /var/log/messages, journald.- Configuration management: Git commit history in Puppet/Ansible/Chef — search for changes to authorized_keys or user resources.- File integrity tools: AIDE/Tripwire reports and previous snapshots.- Remote transfer traces: scp/rsync logs, SFTP server logs, syslog from bastion/jump hosts.- SSH server config: Check AuthorizedKeysCommand, AuthorizedKeysFile patterns and SELinux contexts (restorecon -R /home/USER/.ssh).

**Forensics best practices**

- Preserve evidence: create forensic copies (dd/rsync) and record checksums and chain-of-custody notes.- Correlate timeline: map file timestamps, audit events, SSH login events, and CM commits to identify when and from where modification occurred.- Identify which key was added: compute key fingerprint (ssh-keygen -lf) and search across fleet for same public key.

**Coordinated automated, auditable key rotation**

- Plan: generate a new key pair per-user or use centrally-issued short-lived certificates (recommended).- Preferred design: replace static keys with SSH certificates issued by a CA (ssh-keygen -s ca -I id -n user). Use Vault/PKI or an internal CA; tie lifetime to TTL.- If using keys, implement rotation via orchestration (Ansible) with these properties: - Idempotent playbook that pushes new authorized_keys to a temp file, validates syntax/permissions, and atomically replaces file. - Use secrets manager (HashiCorp Vault / AWS Secrets Manager) to store private keys and audit access. - Use change windows and staged rollout (canary -> rest) with verification tasks (attempt connection using new key from control node, check logs). - Record run metadata to centralized logging (ELK/CloudWatch) and CMDB; also generate a signed audit record per host.

Example Ansible task (concept):

yaml

- name: Deploy rotated authorized_keys safely
  copy:
    content: "{{ lookup('vault', 'secret/ssh/users/USER/public_key') }}"
    dest: /home/USER/.ssh/authorized_keys.new
    owner: USER
    mode: '0600'
- name: Verify permissions and atomic move
  command: mv /home/USER/.ssh/authorized_keys.new /home/USER/.ssh/authorized_keys

**Verification & rollback**

- Post-rotation checks: validate SSH auth logs for failures/successes, run ssh -o BatchMode=yes to verify key works, run host-level sanity checks.- Rollback: keep previous authorized_keys in versioned backup on control plane; if failed, re-deploy previous atomically.- Audit trail: log orchestration runs, store playbook output, ticket reference, CA certificate serials or key fingerprints.

**Prevention & hardening**

- Enforce auditd rules for user .ssh paths, enable AIDE, restrict homedir permissions, disable passwordless root logins, prefer SSH certificates and short TTLs, and centralize key management with rotation policy.

This approach locates added keys/times via timestamps and audit logs, preserves evidence, and implements an automated, auditable rotation using orchestration and centralized secrets or SSH CA to prevent recurrence.

MediumTechnical

91 practiced

Describe best practices for UID/GID planning across a fleet of Linux servers and shared resources (NFS, Ceph). How would you reserve ranges for system accounts, service accounts, human users, and containerized workloads to avoid collisions? Explain how you would document, enforce, and audit these assignments at scale.

MediumTechnical

78 practiced

Explain how ssh-agent and agent forwarding work. What are the security risks of enabling agent forwarding to remote hosts, and what best practices should a systems administrator follow when using agent-based authentication in an environment that includes bastion/jump hosts?

Sample Answer

**How ssh-agent & agent forwarding work**

ssh-agent holds private keys in memory and exposes a local Unix socket. When an SSH client needs to authenticate, it asks the agent to sign challenges so the private key never leaves the agent process. Agent forwarding (ssh -A or ForwardAgent yes) forwards that agent socket over the SSH connection to a remote host so you can SSH from the remote host using your local keys (the remote session can request signatures via the forwarded socket).

**Security risks**

- A compromised or malicious remote host can use the forwarded agent to authenticate to other systems while your connection exists (it can make signing requests).- Privileged users on the remote host (or root) can potentially access the forwarded socket and request signatures or hijack the connection.- Agent forwarding does NOT transmit your private key, but it effectively grants remote-time-limited signing power.- Long-lived forwarded sessions increase exposure window.

**Best practices for bastion/jump hosts (systems administrator perspective)**

- Default to ForwardAgent no; enable only for specific, trusted hosts.- Use per-host ssh config and explicit enabling:

bash

Host bastion.example.com
  HostName bastion.example.com
  ForwardAgent yes

- Prefer short agent lifetimes and require confirmations (ssh-add -t 1h; ssh-add -c) so operations prompt you.- Use hardware-backed keys (YubiKey/PIV/PKCS#11) so signing requires physical presence and mitigates remote socket abuse.- Harden bastions: minimal user software, strict logging, monitoring for use of agent socket, and restricted user accounts.- Use certificate-based SSH with short-lived certs or ephemeral keys issued by a CA instead of wide agent forwarding.- Consider ProxyJump/ProxyCommand so you hop via bastion without forwarding credentials to intermediate hosts.- Disable AllowAgentForwarding in sshd_config on hosts that should never accept forwarded agents.

**Operational controls**

- Rotate keys/certs, audit agent usage, and document when forwarding is allowed.- Train operators: only forward from trusted local workstations and only when needed.

This balances usability (convenient key use through bastions) with minimizing the attack surface.

HardTechnical

103 practiced

A daemon running as user 'svcuser' cannot write to /var/lib/app despite correct Unix permissions; audit logs show SELinux AVC denials. Describe the commands and steps you would use to diagnose the SELinux denial, how to craft a minimal policy to allow the required action, and how to apply it safely with minimal privilege expansion. Mention tools like ausearch, audit2allow, semodule and semanage.

Sample Answer

**Situation / goal**Daemon running as svcuser blocked by SELinux AVC denials when writing /var/lib/app. I would diagnose the denial, prefer fixing file/context or booleans first, and only add a minimal allow rule if needed.

**1) Diagnose the denial**- Search audit logs for recent AVCs:

bash

ausearch -m AVC -ts recent --raw | aureport -a
ausearch -m AVC -ts today | tail -n 50
# or
grep AVC /var/log/audit/audit.log | tail -n 50

- Get a human-readable message:

bash

ausearch -m AVC -ts today -i
sealert -a /var/log/audit/audit.log   # if setroubleshoot available

**2) Prefer corrective actions (least privilege)**- Check file contexts and fix them:

bash

ls -Z /var/lib/app
semanage fcontext -l | grep /var/lib/app
semanage fcontext -a -t myapp_var_lib_t "/var/lib/app(/.*)?"
restorecon -Rv /var/lib/app

- Check and toggle Booleans (may avoid new allow rules):

bash

getsebool -a | grep <relevant_bool>
setsebool -P <bool_name> on

**3) If a policy module is required (minimal allow)**- Extract AVC entries and generate a module, then review:

bash

ausearch -m AVC -ts today -c mydaemon --raw | audit2allow -m mydaemon > mydaemon.te
audit2allow -i /var/log/audit/audit.log -M mydaemon   # creates mydaemon.pp and mydaemon.te
# Inspect mydaemon.te and ensure only necessary rules exist
cat mydaemon.te

- Compile and install safely:

bash

semodule -i mydaemon.pp
semodule -l | grep mydaemon

**4) Verify and rollback plan**- Test daemon write, re-check AVCs:

bash

touch /var/lib/app/testfile; restorecon -v /var/lib/app/testfile
ausearch -m AVC -ts now -i

- To remove module if problematic:

bash

semodule -r mydaemon

**Rationale**- Always try correct labeling or booleans before add allow rules to minimize privilege expansion.- Use audit2allow to speed up drafting but manually review generated .te to prevent overbroad rules.- Use semanage/restorecon for persistent, standard fixes; use semodule only when policy is unavoidable.

EasyTechnical

75 practiced

Provide a one-liner that lists all accounts with UID 0 on a host (including accounts from local files and from NSS sources such as LDAP). Explain why having multiple UID 0 accounts is a risk in production and how you would handle an exception where a UID 0 account is required for legacy reasons.

Sample Answer

**Approach — one-liner that covers local and NSS sources**Use getent (queries NSS) and filter UID 0 entries.

bash

getent passwd | awk -F: '$3==0{print $1" (uid:"$3") home:"$6" shell:"$7}'

**Why multiple UID 0 accounts are risky**- Indistinguishable privilege: UID 0 bypasses account-level controls — all such accounts are root-equivalent.- Auditing & accountability: Logs and processes often show UID 0 only, making it hard to attribute actions to a person.- Attack surface: Extra privileged accounts increase chance of credential compromise and lateral movement.- Configuration drift: Hidden or legacy UID 0 accounts can evade patching and review processes.

**How I'd handle an exception (legacy UID 0 required)**- Approve formally with documented business justification and TTL.- Lock direct password login: passwd -l <acct> and require SSH key-only access.- Restrict access: allow only from specific hosts/networks (sshd Match, firewall).- Require MFA / certificate-based auth where possible.- Monitor & alert: deploy auditd/syslog rules to alert on UID 0 logins and commands.- Periodic review: quarterly review and rotate keys/credentials; plan for migration to sudo with full auditing.

This preserves compatibility while minimizing security risk and preserving accountability.

Unlock Full Question Bank

Get access to hundreds of Linux User and Group Administration interview questions and detailed answers.

Join thousands of developers preparing for their dream job.