Ubuntu MOTD login banner: 7-Step Reliable Proven Guide

Introduction

An Ubuntu MOTD login banner is a system-level configuration used to display specific information to users immediately upon a successful authentication via SSH or local terminal sessions. The Message of the Day (MOTD) serves as a critical communication channel for system administrators to broadcast essential operational data, such as system health, upcoming maintenance windows, or security warnings. Beyond simple messaging, configuring these banners is a fundamental component of system hardening.

By implementing legal warnings and usage policies through login banners, organizations establish a clear “no unauthorized access” boundary, which is vital for audit evidence and legal compliance during forensic investigations.

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

In a professional production environment, the MOTD is not merely a static text file but a dynamic framework. On Ubuntu, the MOTD system utilizes a modular architecture located in /etc/update-motd.d/. This allows administrators to execute scripts that pull real-time data—such as disk usage, CPU load, or pending security updates—and present it to the user. This tutorial provides a comprehensive guide to implementing both static and dynamic banners while adhering to the principle of least privilege and ensuring that configuration changes do not disrupt the authentication lifecycle.

What You’ll Learn

This guide explains Ubuntu MOTD login banner with clear, reproducible administration steps.

By completing this technical guide, you will acquire the skills necessary to manage the visual and security-oriented interface of an Ubuntu server. Specifically, you will learn how to:

• Distinguish between the different types of login messages, including the static MOTD, the dynamic MOTD modules, and the SSH-specific banners.
• Implement a legal warning banner to establish a security boundary for unauthorized access attempts.
• Create custom dynamic MOTD scripts that provide real-time system telemetry (e.g., disk space, memory, and updates) to authenticated users.
• Apply strict filesystem permissions to ensure that configuration files and scripts are owned by root and are not writable by non-privileged users.
• Verify the successful deployment of banners using multiple authentication methods.
• Troubleshoot common failure modes, such as broken shell environments or permission-related visibility issues.
• Apply security hardening principles to ensure that the MOTD system does not leak sensitive system information to unauthenticated users.

Prerequisites

Before you begin Ubuntu MOTD login banner, confirm the following prerequisites.

Before proceeding with the configuration, ensure you meet the following requirements to prevent service disruption or security regressions:

• Administrative Access: You must have sudo privileges or direct root access to modify files within /etc/ and /usr/.
• Terminal Access: A working SSH connection or local console access to an Ubuntu Server (22.04 LTS or 24.04 LTS recommended).
• Basic Linux Proficiency: Familiarity with the command line, file permissions (chmod, chown), and the vim or nano text editors.
• System Awareness: Understanding that changes to the SSH configuration (sshd_config) require a service reload to take effect.

Lab Environment

The lab environment used to demonstrate Ubuntu MOTD login banner is summarized below.

To ensure a safe deployment, this tutorial assumes a controlled environment. For production systems, always perform these changes in a staging environment first to verify that custom scripts do not introduce latency during the login process.

Installation

Ubuntu MOTD login banner

The MOTD and login banner functionality is a core component of the Ubuntu system and the OpenSSH suite. Therefore, no additional package installation is typically required for standard functionality. However, to ensure you have the necessary tools for advanced dynamic messaging, you should verify the presence of the update-motd framework and the pam_motd module.

First, ensure your system is up to date to guarantee the integrity of the package provenance and security patches:

sudo apt update
sudo apt upgrade -y

Verify that the SSH server is installed and running, as the SSH banner is specifically handled by the sshd daemon:

ssh -V
sudo systemctl status ssh

If you intend to use advanced dynamic scripts, ensure bash is available, as most MOTD scripts are written in shell script syntax for compatibility with the system’s execution environment.

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

Experienced administrators define service boundaries before tuning individual settings.

• Treat APT sources, packages, services, kernel, and bootloader as one managed dependency graph.
• Separate routine updates from release upgrades and document third-party repositories.

Record the package source and installed version used for Ubuntu MOTD login banner so future maintenance remains reproducible.

Configuration

After the initial setup, Ubuntu MOTD login banner requires the following configuration checks.

Configuration is divided into two distinct categories: the Pre-Authentication Banner (shown to everyone attempting to connect) and the Post-Authentication MOTD (shown only after successful login).

1. Pre-Authentication Banner (Legal Warning)

The pre-authentication banner is used for legal notices. Because this is shown before the user is identified, it must not contain sensitive information (like the specific kernel version or internal IP addresses) that could assist an attacker in reconnaissance. This is configured via the sshd_config file.

Create a new banner file with strict permissions to prevent unauthorized modification:

sudo touch /etc/issue.net
sudo chmod 644 /etc/issue.net

Edit the file to include your legal disclaimer:

sudo nano /etc/issue.net

Example content for /etc/issue.net:

***************
WARNING: This system is for authorized users only. All activities are
monitored and logged. Unauthorized access is strictly prohibited and
may be subject to criminal prosecution.
***************

Now, instruct the SSH daemon to use this file. Edit /etc/ssh/sshd_config:

sudo nano /etc/ssh/sshd_config

Locate the line #Banner none and change it to:

Banner /etc/issue.net

Validate the configuration and reload the service:

sudo sshd -t
sudo systemctl reload ssh

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

2. Post-Authentication MOTD (Dynamic Messaging)

The dynamic MOTD is managed by the update-motd framework. This framework executes scripts in /etc/update-motd.d/ in numerical order. To create a custom dynamic message, create a new script in this directory.

Let’s create a script that displays the current system load and disk usage. We must ensure the script is executable and owned by root to maintain the principle of least privilege.

# Create the script
sudo nano /etc/update-motd.d/99-custom-stats

Add the following logic to the script:

#!/bin/bash

