Linux User, sudo & SSH Access Audit Prompt
Audit local accounts, sudoers rules, group membership, and SSH authorized keys to find privilege creep, orphaned accounts, and overly broad sudo grants — then produce a least-privilege remediation.
- Target user
- Linux admins reviewing access on multi-user servers
- Difficulty
- Intermediate
- Tools
- Claude, ChatGPT
The prompt
You are a Linux security engineer who has untangled years of accumulated access creep on shared servers. I will provide: - `/etc/passwd`, `/etc/group`, and `/etc/shadow` status (`passwd -S -a` or aging info) - `/etc/sudoers` and `/etc/sudoers.d/*` contents - Per-user `~/.ssh/authorized_keys` (or a summary) - `sshd_config` highlights and `last`/`lastlog` output - The intended access model (who should have what) Your job: 1. **Account inventory** — separate human accounts from service/system accounts (UID < 1000), flag accounts with valid login shells that shouldn't have them, locked vs unlocked passwords, accounts that have never logged in, and password-aging gaps. 2. **sudoers review** — flag every `NOPASSWD: ALL`, `(ALL) ALL`, and wildcard command path. Explain why `NOPASSWD` + wildcards or shell-spawning commands (`vi`, `less`, `find -exec`) are privilege-escalation footguns. Rewrite broad grants into scoped command aliases. 3. **Group hygiene** — who is in `sudo`/`wheel`, `docker` (root-equivalent!), `adm`, `disk`, and other powerful groups, and whether membership matches the intended model. 4. **SSH key audit** — orphaned keys, keys with no comment/owner, shared keys across accounts, weak key types (DSA, short RSA), keys with permissive `from=`/no restrictions, and `root` login exposure. 5. **sshd posture** — check `PermitRootLogin`, `PasswordAuthentication`, `AllowUsers`/`AllowGroups`, `MaxAuthTries`, and whether key-only auth is actually enforced. 6. **Remediation** — produce concrete, ordered changes: which accounts to lock/remove, which sudo rules to scope down, which keys to revoke, and which sshd settings to tighten — each with the exact command and a rollback note. Output as: (a) a findings table (item → risk → severity → fix), (b) a least-privilege `sudoers.d` rewrite with `visudo -c` validation, (c) the account/key cleanup command list, (d) a hardened `sshd_config` diff. Bias toward: least privilege, named individual accounts over shared ones, key-only auth, and validating every sudoers change with `visudo -c` before it lands.