Your First Hour on a Linux Server: Essential Commands Checklist

Your First Hour on a Linux Server: Essential Commands Checklist Checklists & Cheat Sheets

Getting access to a new Linux server is only the beginning. Before you install a website, Docker, a database, a VPN, or a production application, you should first understand the system you received and establish a safe administrative baseline.

This first-hour checklist walks you through that process on a new Ubuntu or Debian-based VPS: connecting with SSH, checking resources, installing updates, creating an administrator account, configuring key-based access, reviewing network exposure, and verifying that the server is ready for its next role.

🎯 What You’ll Learn
  • How to connect to a new Linux server with SSH.
  • How to identify the operating system and inspect server resources.
  • How to update packages safely.
  • How to create a separate administrator account with sudo.
  • How to prepare SSH key authentication without locking yourself out.
  • How to configure a basic firewall and inspect listening ports.
  • How to perform a final health check before deploying applications.
⚠️ Before You Start

Keep your existing root SSH session open while changing SSH accounts, authentication, or firewall rules. Test every access change from a second terminal session before disconnecting the original one. This simple habit can prevent you from locking yourself out of the server.

🧭 Your First-Hour Roadmap

The goal is not to install as much software as possible. Your first hour should establish three things: access, awareness, and a safe baseline.

Phase 1
Connect
SSH access and identity
Phase 2
Inspect
OS, CPU, RAM, disks and network
Phase 3
Update
Packages and system configuration
Phase 4
Secure Access
User, sudo and SSH keys
Phase 5
Reduce Exposure
Firewall, ports and services
Phase 6
Verify
Logs, reboot and health checks

🔐 1. Connect to the Server with SSH

Your provider normally gives you an IP address and an initial authentication method, such as a root password or SSH key.

From a terminal, connect with:

ssh root@SERVER_IP

For example:

ssh root@203.0.113.10

The first connection may ask you to confirm the server’s SSH host key. When your provider exposes the expected fingerprint through a trusted channel, compare it before accepting the key.

Check Your Current Identity

whoami

If you connected with the initial administrator account, the output may be root. Root has unrestricted administrative privileges, so commands executed as root deserve extra care.

🔎 2. Identify the Operating System

Before following any Linux tutorial, identify the distribution and release actually installed on your server.

cat /etc/os-release

Check the running kernel with:

uname -r

Distribution and release information matters because package managers, package names, repositories, configuration paths, service names, and security tooling can differ across Linux families.

📊 3. Inspect CPU, Memory and Storage

Before deploying anything, establish a baseline and make sure the virtual machine roughly matches the resources you expected.

⚙️ CPU
lscpu
nproc
🧠 Memory
free -h
💾 Filesystems
df -h
🗄️ Block Devices
lsblk

For disk space, pay particular attention to the filesystem mounted at /. A server can have a large disk attached while its root filesystem is much smaller, so checking only the advertised storage capacity is not enough.

🌐 4. Inspect the Network

For a concise view of network interfaces:

ip -br addr

Then inspect routing:

ip route

You do not need to understand every networking detail yet. At this stage, identify which interfaces exist, which addresses are assigned, and where the default route points.

⬆️ 5. Update Installed Packages

A newly provisioned VPS may have been created from an image that predates current package updates. Updating the system reduces the gap between the image and the currently available packages.

On Ubuntu or Debian:

apt update
apt upgrade

Check whether the system indicates that a reboot is required:

test -f /var/run/reboot-required && echo "Reboot required"
🧠 Academy Insight

Do not reboot simply because updates are finished. If you are still changing remote-access settings, finish and test those changes first so that you know how you will reconnect.

🏷️ 6. Set a Useful Hostname

Inspect the current hostname:

hostnamectl

Set a descriptive hostname:

hostnamectl set-hostname web01

Names such as web01, db01, or vpn01 become useful once you administer more than one machine. Use a naming scheme that remains understandable as your infrastructure grows.

🕒 7. Check the Server Time

Inspect the current configuration:

timedatectl

For example, to use UTC:

timedatectl set-timezone UTC

UTC is commonly used on servers because it gives logs and monitoring systems a consistent reference across locations. What matters most is that your time configuration is deliberate and understood.

👤 8. Create a Separate Administrator

Instead of performing routine administration from a permanent root shell, create a named account and grant administrative privileges through sudo.

adduser admin
usermod -aG sudo admin

Verify group membership:

groups admin

Then test administrative access:

su - admin
sudo whoami

If sudo is configured correctly, sudo whoami should return root.

🔑 9. Set Up SSH Key Authentication

SSH keys let the server authenticate possession of a private key rather than relying only on a reusable login password.

On your local computer, create an Ed25519 key if you do not already have an appropriate SSH key:

ssh-keygen -t ed25519

On systems with ssh-copy-id, you can copy the public key with:

ssh-copy-id admin@SERVER_IP

Then open a new terminal and test:

ssh admin@SERVER_IP
sudo whoami
⚠️ Do Not Skip the Test

Do not disable another working authentication method until the new account and key have been tested in a separate session. A configuration that looks correct on screen is not the same as a login that has actually succeeded.

🛡️ 10. Review SSH Configuration Carefully

OpenSSH server settings are commonly stored in /etc/ssh/sshd_config, although modern installations may also load additional configuration files.

Before editing, create a backup:

sudo cp /etc/ssh/sshd_config /etc/ssh/sshd_config.backup

After making deliberate changes, validate the configuration before reloading the service:

sudo sshd -t

If validation reports no errors, reload SSH:

sudo systemctl reload ssh

If you choose to disable direct root login or password authentication, do so only after confirming that your alternative administrative login works.

🔥 11. Configure a Basic Firewall

