Five Commands I Run First on Any New Linux Server

Whether it's a fresh cloud instance, a server someone has handed over or a machine in my home lab, I follow the same habit before I change anything: I take a few minutes to understand what I'm looking at.

What version is it running? Who can log in? What's listening on the network? What's using resources? What needs updating? The answers shape every decision that follows, from hardening steps to troubleshooting. They also establish a baseline, so I can recognize unusual activity later.

I work mostly with Ubuntu, both on my home lab server and in study, and I've used Kali Linux extensively for security work. The commands below work on Ubuntu and most other modern distributions. Some need sudo to show complete results.

1. What is this machine? hostnamectl and uname -a

Start with the basics: what operating system and version is this, and what kernel is it running?

hostnamectl
uname -a
cat /etc/os-release

What to look for:

• The distribution and version. Is it a supported release? A server on a version that no longer receives security updates is a significant risk and should be planned for upgrade.
• The kernel version. Useful when checking whether known vulnerabilities apply.
• The hostname. Does it match your documentation? Unexpected hostnames are a sign the system isn't what you think it is.
• Virtualization. hostnamectl usually reports whether this is a virtual machine or container, which affects how you manage and back it up.

This takes ten seconds and prevents a surprising number of mistakes, like following instructions written for a different distribution or version.

2. Who's here, and who has been here? w, last and the user list

Next, I want to know who's logged in now, who has logged in recently and which accounts exist.

w
last -n 20
lastb -n 20   (requires sudo)
getent passwd | awk -F: '$3 >= 1000 {print $1}'
getent group sudo

What to look for:

• Current sessions (w). Is anyone else logged in? From where?
• Recent logins (last). Are the users, times and source addresses expected? A login from an unfamiliar address or at an unusual hour deserves a question.
• Failed logins (lastb). Many failed attempts, especially from internet addresses, show that the server is being targeted, which is common for anything with SSH exposed.
• Human accounts. On many distributions, regular users have IDs of 1000 and above. Are there accounts nobody recognizes, or accounts belonging to people who've left?
• Admin rights. Who is in the sudo group (or wheel on some distributions)? Every admin account should be justified.

3. What's listening? ss -tulpn

This is the command I consider most important for security. It shows every network port the server is listening on and which process owns it.

sudo ss -tulpn

The flags show TCP and UDP sockets that are listening, with numeric addresses and the owning process.

What to look for:

• Every listening service should have a reason. If you see a database, web server or remote access tool you didn't expect, find out why it's there.
• The bind address. A service listening on 127.0.0.1 is only reachable from the server itself. One listening on 0.0.0.0 or [::] is reachable from the network. Databases and admin interfaces usually shouldn't be exposed to the network at all.
• SSH. Usually on port 22. Note it, because it will be one of the first things you harden.
• Unusual high ports with unfamiliar process names. These can indicate leftover test services or, occasionally, something malicious.

Then I compare this with the firewall:

sudo ufw status verbose

Or, on systems that don't use UFW, the nftables or iptables rules. Listening services plus firewall rules together tell you what's actually exposed.

4. What's running? systemctl and top

Now I look at what the server is doing: which services are enabled and running, and what's consuming resources.

systemctl list-units --type=service --state=running
systemctl list-unit-files --state=enabled
top   (or htop, if installed)
df -h
free -h

What to look for:

• Running services. Do they match the server's purpose? A web server shouldn't also be running a mail server unless that's intended. Every unnecessary service is extra attack surface and extra patching.
• Enabled services. These start at boot. Something enabled but not currently running can surprise you after the next restart.
• CPU and memory use. A process consuming heavy CPU on an otherwise idle server could be a misbehaving application, or something like a cryptocurrency miner installed by an attacker.
• Disk space. Full disks break services and stop logs from being written, which can hide problems. I've seen more outages caused by full disks than I can count.

I also glance at scheduled tasks, since persistence often hides there:

crontab -l
sudo ls /etc/cron.*
systemctl list-timers

5. What needs updating? apt list --upgradable

Finally, I check the server's patch status.

sudo apt update
apt list --upgradable

On Red Hat-based systems, dnf check-update does the same job.

What to look for:

• How many updates are waiting. A long list suggests the server hasn't been maintained.
• Security updates in particular. On Ubuntu, these come from the security repository. They should be applied promptly.
• Whether automatic security updates are enabled. On Ubuntu, the unattended-upgrades package handles this. For many servers, automatic security updates are a sensible default.
• Whether a reboot is pending. On Ubuntu, the file /var/run/reboot-required exists if updates need a restart to take effect. Kernel updates don't protect you until you reboot.

Bonus: check the logs

If I have a few more minutes, I look at recent system and authentication logs:

journalctl -p err -b
sudo journalctl -u ssh --since "24 hours ago"
sudo tail -n 50 /var/log/auth.log

Errors since boot, repeated failed SSH attempts or unexpected sudo activity are all worth knowing about before you start making changes.

The first change I usually make: hardening SSH

If the server is reachable over SSH, which most are, that's usually the first thing I tighten, because it's the front door for administrators and a constant target for automated attacks.

My typical steps:

1. Set up key-based login for my account first, and test it in a second terminal before changing anything else. Locking yourself out of a remote server is a lesson you only want to learn once.
2. Disable password authentication, so stolen or guessed passwords can't be used to log in.
3. Disable direct root login, so administrators log in as themselves and use sudo, which leaves a clearer audit trail.
4. Limit who can log in, for example with an AllowUsers or AllowGroups line.
5. Restrict where SSH can be reached from, using the firewall to allow only trusted networks or a VPN where possible.

The relevant settings live in the SSH server configuration file, /etc/ssh/sshd_config. Open it with an editor such as sudo nano, then set:

PasswordAuthentication no
PermitRootLogin no
AllowGroups sshusers

Save the file, then test and apply the change:

sudo sshd -t
sudo systemctl reload ssh

The sshd -t command tests the configuration for errors before you reload, which prevents a typo from breaking remote access. On some distributions the service is named sshd rather than ssh, and newer Ubuntu releases may also read settings from files in /etc/ssh/sshd_config.d/, so check there too.

In my home lab, SSH is reachable only from inside my network or over my WireGuard VPN. Nothing about it is exposed directly to the internet, and the failed-login logs stay quiet as a result.

Turning observations into actions

These checks aren't just for information. They feed directly into a short action list. Typical items include:

• Apply pending security updates and reboot if required.
• Remove or disable services that aren't needed.
• Close or restrict ports that shouldn't be exposed.
• Remove unknown or stale accounts, and reduce admin rights to those who need them.
• Switch SSH to key-based authentication and disable password logins.
• Enable a host firewall and allow only required ports.
• Turn on automatic security updates where appropriate.
• Write everything down, including the original state, so there's a record to compare against later.

Why this habit matters

Running the same checks every time makes you faster and more consistent. It also gives you a baseline. If you know what normal looks like on day one, you'll notice when something changes on day ninety: a new listening port, an unfamiliar account, a process that shouldn't be there. That's how many intrusions are first spotted.

A few minutes of observation before acting is one of the cheapest security habits there is.

What's the first command you run when you log in to an unfamiliar server?