Working as root all the time is the default on a fresh VPS and the arrangement you should leave behind within the first hour. Every command runs with full authority, mistakes have no floor, and nothing distinguishes you from anyone who obtained your key.
Create a user and give it sudo
adduser jane usermod -aG sudo jane
The group is sudo on Debian and Ubuntu, and wheel on RHEL-family systems. Adding the wrong one leaves a user who cannot escalate, and the error appears only when they try.
Then copy your key to the new user so you can log in as them, and test that login in a second terminal before closing the one you are in. Confirm you can run a command with sudo as well as connect; a working login without working escalation is only half the job.
Then disable root login
Once the new account works, in /etc/ssh/sshd_config:
PermitRootLogin no PasswordAuthentication no
The first stops direct root access. The second is the more valuable of the two. It removes password guessing entirely, and every automated attack on port 22 is guessing passwords.
Reload SSH and test from a new terminal while the current one stays open. That habit is what turns a mistake into a correction instead of a lockout. Securing your VPS goes into the rest of the hardening.
Why sudo is better than root, concretely
Three reasons, and the third is the one people miss.
It is logged. Every sudo command records who ran what and when. Root commands record only that root did something.
It requires intent. Typing sudo is a small pause before a destructive command, and that pause catches real mistakes.
It is revocable per person. Removing someone from the sudo group removes their access without changing anything for anyone else, which is impossible when everyone shares root.
One account per person
Shared accounts undo the logging. When three people use admin, the log tells you a command was run and not who ran it.
An account each also means offboarding is one command instead of a password change everybody has to be told about.
The same applies to keys: each person gets their own key on their own account. A key file passed between people is a shared password with extra steps.
Restrict sudo when it fits
Full sudo grants everything. For someone who only needs to restart a service, that is more than the job requires.
The sudoers file can grant specific commands to specific users. Edit it with visudo rather than directly: it validates the syntax before saving, and an invalid sudoers file means nobody can escalate at all, on a server where you just disabled root login.
That combination is one of the genuinely difficult ways to lock yourself out, and visudo is the entire prevention.
Service accounts are not people
Applications should run as their own user, with no login shell and no sudo.
The reason is containment: a compromise of the application then has the application's access instead of a person's, and cannot escalate. An application running as root has no such limit, and a flaw in it is a flaw with full system access.
Give each application its own account instead of one shared "apps" user, so a compromise of one does not reach the others' files.
Keys, not passwords
Key authentication removes guessing as a route entirely: there is nothing to guess.
Put a passphrase on the private key so a stolen laptop is not a stolen server, and use an agent so you are not typing it constantly.
Review ~/.ssh/authorized_keys for each account occasionally. Keys accumulate: a contractor's key from a project two years ago is a working credential nobody is watching. Connecting via SSH sets out setting them up.
Remove people properly
When someone leaves, do three things.
Lock or delete their account. Remove their key from every authorized_keys file, including root's and any service account they helped set up. And rotate any shared credential they knew: database passwords, API tokens, the control panel login.
The second one is the step that gets missed, and a key left in a file nobody looks at outlives the person's employment indefinitely.
Check what exists now
On a server you inherited, find out who can get in before assuming:
getent passwd | grep -v nologin getent group sudo
The first lists accounts with a usable shell; the second lists who can escalate. Then read every authorized_keys file on the system.
Anything you cannot account for should be disabled rather than deleted at first, disable it, see what breaks, and remove it a week later when nothing has. Server hardening goes into the wider audit.
Agent forwarding makes onward connections easy and lets that machine use your keys. There is more on when to enable it in How to Use SSH Config, Jump Hosts and Key Agents.
Read what sudo actually permits
Granting elevation is usually done once and reviewed never, and the effective permission is wider than most people assume.
sudo -l -U username grep -rn '' /etc/sudoers.d/ 2>/dev/null | head grep -vE '^#|^$' /etc/sudoers 2>/dev/null | head
Full elevation means the account can do anything, including reading every file and becoming any other user. That is appropriate for an administrator and excessive for a deployment account.
Read it per user rather than trusting the group membership. An account in an administrative group has full access whether or not anybody remembers adding it there.
Restrictions that do not restrict
Limiting elevation to specific commands is a good instinct and several common entries are equivalent to full access.
Permitting an editor allows running any command from inside it. Permitting a package manager allows installing anything, including something that grants more. Permitting a shell script the user can edit allows anything at all.
ls -la /usr/local/bin/*.sh 2>/dev/null | head sudo -l -U deploy 2>/dev/null | grep -iE 'vi|vim|nano|less|find|awk|python|perl|sh|bash'
Where a restriction is intended to be real, the permitted command must be one the user cannot modify and one that does not let them run something else. That rules out most of what people list first.
Removing a person takes more than one step
An account disabled in one place frequently remains usable through another.
passwd -l username usermod -s /usr/sbin/nologin username grep -c . /home/username/.ssh/authorized_keys 2>/dev/null crontab -l -u username 2>/dev/null | grep -vc '^#'
Locking the password does nothing to key based access, which is how most access actually happens. The authorised keys file has to be dealt with separately.
Scheduled jobs belonging to the account keep running after the person leaves, which is either a service that must be moved or a task nobody owns. Read both before concluding the removal is complete. Managing SSH keys covers the key side.