# Get system load
LOAD=$(uptime | awk -F'load average:' '{ print $2 }')
# Get disk usage of root partition
DISK=$(df -h / | awk 'NR==2 {print $5}')

echo "-------------------------------------------------------"
echo " SYSTEM STATUS REPORT"
echo "-------------------------------------------------------"
echo " Load Average: $LOAD"
echo " Root Disk Usage: $DISK"
echo "-------------------------------------------------------"

Set the correct ownership and permissions. This is a critical security step; if a non-root user can write to this script, they can achieve privilege escalation by injecting commands that run during the login process of a root user.

sudo chown root:root /etc/update-motd.d/99-custom-stats
sudo chmod +x /etc/update-motd.d/99-custom-stats

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 motd

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 boot time, memory pressure, disk latency, and service startup before changing kernel or sysctl settings.
• Keep /boot and root filesystem capacity monitored before large upgrades.

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

• Monitor failed systemd units, pending reboots, disk space, and security updates.

Keep the final Ubuntu MOTD login banner configuration in version control and document every production-specific deviation.

Review Ubuntu MOTD login banner 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 Ubuntu MOTD login banner completed successfully.

Verification ensures that the configuration is applied correctly and that the security boundaries are intact. We will verify both the pre-authentication and post-authentication messages.

Verifying Pre-Authentication Banner

To verify the /etc/issue.net banner, attempt to connect to the server from a remote client. Note that you should observe the banner before you are prompted for a password.

# From a remote machine
ssh -o Banner=/etc/issue.net user@server_ip

Observable Evidence: If successful, the legal warning appears immediately. If you see the standard SSH prompt without the warning, the Banner directive in sshd_config was not applied or the service was not reloaded.

Verifying Post-Authentication MOTD

To verify the dynamic MOTD, log in to the server and check the output of the scripts. You can also manually trigger the update process to ensure there are no syntax errors in your scripts.

# Manually run the update-motd tool
sudo run-parts /etc/update-motd.d/

Observable Evidence: The output should display your custom “SYSTEM STATUS REPORT” block. If the command returns an error, check the script syntax using bash -n /etc/update-motd.d/99-custom-stats.

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

Save the successful the service environment validation output as a baseline for later incident comparison.

Troubleshooting

If the Linux setup does not work as expected, review these common causes.

When MOTD or banners fail to appear, use the following diagnostic steps to isolate the failure mode.

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.

motd --version
systemctl status motd --no-pager
journalctl -u motd -n 100 --no-pager
journalctl -u motd --since '30 minutes ago'
systemctl status motd --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/motd /etc/motd.backup
sudo systemctl restart motd
sudo apt remove motd

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 motd
journalctl -u motd -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

Security Best Practices

Apply these security controls after the procedure is complete.

Configuring login banners is a security task that requires adherence to the principle of least privilege and information concealment.

Principle of Least Privilege

Never allow non-privileged users to write to /etc/update-motd.d/ or /etc/issue.net. If a user can modify these files, they can execute arbitrary code with the privileges of the user logging in. Always use chown root:root and chmod 644 for static files and chmod 755 for executable scripts.

Preventing Information Leakage

A common mistake is including highly specific system details in the pre-authentication banner. For example, do not include:

• The exact OS version (e.g., “Ubuntu 24.04.1 LTS”).
• The specific kernel version.
• Internal network interface IP addresses.
• The names of running services.

These details provide an attacker with a “roadmap” for exploitation. Keep the pre-authentication banner generic and use the post-authentication MOTD for detailed system telemetry, as the user has already been authenticated at that stage.

Audit and Compliance

Use the MOTD to display a “Legal Notice” that explicitly states that all activities are monitored. This is not just for psychological deterrence; it is a legal requirement in many jurisdictions to establish that the user had no “reasonable expectation of privacy” on the system, which is essential for the admissibility of logs in legal proceedings.

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 unattended-upgrades with monitoring and an explicit reboot policy.
• Prefer AppArmor profiles, least-privilege sudo rules, and minimal exposed services.

Avoid these common operational anti-patterns.

• Do not mix multiple repositories for the same core package without pinning.

Expert Recovery Strategy

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

• Retain previous kernels and console access.
• Save package selections, APT sources, and configuration backups before high-risk changes.

Automate repeatable checks and changes without hiding failures.

• Use cloud-init or Ansible for repeatable host configuration.

Frequently Asked Questions

What should I verify after this configuration?

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

Why is my banner not showing up even after I edited sshd_config?

The most common reason is that the SSH service was not reloaded. Changes to sshd_config are only read when the service starts or reloads. Always run sudo systemctl reload ssh after making changes.

Can I use Python scripts for my MOTD instead of Bash?

Yes, you can. However, you must ensure the script is executable and that the shebang (e.g., #!/usr/bin/python3) is correctly defined at the top of the file. Note that using Python may slightly increase login latency compared to lightweight Bash scripts.

What is the difference between /etc/issue and /etc/issue.net?

/etc/issue is typically used for local console logins (physical access), while /etc/issue.net is the standard file used by the SSH daemon for remote network logins.

Conclusion

You now have a verified process for the deployment with configuration, troubleshooting, and security guidance.

Configuring the Ubuntu MOTD and login banners is a vital administrative task that bridges the gap between system usability and security hardening. By implementing a clear, legal pre-authentication banner, you establish a security boundary. By utilizing the dynamic update-motd.d framework, you provide users with immediate, actionable system telemetry. Always remember to maintain strict ownership and permissions on these configuration files to prevent privilege escalation and to ensure that your system remains secure and compliant with organizational policies.

Related Tutorials

• Cloud-init Ubuntu Server: 7-Step Reliable Proven Guide
• Ubuntu Server first boot: 7-Step Reliable Proven 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.