Harden OpenSSH Ubuntu 24.04 LTS: Reliable Proven Guide

Introduction

Harden OpenSSH Ubuntu is covered in this complete practical tutorial. To harden OpenSSH server on Ubuntu 24.04 LTS is to implement a multi-layered defense strategy designed to mitigate the risks of brute-force attacks, credential theft, and unauthorized lateral movement within a network. OpenSSH (Open Secure Shell) is the industry-standard protocol for secure remote administration, but its default configuration often prioritizes ease of use and backward compatibility over maximum security. By applying advanced hardening techniques, administrators can enforce the principle of least privilege, mandate strong cryptographic primitives, and establish robust audit trails for all remote access attempts.

Version note: These instructions target ubuntu 24.04. Package versions and repository behavior may change in later releases, so verify upstream documentation before applying production changes.

This guide focuses on transforming a standard OpenSSH installation into a hardened gateway. We will move beyond simple password changes to implement public-key authentication, restrict user access via specific system groups, disable insecure legacy protocols, and configure advanced logging to ensure every connection attempt leaves a verifiable audit trail. This process is essential for any production environment where the threat model includes automated botnets and sophisticated targeted attacks.

What You’ll Learn

This guide explains Harden OpenSSH Ubuntu with clear, reproducible administration steps.

By completing this advanced tutorial, you will gain the technical expertise required to secure remote access on Ubuntu 24.04 LTS. Specifically, you will master the following domains:

• Cryptographic Hardening: How to restrict SSH to modern, high-entropy Key Exchange (KEX) algorithms, Ciphers, and Message Authentication Codes (MACs) to prevent downgrade attacks.
• Authentication Enforcement: Implementing mandatory Public Key Authentication and disabling password-based logins to eliminate the risk of brute-force credential guessing.
• Access Control & Least Privilege: Using the AllowUsers and AllowGroups directives to ensure only authorized identities can initiate sessions, regardless of their system-level permissions.
• Service Lifecycle Management: Managing the sshd service lifecycle, including safe configuration validation and graceful reloads to prevent accidental lockout.
• Auditability and Observability: Configuring advanced logging levels and monitoring system logs to detect reconnaissance and failed authentication patterns.
• Failure Recovery: Establishing a safe rollback path to restore connectivity in the event of a configuration error that results in a lockout.

Prerequisites

Before you begin Harden OpenSSH Ubuntu, confirm the following prerequisites.

Before beginning the hardening process, ensure your environment meets the following requirements to prevent service interruption:

• Administrative Access: You must have sudo privileges on the target Ubuntu 24.04 LTS system.
• Secondary Access Method: Critical: Always maintain an active, secondary session (such as a serial console, IPMI, or a separate non-SSH terminal) while modifying sshd_config. If a configuration error occurs, you will be locked out of your primary SSH session.
• SSH Client: A modern SSH client capable of supporting Ed25519 keys and modern KEX algorithms (e.g., OpenSSH 8.0+).
• Public Key Pair: A pre-generated SSH key pair (preferably Ed25519) located on your local workstation.

Lab Environment

The lab environment used to demonstrate Harden OpenSSH Ubuntu is summarized below.

For the purposes of this tutorial, the following environment is assumed. This setup is designed to simulate a production-grade security boundary.

Installation

Harden OpenSSH Ubuntu

On a fresh Ubuntu 24.04 LTS installation, OpenSSH is typically installed by default. However, to ensure you are working with the most recent, vendor-supported version from the official Ubuntu repositories, you should verify the package provenance and integrity.

First, ensure your local package index is synchronized with the official Ubuntu repositories:

sudo apt update

Verify that the openssh-server package is installed and check its version to confirm it aligns with the expected security baseline:

dpkg -l | grep openssh-server
ssh -V

If the package is not present, install it using the standard package manager. The Ubuntu repository ensures that the package is signed by the official Ubuntu Archive Key, maintaining package provenance:

sudo apt install openssh-server -y

Once installed, ensure the service is enabled to start on boot and is currently running:

sudo systemctl enable ssh
sudo systemctl status ssh

The output of systemctl status ssh should indicate that the service is active (running). If the service fails to start, check the logs immediately using journalctl -u ssh to identify syntax errors or port conflicts.

Alternative Installation and Package Sources

Compare the distribution-supported package with the project’s official repository or installation method. Choose one source, document it, and avoid mixing package origins.

