Users and sudo

Make yourself an account

First thing on a new machine, before anything else:

adduser yourname

usermod -aG sudo yourname — on Debian and Ubuntu

usermod -aG wheel yourname — on RHEL-based systems

Copy your SSH key across, log in as that user in a second terminal, and confirm sudo -i works before you close the first one. That second terminal is the difference between a mistake and a trip to the rescue system.

Then close the root door

In /etc/ssh/sshd_config:

PermitRootLogin prohibit-password
PasswordAuthentication no

Reload with systemctl reload ssh. Password login on root is what the thousands of daily brute-force attempts are hoping for; keys remove the entire category. See securing a new server and SSH access.

Lock the root password itself with passwd -l root. Console and rescue mode still work, so you are not locking yourself out.

sudo, usefully

Edit rules with visudo, never a plain editor — it validates before saving and a broken sudoers file locks everyone out of root.

Grant narrowly where you can. A deploy user that needs exactly one command:

deploy ALL=(ALL) NOPASSWD: /bin/systemctl reload myapp

That lets your pipeline reload the service without handing it the machine. Full NOPASSWD: ALL for a human account is convenient and worth thinking about twice.

Everything sudo does is logged. journalctl -t sudo is the first place to look when you want to know who did what.

Service accounts are not people

Applications get their own system users with no shell and no home directory to speak of:

useradd --system --shell /usr/sbin/nologin myapp

Nobody logs in as them, and if the application is compromised the attacker lands somewhere with nothing in it. See running your application as a service.

Groups and shared directories

When several people need to work on the same files, a shared group plus the setgid bit keeps ownership consistent:

chgrp -R developers /srv/project && chmod -R g+w,g+s /srv/project

New files inside then inherit the group automatically instead of belonging to whoever happened to create them.

When someone leaves

Have a routine, and use it the same day:

1. usermod -L to lock the account, and remove their key from authorized_keys — locking alone does not stop key login.
2. Remove them from sudo and from any shared groups.
3. Rotate anything they knew: deploy keys, API tokens, database passwords, the API key if they had one.
4. Tell us to remove them as an authorised contact — see authorised contacts.

Keep the account rather than deleting it if files belong to it; a deleted user leaves orphaned numeric ownership behind.

---

Still stuck? Mail support@novogara.com — an engineer answers, at any hour. Back to the knowledge base