Ubuntu Server Post-Install Systems Configuration

Table of Contents:

• Phase 1 - Initial Validation & Environment Awareness
• Phase 2 - Identity, Privilege Management, & Access Control
• Phase 3 - Networking & Host Identity
• Phase 4 - Security Baseline
• Phase 5 - Service & System Management
• Phase 6 - Logging, Monitoring, & Maintenance

Phase 1 — Initial Validation & Environment Awareness

1. ubuntu-server login:

After successful authentication, the system loads directly into a user shell. Root access can be obtained using sudo.

When you download the official Ubuntu Server ISO and install it, you get a headless system by default. A headless system is one to where there is no GUI (Graphical User Interface) to login to and manage the system with, it's all done in the Linux terminal via command-line shell.

However, even though the system is headless by default, that doesn't mean you're "locked out" of the GUI. If you find that a specific task is too difficult in the terminal, you can run one command: sudo apt install ubuntu-desktop, this will download about 2GB of data and convert the server into a desktop environment. However, it's a best practice to avoid this because it results in the server becoming slower and less secure.

Even though you can enable a GUI, when it comes to Linux server administration, the ability to be able to effectively and efficiently manage an Ubuntu server system via terminal is widely considered one of the most imperative skills in Linux server administration.

2. Verify OS, Kernel, and System Health

Immediately confirm what you're running:

Before proceeding with system configuration, there are some critical verifications to look through, that can really be huge time savers.

These commands are considered the "vital signs" to check on an Ubuntu server system post OS installation, or any Linux server installation for that matter.

Especially when there's only a terminal to work with. These commands help to confirm that the hardware and software components of a given system are functioning as expected before continuing to configure the system further.

I like to start out with commands such as hostname, whoami, pwd, to get an overall feel for the environment that I'm working in.

After going through those, I then go through the following:

• lsb_release -a & uname -a
• uptime
• df -h
• free -h

The System "Identity Check"

• Why: You need to verify exactly which version of Ubuntu and which Linux Kernel were installed.


• The Goal: If you intended to install a Long Term Support (LTS) version like 24.04 but accidentally installed an interin version, you want want to know before you spend hours configuring it. It also confirms if you are running a 64-bit or ARM-based system.

The System "Stability Check"

• Why: This tells you how long the server has been running and the "load average."


• The Goal: This helps to confirm that the system didn't experience a silent crash or reboot during the final stages of the installation process. If the load average is high on a brand-new install, something is going on with the background processes.

The System "Storage Check"

• Why: This shows your disk partitions and how much space is used.


• The Goal: There is a common issue during Ubuntu installations is the "LVM" default, which can sometimes only allocate half of the drive space. Running this command ensures that the server actually sess all the storage you gave it.


• The -h makes the command output "human readable" (showing GB instead of raw blocks).

The System "Memory Check"

• Why: This displays the system RAM usage and system "Swap" space.


• The Goal: You want to make sure the server is detecting all of the RAM sticks (or the full amount of RAM allocated). If the server is already using 90% of its RAM with nothing installed, that's a sure sign an upgrade is needed well before the deployment stage is reached.

3. Update the System (Mandatory First Action)

After going through the verification of the OS, Kernel, and System Health, updating the system with the latest packages and security patches is an absolute imperative must!

Never configure a stale system:

Why

• Security patches
• Kernel fixes
• Package stability before service deployment

In this example, apt update and apt upgrade are used in a one-line command with the use of the && (Logical AND) operator, allowing the system to run the two commands sequentially instead of running both commands separately.

This command chain performs a two-stage maintenance routine that first synchronizes the local system with official software repositories and then applies all available security and stability patches.

After a significant system upgrade, a sudo reboot is performed to initialize the newly installed Linux Kernel.

Helping to ensure that the system isn't running an outdated or vulnerable kernel and that all system services have been refreshed to utilize the latest patched libraries.

Phase 2 — Identity, Privilege Management & Access Control

1. Create a Non-Root Admin User

Never operate day-to-day as root:

Running groups sysadmin command confirms that the automated part of the command adduser process works correctly.

It Shows:

• Primary Group: The user has their private group ( sysadmin )


• Standard Access: The user was successfully added to the users group, which is the standard pool for non-0administrative accounts on the system.

Creating a Non-Root Admin User account is an action of Account Isolation.

Instead of doing everything through your personal account or the "root" account, this creates a dedicated service account (sysadmin). This is a key security-step-if one users becomes compromised, the other user accounts remain protected.

Why:

• Least privilege
• Auditability
• Industry best practice

2. Harden SSH Access

Edit SSH configuration:

Recommended changes:

• PermitRootlogin no
• PasswordAuthentication no
• PubKeyAuthentication yes

Verify/Make necessary changes, ctrl + o to save, ctrl + x to exit.

Here it shows:

• PermitRootLogin prohibit-password (no)
• PubKeyAuthentication yes
• PermitRootLogoin prohibit-password (no)-(set-above)

After making adjustments, restart the ssh service for the changes to take effect:

Why:

• Prevents brute-force attacks
• Enforces key-based auth

Phase 3 — Networking & Host Identity

1. Verify Network Configuration (Netplan)

The ip a command confirms/verifies the IP configuration details to the systems network adapater.

Best practice to review the IP configuration details to verify that you have the expected details set for the given configuration.

The ip route command lists the default routes that are defined on the given system.

It's a good detail to verify, and a good command to run in different troubleshooting scenarios.

View Netplan:

Here, things are moving into network administration with the Netplan system utility. Netplan is the default way Ubuntu Server manages network settings like IP addresses, DNS, and gateways.

Running ls /etc/netplan/ to see what is available in the /netplan directory.