Before changing package sources, record the current package version and repository origin. This makes troubleshooting and rollback more predictable.

Expert Architecture Notes

Security Core provides shared production guidance for least privilege, defense in depth, secure change management, auditability, monitoring, recovery, and incident response. Identity Core provides shared authentication, authorization, account lifecycle, session, privilege, and identity-audit guidance. Network Security Core provides shared firewall, segmentation, exposure, rate-limit, listener, and network-verification guidance. OpenSSH provides production security guidance for public-key authentication, session control, host identity, administrative access.

Experienced administrators define service boundaries before tuning individual settings.

• Separate preventive, detective, and recovery controls into explicit layers.
• Treat identities, network exposure, secrets, audit evidence, backups, and patch state as one security system.
• Separate identity proof, authentication factors, authorization policy, session controls, and audit records.
• Use named accounts and service identities instead of shared administrative credentials.
• Separate public, private, management, and backend network zones.
• Tie every allowed flow to an owner, service, source, destination, protocol, and review date.
• Separate daemon policy, host keys, user keys, bastion access, forwarding, and audit logs.
• Use configuration drop-ins and preserve an out-of-band recovery path.

Request and Component Flow

• An administrator defines the required service and trust boundaries.
• Preventive controls reduce exposure and privilege.
• Detective controls record and alert on abnormal behavior.
• Recovery controls restore known-good service and preserve evidence.
• An identity is enrolled and assigned approved roles.
• Authentication proves control of one or more factors.
• Authorization evaluates the requested action.
• The session and resulting changes are audited.

Security Core Flow

Asset
  ↓
Trust Boundary
  ↓
Preventive Controls
  ↓
Detection and Audit
  ↓
Recovery and Evidence

Review the command output before continuing, and confirm that it completed without errors.

Identity Core Flow

Identity Source
  ↓
Authentication Factors
  ↓
Authorization Policy
  ↓
Session
  ↓
Audit Trail

Version and Platform Guidance

Record the package source and installed version used for Harden OpenSSH Ubuntu so future maintenance remains reproducible.

Configuration

After the initial setup, Harden OpenSSH Ubuntu requires the following configuration checks.

Hardening OpenSSH requires a surgical approach to the /etc/ssh/sshd_config file. We will implement a “deny-by-default” posture. Before making any changes, create a backup of the existing configuration to facilitate a rapid rollback if connectivity is lost.

sudo cp /etc/ssh/sshd_config /etc/ssh/sshd_config.bak

Review the command output before continuing, and confirm that it completed without errors.

1. Cryptographic Hardening

Modern attacks often target weak key exchange algorithms or legacy ciphers. We will restrict OpenSSH to only use high-security primitives. We will prioritize Ed25519 for host keys and Curve25519 for key exchange.

Open the configuration file with a text editor:

sudo nano /etc/ssh/sshd_config

Locate or add the following directives to restrict the cryptographic suite:

# Restrict Key Exchange Algorithms
KexAlgorithms curve25519-sha256@libssh.org,diffie-hellman-group16-sha512,diffie-hellman-group18-sha512

# Restrict Ciphers (AES-GCM is preferred for performance and security)
Ciphers chacha20-poly1305@openssh.com,aes256-gcm@openssh.com,aes128-gcm@openssh.com

# Restrict MACs (Ensure integrity via SHA2)
MACs hmac-sha2-512-etm@openssh.com,hmac-sha2-256-etm@openssh.com,umac-128-etm@openssh.com

Review the command output before continuing, and confirm that it completed without errors.

2. Authentication Enforcement

To mitigate brute-force attacks, we must disable password authentication entirely and mandate the use of SSH keys. We will also disable root login to enforce the principle of least privilege, requiring users to log in as a standard user and use sudo for administrative tasks.

Update the following settings in sshd_config:

# Disable password authentication
PasswordAuthentication no
PermitEmptyPasswords no

# Disable root login via SSH
PermitRootLogin no

# Enable Public Key Authentication
PubkeyAuthentication yes

# Ensure authentication attempts are logged
LogLevel VERBOSE

Note: Setting LogLevel VERBOSE provides more detailed information in the logs, including the fingerprint of the key used for login, which is vital for audit evidence during incident response.

3. Access Control & Least Privilege

Even with strong keys, you should limit which users can access the system via SSH. We will use the AllowGroups directive. First, create a dedicated group for SSH access on your system:

sudo groupadd sshusers
sudo usermod -aG sshusers 

Now, restrict SSH access to only members of this group in sshd_config:

# Only allow members of the sshusers group
AllowGroups sshusers

Review the command output before continuing, and confirm that it completed without errors.

4. Resource Controls & Session Management

To prevent Denial of Service (DoS) attacks targeting the SSH service, we will implement limits on connection attempts and session timeouts.

# Limit concurrent connections
MaxStartups 2:30:10

# Limit maximum authentication attempts per connection
MaxAuthTries 3

# Set idle timeout to prevent abandoned sessions
ClientAliveInterval 300
ClientAliveCountMax 2

The MaxStartups setting 2:30:10 means: start dropping unauthenticated connections when there are 2 unauthenticated connections, start dropping 30% of them, and cap the total at 10. This prevents a single IP from exhausting the connection pool.

Applying Changes Safely

Never restart the SSH service without first validating the configuration syntax. A syntax error in sshd_config will prevent the service from starting, resulting in a total lockout.

Run the test command:

sudo sshd -t

If the command returns no output, the configuration is valid. You can now reload the service to apply the changes gracefully:

sudo systemctl reload ssh

Review the command output before continuing, and confirm that it completed without errors.

Configuration and File Reference

Paths can vary by distribution and installation method. Confirm each path on the target host before editing or automating it.

Upgrade and Maintenance Workflow

Use a staged maintenance process: capture the current version, back up configuration and data, review available packages, apply the update, and complete the same verification checks used after installation.

sudo apt update
sudo apt install --only-upgrade openssh

Run upgrade commands during a maintenance window. Review package changes before confirmation, then verify the service, logs, listening ports, and application behavior.

Expert Performance Guidance

Performance changes should follow measurement, not assumptions.

• Measure the cost of controls with authentication latency, connection overhead, logging volume, and resource saturation.
• Tune controls only after proving they create operational risk; never disable them solely for convenience.
• Measure authentication latency, directory availability, session volume, and lockout rates.
• Cache identity data only with explicit expiry and revocation behavior.
• Measure enforcement cost and resource impact before tuning.
• Prefer specific rules and sets over broad duplicated policy.
• Measure authentication latency, connection rate, and brute-force load.
• Use client multiplexing for approved automation.

Monitor the signals that prove whether the change helped or introduced risk.

• Monitor authentication anomalies, privilege changes, firewall changes, integrity events, patch state, and backup health.
• Correlate host, application, network, and identity events using consistent time synchronization.
• Monitor failed logins, lockouts, privilege changes, dormant accounts, and unusual session locations.
• Monitor policy changes, enforcement failures, denied actions, exceptions, and control coverage.
• Monitor failed authentication, new keys, Match-rule changes, and source geography.
• Track host-key fingerprints and privileged sessions.
• Monitor failed systemd units, pending reboots, disk space, and security updates.

Expert Decision Tables

Security Control Layers

Security Change Strategy

Incident Severity

Keep the final Harden OpenSSH Ubuntu configuration in version control and document every production-specific deviation.

Review Harden OpenSSH Ubuntu settings after major package or operating-system upgrades because defaults can change.

Verification

For upstream details and current platform guidance, consult the Ubuntu Server documentation.

Use these checks to verify that Harden OpenSSH Ubuntu completed successfully.

Verification ensures that the security boundaries are active and that the configuration has not inadvertently broken legitimate access paths. We will verify this through three methods: service state, configuration inspection, and active connection testing.

1. Service and Configuration Verification

First, confirm the service is running and check the effective configuration using the sshd -T command. This command outputs the configuration as it is actually being interpreted by the daemon, which is more reliable than reading the file manually.

sudo systemctl is-active ssh
sudo sshd -T | grep -E "passwordauthentication|permitrootlogin|allowgroups|ciphers|kexalgorithms"

The output should explicitly show passwordauthentication no and permitrootlogin no. If it shows yes, your configuration file has a syntax error or is being overridden by a file in /etc/ssh/sshd_config.d/.

2. Connection Verification (The “Golden Rule”)

Do not close your current session. Open a new terminal window on your local machine and attempt to log in. This allows you to immediately revert changes if the connection fails.

Test the public key authentication:

ssh -i ~/.ssh/id_ed25519 @

