Ubuntu Server Security: SSH Keys, UFW, and Automatic Updates

1. Establish a recovery path

Before changing SSH or firewall settings, verify that the provider console works and take a backup. Record your actual SSH port and keep the original session open. This guide assumes a normal systemd-based Ubuntu server. Container hosts and machines with an existing firewall policy need additional review.

2. Review updates and listening services

sudo apt update
apt list --upgradable
sudo apt upgrade
sudo ss -lntup
systemctl --failed

Review package prompts, then plan any required restart. For each listening service, decide whether it belongs on the public interface. Bind databases and internal dashboards to a local or private address when public access is unnecessary.

3. Test a named administrator and SSH key

Create a dedicated administrator if your image does not already provide one. The example username is opsadmin; choose your own. Set a strong local password for sudo when prompted.

sudo adduser opsadmin
sudo usermod -aG sudo opsadmin

On your own computer, generate a passphrase-protected key if needed and install its public half. Substitute your real address and SSH port; never upload the private key.

ssh-keygen -t ed25519
ssh-copy-id -p 22 opsadmin@SERVER_IP
ssh -p 22 opsadmin@SERVER_IP

In the new session, run sudo -v. Only after key login and sudo both work, review the SSH configuration. In a configuration snippet read before conflicting settings, use the following baseline when you do not rely on keyboard-interactive MFA:

PubkeyAuthentication yes
PasswordAuthentication no
KbdInteractiveAuthentication no
PermitRootLogin no

Ubuntu normally reads /etc/ssh/sshd_config.d/*.conf near the top of its main configuration. Most SSH settings use the first value encountered. Check the effective values rather than assuming a file with a high number overrides earlier files. Keep MFA settings if your access design requires them.

sudo /usr/sbin/sshd -t
sudo /usr/sbin/sshd -T | grep -E "^(passwordauthentication|kbdinteractiveauthentication|permitrootlogin|pubkeyauthentication) "

If syntax and effective values are correct, reload ssh.service and test another connection. This guide leaves the SSH port unchanged; socket-activated installations require extra care when changing listeners. See Ubuntu’s OpenSSH documentation.

4. Enable UFW without closing your way in

Use these examples on a simple server where UFW will be the firewall manager. Replace port 22 if your SSH service uses another port, and add any other required application ports before enabling the policy.

sudo apt install ufw
sudo ufw default deny incoming
sudo ufw default allow outgoing
sudo ufw allow 22/tcp comment "SSH administration"
# Only for a public web server:
sudo ufw allow 80/tcp
sudo ufw allow 443/tcp
sudo ufw enable
sudo ufw status verbose

Verify IPv6 handling in /etc/default/ufw and test both address families. For a fixed management address or VPN, tighten SSH access after testing the corresponding allow rule. Do not stack UFW over another firewall manager or assume published container ports follow the same path. UFW documentation explains rule management.

5. Check unattended security updates

sudo apt install unattended-upgrades
sudo unattended-upgrade --dry-run --debug
systemctl list-timers apt-daily-upgrade.timer

Review allowed package origins, logs, and reboot behavior before relying on automation. Third-party repositories need their own update policy. See Ubuntu automatic updates.

6. Verify and maintain

From a second machine, test SSH and the intended public services. Check that private services are not exposed. Keep AppArmor enabled, monitor failed services and disk space, and schedule a restore test from an off-server backup. If a change fails, revert the specific SSH snippet or firewall rule using the console rather than disabling all security controls.