Servers
Users tab
Who can log into this server, how, and with what rights — plus how to give and remove access.
Every person or program that can log into your server has an account on it. This tab shows them all. It is the answer to "who can get into this machine?" — a question worth asking twice a year, and always after someone leaves.
The list
| Column | Meaning |
|---|---|
| User | The account name |
| UID | Its numeric id. Below 1000 is usually a system account, not a person |
| Shell | /bin/bash means a person can log in. /usr/sbin/nologin means they cannot |
| Last login | When they were last here. "Never" on a person's account is a clue |
| Keys | How many SSH keys are installed for them |
Most of the accounts on any Linux server are system accounts created by software, not people. The ones to examine are those with a real shell and a home directory.
SSH keys
Select a user and you see their authorized_keys — every key that can log in
as them, with a fingerprint and any comment.
This is where old access hides. A freelancer's key stays valid forever until someone removes it. Changing the server's password does nothing to it.
Remove a key and that access stops immediately.
Actions
| Action | Notes |
|---|---|
| Create user | Optionally with a public key and sudo rights |
| Delete user | Permanent. Consider locking first |
| Lock / unlock | Blocks sign-in while keeping the account and its files |
| Change shell | Setting nologin stops interactive logins |
| Set password | For password logins |
| Add / remove SSH key | The usual way to grant and revoke access |
| Sudo | Whether they can act as administrator |
Lock rather than delete when someone leaves. Deleting can orphan files and break cron jobs that ran as them; locking stops the access immediately and is reversible.
Groups and sudo
Sudo means "may act as administrator". Give it only to people who need to install software or restart services. The list of who has it is on this tab.
The sshd settings
Two server-wide settings are shown because they decide how anyone gets in at all:
- Password authentication — whether passwords are accepted. Turning it off and using keys only is the single biggest security improvement available on a server exposed to the internet.
- Root login — whether anyone may log in directly as
root.
Change these carefully. Turning off password authentication while your own access is a password will lock you out. Make sure a key works first. The guided task Harden a new server does the steps in the safe order.
Giving a developer access
Do not share the root password. Instead:
- Ask them for their public key (the
.pubfile — see SSH keys). - Create a user for them and paste that key in.
- Give sudo only if they need it.
The guided task Give a developer access does all of this and tells you what was created. Remove someone's access reverses it. See Guided tasks.
Note that this is access to the server. To give someone access to DevOps Agent, create a team login instead — see Team members.
Permissions
Operator and above can create, lock and change users. Viewers can see the list. Every change is recorded in the Activity log.