If the connection is successful without a password prompt, the hardening was successful. If you are prompted for a password, the PasswordAuthentication no setting is not working or your key is not in the authorized_keys file.

3. Audit Evidence Verification

Verify that the VERBOSE logging is capturing authentication events. Check the system journal for successful and failed login attempts:

sudo journalctl -u ssh -f

Look for lines containing Accepted publickey for... or Connection closed by authenticating user.... This provides the observable evidence required for security auditing and incident response.

A complete Harden OpenSSH Ubuntu verification should cover the version, service state, logs, listening ports, and application response.

Save the successful Harden OpenSSH Ubuntu validation output as a baseline for later incident comparison.

Troubleshooting

If Harden OpenSSH Ubuntu does not work as expected, review these common causes.

When hardening OpenSSH, failure modes typically fall into three categories: configuration syntax errors, authentication failures, and network/firewall issues.

Rollback Procedure: If you are locked out and cannot access the server via SSH, you must use a console-based access method (e.g., DigitalOcean Console, AWS Instance Connect, or physical monitor/keyboard). Once logged in, restore the original configuration:

sudo cp /etc/ssh/sshd_config.bak /etc/ssh/sshd_config
sudo systemctl reload ssh

Review the command output before continuing, and confirm that it completed without errors.

Logs and Diagnostic Commands

When the service behaves unexpectedly, collect evidence before changing configuration. The following commands establish the installed version, service state, recent errors, and application-level health.

openssh --version
systemctl status openssh --no-pager
journalctl -u openssh -n 100 --no-pager
journalctl -u openssh --since '30 minutes ago'
systemctl status openssh --no-pager

Save the relevant output with timestamps. Compare the first error with later secondary failures, because the earliest failure usually identifies the root cause.

Rollback and Uninstall Strategy

A rollback should restore both configuration and compatible application data. Do not remove data directories until backups have been verified and the retention decision is documented.

sudo cp -a /etc/openssh /etc/openssh.backup
sudo systemctl restart openssh
sudo apt remove openssh

Package removal does not always delete configuration or persistent data. Inspect the package manager output, verify backups, and confirm whether a purge is appropriate before deleting retained files.

Automation and Routine Health Checks

Automate read-only health checks before automating changes. A scheduled check should report a failure without repeatedly restarting services or hiding the original error.

systemctl is-active openssh
journalctl -u openssh -n 20 --no-pager

For fleet management, place the same checks in Ansible, a monitoring agent, or a systemd timer. Keep credentials outside scripts and make maintenance jobs idempotent.

Common Production Failure Modes

Structured Troubleshooting Playbook

Unexpected privileged access

Symptoms:

• Unexpected privileged access creates a security, availability, or auditability gap.

Likely causes:

• Excessive group membership, sudo rules, service permissions, or stolen credentials grant access.

Diagnosis:

id USER
sudo -l -U USER
getent group sudo

Run these checks in order and preserve the first relevant error before making changes.

Resolution:

• Remove unnecessary privilege, rotate credentials, and review audit evidence.

Verification:

• Confirm the user can perform only approved actions.

Security logging missing

Symptoms:

• Security logging missing creates a security, availability, or auditability gap.

Likely causes:

• Audit or journal configuration is disabled, filtered, or storage is full.

Diagnosis:

journalctl --disk-usage
systemctl status auditd --no-pager
df -h /var/log

Resolution:

• Restore logging, free space safely, and verify retention.

Verification:

• Generate a test event and confirm it is recorded.

Unpatched exposed service

Symptoms:

• Unpatched exposed service creates a security, availability, or auditability gap.

Likely causes:

• Repository, maintenance, or reboot workflow is incomplete.

Diagnosis:

apt list --upgradable
systemctl --failed
needrestart -r l 2>/dev/null || true

Resolution:

• Apply tested security updates and reboot where required.

Verification:

• Confirm package versions and external service health.

Administrator lockout

Symptoms:

• Administrator lockout creates a security, availability, or auditability gap.

Likely causes:

• Authentication, firewall, or privilege changes removed the recovery path.

Diagnosis:

ss -ltnp
journalctl -u ssh -n 100 --no-pager
visudo -c

Resolution:

• Use console access to restore the last known-good policy.

Verification:

• Open a second verified administrative session.

Compromise suspected

Symptoms:

• Compromise suspected creates a security, availability, or auditability gap.

Likely causes:

