Users, sudo & SSH

In this module, you'll learn to:

• Create users and groups, and read the files that define them
• Grant narrow, auditable sudo rights instead of full root
• Sign in with SSH keys through a jump host, and harden the SSH server safely

Before you start: finish Files, Inodes & Permissions. This lab uses two extra VMs, so you'll need about 2 GB more free memory.

Users and groups

Every process on Linux runs as a user, identified by a number called a UID. Users belong to groups (GIDs), and permissions are checked against both. Three files hold the details:

# /etc/passwd: one line per user (readable by everyone; no passwords in it)
# name:x:UID:GID:comment:home directory:login shell
grep ubuntu /etc/passwd

# /etc/shadow: the password hashes, readable only by root
sudo grep ubuntu /etc/shadow

# /etc/group: groups and their members
grep sudo /etc/group

id                 # your UID, primary group, and every group you're in

UIDs below 1000 are system users, created for services such as www-data for a web server. They usually have /usr/sbin/nologin as their shell, so nobody can sign in as them. Running each service as its own unprivileged user limits the damage if that service is broken into.

sudo useradd -m -s /bin/bash carol   # -m creates a home directory
sudo passwd carol                     # set a password
sudo usermod -aG devteam carol        # ADD carol to a group (note the -a)
sudo userdel -r carol                 # delete carol and her home directory

usermod -G without -a replaces all of a user's extra groups with the ones you list. On a server, that can silently remove someone's admin rights.

sudo, and how narrow it can be

sudo lets an allowed user run a command as root, and records who ran what. On Ubuntu, members of the sudo group can run anything. That's convenient on your laptop, but too broad for a deploy pipeline or an on-call rota. The rules live in /etc/sudoers and in files under /etc/sudoers.d/.

Always edit them with visudo. It checks the syntax before saving. A typo saved straight into /etc/sudoers can stop sudo working for everyone, and then you'd need root to fix it.

# Let the user "deploy" restart one service, and nothing else
sudo useradd -m -s /bin/bash deploy
sudo visudo -f /etc/sudoers.d/deploy

Add this line in the editor, then save:

deploy ALL=(root) NOPASSWD: /usr/bin/systemctl restart ssh

sudo -l -U deploy                            # what may deploy run?
sudo -u deploy sudo systemctl restart ssh    # allowed, with no password
sudo journalctl _COMM=sudo -n 5              # the audit trail: who ran what

How SSH proves who you are

Passwords can be guessed, phished, and reused. SSH keys work as a pair. The private key stays on your laptop and never leaves it. The public key is copied to every server you're allowed to sign in to, into ~/.ssh/authorized_keys for that user.

# On your laptop (Windows 10/11, macOS, and Linux all include ssh)
ssh-keygen -t ed25519 -C "you@laptop"
# Press Enter for the default location, and set a passphrase.

# Show the PUBLIC key; this is the part you share
cat ~/.ssh/id_ed25519.pub

Key-only SSH through a jump host

Real servers usually aren't reachable from the internet directly. You sign in to a bastion (or jump host) first, and hop from there to the server. Build that with two VMs. Save this as keys.yaml on your laptop, pasting in your own public key:

#cloud-config
ssh_authorized_keys:
  - ssh-ed25519 AAAA...your public key... you@laptop

multipass launch 24.04 --name bastion --cloud-init keys.yaml
multipass launch 24.04 --name app --cloud-init keys.yaml
multipass list          # note both IP addresses

Add this to ~/.ssh/config on your laptop, using the IP addresses from multipass list:

Host bastion
    HostName 192.168.x.10
    User ubuntu

Host app
    HostName 192.168.x.11
    User ubuntu
    ProxyJump bastion

ssh app                     # connects to bastion, then hops to app
scp notes.txt app:/tmp/     # file copies use the same route

ProxyJump keeps your private key on your laptop. The bastion only relays the encrypted connection, so a compromised bastion can't steal your key. In production, the app server's firewall or cloud security group would also accept SSH only from the bastion.

Change sshd without locking yourself out

On Ubuntu, the SSH server reads /etc/ssh/sshd_config, which starts by including every file in /etc/ssh/sshd_config.d/. For each setting, the first value sshd reads wins, and the included files are read in name order. So put your changes in an early-numbered file:

# On app: forbid passwords and direct root sign-in
sudo tee /etc/ssh/sshd_config.d/10-hardening.conf <<'EOF'
PasswordAuthentication no
PermitRootLogin no
EOF

Now follow the safe sequence. Skipping it is how people lock themselves out of servers they can't reach any other way:

1. Keep your current session open. It stays connected even if the new configuration is broken.
2. Check the syntax: sudo sshd -t prints nothing when the configuration is valid.
3. Check the result: sudo sshd -T | grep -Ei 'passwordauth|permitroot' shows the values sshd will actually use.
4. Apply it: sudo systemctl restart ssh.
5. Test from a second terminal: run ssh app again. Close the first session only once this works.

The key the server keeps refusing

A new teammate, dev, needs to sign in to app. Someone set up their account, then "made their home directory shareable" so the team could drop files in it. Now dev can't sign in. Set it up on app, reusing your own key for the test:

# On app
sudo useradd -m -s /bin/bash dev
sudo mkdir -p /home/dev/.ssh
sudo cp ~/.ssh/authorized_keys /home/dev/.ssh/
sudo chown -R dev:dev /home/dev/.ssh
sudo chmod 700 /home/dev/.ssh
sudo chmod 600 /home/dev/.ssh/authorized_keys
sudo chmod 777 /home/dev          # "made it shareable"

# On your laptop
ssh dev@app
# dev@app: Permission denied (publickey).

Your job: find out why the server refuses a key that is definitely in authorized_keys, and fix it. Try it before opening a hint.

Key terms

• UID and GID: the numbers that identify a user and a group. UIDs below 1000 are system users.
• sudo and sudoers: run one command as root, under rules edited with visudo.
• Private and public key: the secret half stays with you; the public half goes in authorized_keys.
• Bastion and ProxyJump: a single entry point, and the SSH option that hops through it.
• sshd: the SSH server. sshd -t checks its configuration, and sshd -T prints the values it will use.
• StrictModes: sshd's refusal to trust key files that other users could change.

Pop quiz

Five questions: three on the ideas in this module, and two scenarios where you apply them. The order changes every time you take it, and 4 out of 5 passes.