Use personal admin accounts

Shared accounts hide who changed the system. Give each administrator their own login.

When three people share ubuntu, a sudo event cannot identify who changed Nginx. Personal accounts add lifecycle work, but let you remove one person without rotating everyone’s access.

Create a personal account

Create the account and add it to the sudo group:

sudo adduser dana
sudo usermod -aG sudo dana

Have Dana log in and confirm privilege escalation works:

sudo whoami
# root

Use an unprivileged account for normal work and sudo only for the command that needs it. Every escalation lands in the authentication log with a username attached, so a sudo systemctl restart nginx at 02:14 points to a person, not a mystery.

Review who has access

Review group membership and sudo rules on a schedule, not only when something breaks:

getent group sudo
# sudo:x:27:dana,marco
sudo ls /etc/sudoers.d/

Edit sudo rules only through visudo, which validates the syntax before saving. A typo in /etc/sudoers can lock every administrator out of root at once:

sudo visudo -f /etc/sudoers.d/deploy

Keep service accounts non-interactive unless a documented task requires a shell. An application user with a login shell and a password is an extra door nobody watches.

Remove a person cleanly

When responsibilities change, lock the account and expire it instead of deleting it right away, so file ownership and audit history stay readable:

sudo usermod -L marco
sudo chage -E 0 marco

Then remove their key from authorized_keys and their entry from any sudoers file. Deleting the account first is the common mistake: files owned by a vanished UID show up as raw numbers, and you lose the trail you may need later.

Keep one independently protected recovery identity outside normal daily use. Review its access too, because an emergency account that never expires can become the least visible administrator.

Save a list of login shells, groups, and effective sudo permissions for each administrator. Disable one test account and prove its SSH key and sudo path both fail while another administrator still has recovery access.