• Unexpected processes, accounts, network traffic, or integrity changes indicate intrusion.

Diagnosis:

ps auxf
ss -plant
last -ai
find /etc -type f -mtime -2

Resolution:

• Isolate the host, preserve evidence, rotate credentials, and rebuild from trusted media when appropriate.

Verification:

• Validate the rebuilt host and monitor for recurrence.

When diagnosing Harden OpenSSH Ubuntu, capture the earliest error before restarting services or changing configuration.

Compare a failed Harden OpenSSH Ubuntu host with a known-good configuration to identify drift quickly.

Security Best Practices

Apply these security controls after Harden OpenSSH Ubuntu is complete.

Hardening is an ongoing process, not a one-time event. To maintain a high security posture, adhere to these lifecycle management principles:

Principle of Least Privilege

Never grant sudo access to users unless absolutely necessary for their role. Use specific sudoers entries to allow users to run only specific commands rather than granting full root access. This limits the blast radius if a user’s credentials are compromised.

Secret Handling and Key Management

Never store private keys on the server itself. Private keys should reside only on trusted client machines or in secure hardware modules (HSM). When using SSH keys, always use a passphrase to encrypt the private key on your local machine. This adds a second factor: something you have (the key file) and something you know (the passphrase).

Continuous Auditing

Regularly review /var/log/auth.log (on Debian/Ubuntu) or the systemd journal for patterns of failed login attempts. A sudden spike in Connection closed by authenticating user messages from various IP addresses is a strong indicator of a brute-force reconnaissance attempt. Consider implementing Fail2Ban to automatically block IPs that exhibit such behavior.

Patch Management and Lifecycle

Security vulnerabilities are discovered in OpenSSH periodically. Ensure your system is configured for automatic security updates using the unattended-upgrades package:

sudo apt install unattended-upgrades
sudo dpkg-reconfigure --priority=low unattended-upgrades

Review the command output before continuing, and confirm that it completed without errors.

Production Readiness Checklist

• Back up configuration and application data before changes.
• Validate configuration before restarting or reloading the service.
• Monitor logs, disk usage, resource consumption, and service availability.
• Document rollback steps and test them outside production.

Record the tested version, configuration checksum, backup location, validation commands, and rollback owner in the change record before production rollout.

Expert Hardening Guidance

Apply controls in layers and verify that security changes do not break required service behavior.

• Use least privilege and deny-by-default policies.
• Patch exposed services promptly and stage risky changes.
• Protect administrative paths with strong authentication and private access.
• Disable dormant and shared accounts.
• Use strong factors for privileged access.
• Separate human, service, and emergency identities.
• Use deny-by-default ingress and explicit management allowlists.
• Restrict egress for sensitive workloads where operationally practical.

Production Best Practices

• Document trust boundaries and required exposures.
• Use least privilege for users and services.
• Keep systems and dependencies patched.
• Centralize and retain audit logs.
• Test backups and bare-metal recovery.
• Protect administrative interfaces.
• Rotate credentials after suspected exposure.
• Validate time synchronization.
• Use configuration management for security state.
• Review exceptions with an expiry date.

Security Checklist

OpenSSH Production Security Checklist

• Back up sshd configuration and host keys.
• Verify console or out-of-band access.
• Run sshd -t.
• Keep an existing session open.
• Test a second session.
• Review forwarding and root-login policy.
• Confirm logging and time sync.

Avoid these common operational anti-patterns.

• Do not apply hardening without a tested access-recovery path.
• Do not delete logs or rebuild a compromised host before preserving evidence.
• Do not use shared root credentials.
• Do not grant permanent privilege for temporary work.
• Do not disable the control globally to fix one application.
• Do not create undocumented permanent exceptions.

Expert Recovery Strategy

Recovery planning must cover configuration, persistent state, dependencies, and the order in which services return.

• Preserve logs, timestamps, volatile evidence, and configuration before remediation.
• Restore from a known-good baseline and rotate affected credentials.
• Complete a post-incident review and convert findings into preventive controls.
• Maintain tested emergency access with strict monitoring.
• Revoke sessions and rotate affected factors after compromise.
• Keep a validated policy backup and a console recovery path.
• Preserve denial and audit evidence before relaxing controls.
• Use console access to restore the last known-good configuration.

Automate repeatable checks and changes without hiding failures.