In this example, the output file is 50-cloud-init.yaml.

In Ubuntu systems, network configurations are stored in YAML files.

These files are the "instruction manuals" that instruct a Network Interface Card (NIC) how to establish an internet connection.

Apply safely

This right here is the most critical part of network configuration:

Committing changes safely!

When you edit network settings on a headless server, there is a high risk of accidentally locking yourself out.

If you type one wrong number in an IP address and hit "apply," the server might lose its connection, and since you don't have a GUI or a local screen, you'd have no way to get back in to fix it.

The sudo netplan try command applies new network settings temporarily.

• The "Timeout" Feature: In the output it says "Changes will revert in 115 seconds." It starts a countdown. If you don't press Enter within that time, the server assumes something went wrong (like you losing your connection) and automatically rolls back to the old, working settings.


• Why it's a lifesaver: If your new config breaks the internet, you just wait two minutes, and the server "fixes itself" by reverting back to your previous settings.

The sudo netplan apply command is The "Final Commitment"

• What it does: Once you've confirmed that netplan try worked and you still have access, you run this to make the changes permanent.


• The Result: The system writes the configuration to the network stack. These settings will now persist even after the server reboots.

Why:

• Static IPs for servers
• Prevents accidental lockouts

Why This is Among One of the First Steps - Post OS Installation:

In a headless server configuration, the Network Configuration is the most critical file. If the file is set up incorrectly, the server goes offline, and you lose your SSH connection. Admins usually have to:

• Set a Static IP: Ensuring the server's address never changes (so you always know where to SSH).


• Configure DNS: Telling the server which "phonebook" (like Google or Cloudflare) to use to find websites.

Operational continuity relies heavily on servers with Network Persistence & Configuration. To ensure consistent remote access, using Netplan to manage the server's network stack, helps to maintain that persistence.

By auditing the YAML configuration files in /etc/netplan/, you can define static IP assignments and custom DNS resolvers.

The nano or other text editor CLI of your choice can be used to make changes to the file's configuration details, ensuring the server maintains a reliable 'heartbeat' on the local network, ensuring operations are not disrupted.

2. Set Hostname & Local Name Resolution

Initial System Provisioning

Add:

• 127.0.1.1 ubuntu-srv01

With these commands, the goal is to ensure network clarity and application stability.

After the initial system health check, it's time setup a recognizable hostname for the system that will be deployed into production that fits its intended purpose.

Listing out the current default hostname, followed by running the sudo hostnamectl set-hostname command to change the system's hostname to ubuntu-srv01.

Then mapping the new system hostname to the local loopback address in the /etc/hosts file.

This prevents 'DNS-lookup lag' and ensures that local services can resolve the system's identity without external network dependencies.

Why:

• Clean logs
• Predictable service identity
• Easier monitoring & automation

Phase 4 — Security Baseline

1. Configure the Firewall (UFW)

• Deny incoming traffic by default
• Allow outgoing traffic by default
• Allow OpenSSH
• Enable the ufw Firewall
• List ufw Firewall status

Why:

• Immediate attack surface reduction
• Zero-trust mindset

2. Enable Automatic Security Updates

To minimize the attack surface and ensure 24/7 security compliance, the unattended-upgrades program can be used to implement Automated Patch Management.

This configuration enables the server to autonomously fetch and apply critical security updates from the official Ubuntu repositories.

This proactive approach ensures the system remains resilient against emerging threats without requiring manual intervention, balancing high security with operational stability.

Select Yes when prompted:

The sudo dpkg-reconfigure unattended-upgrades command is a major step in Automated Security Management.

By automating patch management workflows you maintain a proactive security posture.

Enabling automated background delivery of critical security patches.

This approach ensures the server remains resilient against 'Zero-Day' vulnerabilities by synchronizing with official repositories daily, reducing the need for manual intervention while maintaining system uptime and stability.

Phase 5 — Service & System Management

1. Install Core SysAdmin Tools

Install essential commands:

• htop
• curl
• wget
• git
• net-tools
• fail2ban

The Fail2ban service is a critical open-source intrusion prevention service.

It's designed to harden a server against brute-force attacks.

It does by configuring 'jails,' the system dynamically monitors SSH authentication logs and proactively bans malicious IP addresses.

This automation significantly reduces the server's attack surface and ensures that system resources are reserved for legitimate users.

Enabling fail2ban

This is the terminal equivalent of opening the "Processes" tab in a Windows Taks Manager or Activity Monitor on a Mac.

Phase 6 — Logging, Monitoring & Maintenance

1. Log Inspection

In this example, I utilized journalctl -p 3 -xb as a primary diagnostic tool to run a high-priority log inspection.

By filtering for Priority 3 (Error-level) events within the current boot descriptro, to be able to bypass non-critical system telemetry and immediately isolate service failures or kernel exceptions that could impact system stability.

2. Check auth logs

Simultaneously, I used tail -f on the authentication logs (auth.log) to establish a Live Security Feed, allowing for real-time observation of user sessions and authentication attempts.

This approach ensures total visibility into both system stability and security integrity.

Why:

• Early intrusion detection
• Debugging misconfigurations

3. Backup Awareness (Often Ignored)

Even if you don't implement backups yet:

In establishing a robust disaster recovery plan, it's absolutely imperative to prioritize the /etc and /var directories.

Backing up /etc preserves the System State, capturing all custom configurations, security policies, and network definitions.

Meanwhile, backing up /var ensures preservation of Operational Data, including critical security logs and application databases.

Together, these backups allow for a rapid 'Bare Metal' recovery, ensuring that the system can be restored to its exact functional state in the event of hardware failure or data corruption.