A firewall helps limit which network services can be reached. On Ubuntu, UFW provides a convenient interface for managing host firewall rules.

Allow SSH before enabling the firewall:

sudo ufw allow OpenSSH
sudo ufw enable
sudo ufw status verbose

If this server will later host a website, HTTP and HTTPS commonly use:

sudo ufw allow 80/tcp
sudo ufw allow 443/tcp
💡 A Better Firewall Habit

Do not ask, “Which ports should a server have open?” Ask, “Which services does this specific server need to expose?” Everything else can remain unreachable unless there is a reason to allow it.

👀 12. See What Is Actually Listening

Firewall rules tell you what traffic is allowed. You should also know which processes are listening for connections.

sudo ss -tulpn

A fresh server may have only a small number of listening services. Later, a web server may listen on ports 80 and 443, a database may listen locally or on a private network, and additional applications may introduce their own sockets.

An unfamiliar listening port is not automatically malicious. It is a prompt to identify the process and understand why it is there.

⚙️ 13. Review Running Services

List active systemd services:

systemctl --type=service --state=running

Inspect an individual service:

systemctl status ssh

Learning systemctl early is useful because web servers, databases, Docker, SSH, monitoring agents, and many other Linux components are commonly managed as services.

🔄 14. Configure Automatic Security Updates

Ubuntu and Debian systems can use unattended-upgrades to automate selected package updates.

sudo apt install unattended-upgrades
sudo dpkg-reconfigure unattended-upgrades

Automation can reduce the time that known security fixes remain unapplied, but it does not replace backups, monitoring, maintenance planning, application updates, or a recovery strategy.

💽 15. Check Swap

swapon --show
free -h

Some VPS images have swap configured; others do not. That is not automatically a problem. The appropriate configuration depends on available memory, workload behavior, storage characteristics, and operational requirements.

Most importantly, swap is not a replacement for sufficient RAM.

📜 16. Learn Where to Look When Something Fails

You do not need to memorize Linux logging on day one. You should, however, become comfortable asking the system what happened.

Command What It Helps You See
journalctl -p warning -b Warnings from the current boot
journalctl -u ssh SSH service messages
journalctl -u ssh -f Live SSH service log output
dmesg | tail Recent kernel messages

A warning is not automatically a failure. The skill you are building is the ability to observe the server before guessing what is wrong.

🧰 17. Add a Small Administration Toolkit

Minimal server images may omit utilities you expect to find. Install tools because you need them rather than filling the server with packages “just in case.”

A useful starter set might be:

sudo apt install curl wget git nano htop unzip dnsutils
curl
HTTP and network testing
git
Version-controlled projects
htop
Interactive process view
dnsutils
DNS troubleshooting tools

♻️ 18. Reboot and Verify

If a reboot is required after updates, and you have already verified remote access, reboot:

sudo reboot

Reconnect with your administrative account and perform a final check:

uptime
free -h
df -h
sudo ufw status
sudo ss -tulpn
systemctl --failed

Pay particular attention to systemctl --failed. Investigate unexpected failed units before treating the server as ready.

✅ Final Linux Server Checklist

🔐 Access
  • SSH access works.
  • A separate administrator account exists.
  • sudo access has been tested.
  • SSH key authentication works.
  • Access changes were tested from a second session.
⚙️ System
  • Linux distribution and release identified.
  • CPU, RAM, storage, and networking inspected.
  • Available package updates installed.
  • Hostname and timezone reviewed.
🛡️ Exposure & Security
  • Firewall configuration reviewed.
  • SSH remains reachable.
  • Listening ports are understood.
  • Running services have been reviewed.
  • Automatic security updates have been considered or configured.
📊 Health
  • Logs have been inspected.
  • Swap configuration is understood.
  • The server has been rebooted if required.
  • No unexplained failed services remain.

🚫 Common First-Server Mistakes

Changing SSH and Closing the Only Session

Always verify a new login path before disconnecting the session that already works.

Enabling a Firewall Before Allowing SSH

Remote firewall changes should be planned around preserving administrative access.

Installing Everything Immediately

Every additional service adds configuration, resource use, maintenance, and potentially another exposed component.

Copying Commands Without Understanding Them

Administrative commands can change access, networking, files, packages, and security. Understand the purpose of a command before running it as root.

Treating Initial Setup as Permanent Security

A secure baseline is only the beginning. Servers require ongoing updates, monitoring, backups, and application maintenance.

🧪 Knowledge Check

  1. Why should you keep your original SSH session open while changing remote access?
  2. Which file tells you which Linux distribution is installed?
  3. Which commands can you use to inspect RAM and disk usage?
  4. Why create a separate administrative user?
  5. What should you test before disabling an existing SSH authentication method?
  6. Why should SSH be allowed before enabling a remote firewall?
  7. Which command shows listening TCP and UDP sockets?
  8. What does systemctl --failed help you find?
  9. Why is swap not a substitute for sufficient RAM?
🎓 Check Your Answers
  1. So you retain a working connection if the new configuration fails.
  2. /etc/os-release.
  3. free -h and df -h.
  4. To perform routine administration through a named account and elevate privileges with sudo when required.
  5. A successful login using the new account and authentication method, including working sudo access where required.
  6. Otherwise you could block the connection you use to administer the remote machine.
  7. ss -tulpn.
  8. Unexpected failed systemd units.
  9. Swap can help with memory pressure, but it is much slower than RAM and does not provide equivalent capacity or performance.
Servers Academy — Key Takeaway

Your first hour on a Linux server is about establishing control before adding complexity. Know what system you received, preserve reliable administrative access, understand what is exposed to the network, update the base system, and verify its health before deploying applications.

Rate article
Servers Academy
Add a comment