• Automate read-only compliance checks before remediation.
• Require validation and rollback for automated security changes.
• Automate joiner, mover, and leaver workflows.
• Continuously compare account state with the approved source of truth.
• Manage policy through version-controlled idempotent automation.
• Validate effective state after every deployment.

Incident Response Playbook

OpenSSH Security Incident Response

Containment:

• Isolate suspicious source addresses and preserve the active session.

Evidence collection:

• Collect auth logs, process state, keys, and network connections.

Eradication:

• Remove unauthorized keys, accounts, tunnels, and persistence; rotate credentials.

Recovery:

• Restore validated configuration and trusted host identity.

Verification:

• Verify authorized access, monitor recurrence, and document the incident.

Reassess Harden OpenSSH Ubuntu permissions, exposed ports, credentials, and update status during every security review.

Limit administrative access to Harden OpenSSH Ubuntu and retain an auditable record of privileged changes.

Expert FAQ

What is defense in depth?

Defense in depth uses multiple independent controls so one failure does not expose the entire system. Combine identity, network, host, application, monitoring, and recovery controls.

Should every server use the same hardening policy?

Use a shared baseline, then apply role-specific controls. A database, reverse proxy, and CI runner have different required services and trust boundaries.

How often should security updates be applied?

Apply critical updates quickly after compatibility testing. Use a defined maintenance and emergency patch process rather than an arbitrary fixed interval.

What should be logged?

Record authentication, privilege changes, service failures, firewall changes, configuration changes, and security-tool alerts while avoiding unnecessary secrets in logs.

When should credentials be rotated?

Rotate on staff or role changes, suspected exposure, policy deadlines, and after incidents. Automated short-lived credentials are preferable where supported.

Is a firewall enough to secure a server?

No. A firewall reduces exposure but does not replace patching, least privilege, authentication, application security, monitoring, or recovery planning.

Related Technologies

• OpenSSH
• UFW
• Fail2Ban
• auditd
• AppArmor
• SELinux
• nftables
• sudo
• PAM
• iptables
• HAProxy
• Nginx

Frequently Asked Questions

What should I verify after Harden OpenSSH Ubuntu?

Confirm the service, version, logs, network access, and security settings described above.

Will disabling password authentication lock me out if my SSH key fails?

Yes. If you disable password authentication and your SSH key is not correctly configured in the authorized_keys file, you will be locked out. Always test your key connection in a separate window before closing your current session.

Why should I use Ed25519 instead of RSA?

Ed25519 is faster, more secure, and has smaller key sizes than RSA. It is resistant to many side-channel attacks that affect older algorithms and is the modern standard for secure SSH communications.

Is it safe to change the default SSH port?

Changing the port from 22 to a non-standard port can reduce the noise in your logs from automated bots, but it is “security through obscurity” and does not replace the need for robust authentication and cryptographic hardening.

How do I verify if my SSH configuration is valid without restarting?

Always use the command sudo sshd -t. This performs a syntax check on your configuration files and reports any errors without attempting to start the service.

For repeatable results, document the exact Harden OpenSSH Ubuntu version and platform used by this tutorial.

Conclusion

You now have a verified process for Harden OpenSSH Ubuntu with configuration, troubleshooting, and security guidance.

Hardening the OpenSSH server on Ubuntu 24.04 LTS is a fundamental requirement for securing any Linux-based infrastructure. By moving from a permissive default state to a restrictive, identity-based, and cryptographically sound configuration, you significantly increase the cost and complexity for an attacker. Remember that security is a lifecycle: always validate configurations before applying them, maintain a secondary access method for recovery, and continuously monitor your logs for signs of unauthorized activity.

Through the implementation of least privilege, strong key-based authentication, and modern cryptographic primitives, you establish a resilient gateway for your critical systems.

Keep this the service environment procedure available for future maintenance and repeatable deployments.

Document the final the Linux setup baseline so later troubleshooting remains consistent.

Recheck the procedure after major package, firewall, database, or operating-system updates.

Test the this configuration rollback procedure before the next production maintenance window.

Monitor the deployment after deployment and compare the observed behavior with the verification baseline.

Related Tutorials

• Ubuntu Server first boot: 7-Step Reliable Proven Guide
• Create sudo user Ubuntu: 7-Step Efficient Expert Guide
• Set hostname Ubuntu Server 24.04 LTS: Secure Expert Guide

Need help? If you run into issues while following this guide, leave a comment with the command output and your Linux version.