Microsoft Azure Verified Account Azure CentOS VM Initial Server Setup

Azure CentOS VM Initial Server Setup

So you’ve spun up an Azure VM with CentOS. Congratulations! You now have a shiny new computer somewhere in Microsoft’s datacenters, just waiting to be set up for your purposes. Unfortunately, that computer is not automatically aware of your preferences, your security standards, or the fact that you prefer sane defaults over “whatever the template felt like doing.”

Microsoft Azure Verified Account This guide is your responsible adult in a hoodie, walking you through initial setup for an Azure CentOS VM—step by step, with clear structure and a strong emphasis on making the server usable and secure before you start installing big, dangerous software like databases, CI servers, or anything else that screams “please don’t expose me to the whole internet.”

We’ll cover everything from logging in and updating packages, to configuring SSH, setting up firewall rules, installing useful utilities, and preparing storage. You’ll also get practical troubleshooting notes so you can recover quickly when Azure decides to be mysterious (Azure rarely means to be mysterious; it’s just very committed to being cloud-like).

1) Before You Begin: Have the Right Access

Before touching the VM, double-check you have the basics lined up:

• Credentials: SSH access via an SSH key is preferred. If you only have a password, use it temporarily and plan to switch to key-based login.
• Networking: Verify your Azure Network Security Group (NSG) rules allow inbound access only where you actually need it (typically SSH).
• Console access: Keep the Azure Serial Console or console option available in case you lock yourself out (which is not inevitable, but it is a classic rite of passage).

In an ideal world, you would already know which port you’ll use for SSH (default is 22). In the real world, you’ll at least confirm what’s open in the NSG. If you plan to change SSH to a non-standard port, do it carefully after you confirm you can reconnect.

2) First Login and Quick Health Checks

Log into the VM via SSH:

Then, once you’re in, take a minute to verify the system identity and basic health. This is the “meet and greet” moment, like shaking hands with your new server and checking whether it’s wearing shoes.

2.1 Confirm OS version

Run:

cat /etc/os-release

This tells you which CentOS version you’re dealing with. It matters for package names, repository behavior, and whether you’re truly on CentOS Linux 8 versus a stream variant (depending on what you deployed).

2.2 Check kernel and system resources

uname -r
free -h
df -h
uptime

You’re looking for red flags, like an absurdly small root disk, zero free space, or a system that clearly shouldn’t be running yet (we’ll still be patient, but not too patient).

3) Update Packages (Yes, Immediately)

Initial setup should include updates. The server you deployed is typically a “snapshot of time,” not a constantly evolving miracle. So update it right away.

3.1 Clean metadata and update

sudo dnf -y update || sudo yum -y update

On CentOS 7/8 you’ll often have yum, while newer ones might use dnf. If one command fails, use the other. You can also check whether dnf exists:

command -v dnf

3.2 Reboot if required

After updates, you might need a reboot. If a kernel update occurred, you probably will.

sudo needs-restarting -r

If it suggests a restart, do it:

sudo reboot

Then reconnect. The reboot is where the server officially stops pretending it’s still the template.

4) Secure SSH: The “Don’t Get Brute-Forced” Step

SSH is the front door. If you leave it unlocked, you’ll soon discover that the internet is full of people who treat your server like a piñata.

4.1 Check current SSH config

sudo sshd -T | grep -E 'port|passwordauthentication|permitrootlogin|pubkeyauthentication'

This shows the effective settings. Then edit:

sudo vi /etc/ssh/sshd_config

Basic recommended settings:

• Disable password authentication: set PasswordAuthentication no once you’ve confirmed your SSH key works.
• Disable root login: set PermitRootLogin no.
• Use key-based auth: ensure PubkeyAuthentication yes.
• Optionally change SSH port: pick something non-standard if you want, but don’t use security-by-obscurity as your only strategy.
• Limit authentication attempts: MaxAuthTries 3 or similar.

Example snippet:

PasswordAuthentication no
PermitRootLogin no
PubkeyAuthentication yes
MaxAuthTries 3

4.2 Make sure your SSH key is installed

On your local machine, you should already have an SSH key pair. On the VM, ensure your user has an authorized key:

mkdir -p ~/.ssh
chmod 700 ~/.ssh
nano ~/.ssh/authorized_keys

Paste your public key, then:

chmod 600 ~/.ssh/authorized_keys

4.3 Validate config before restarting

sudo sshd -t

If it passes, restart SSH:

sudo systemctl restart sshd

Now test from your local machine immediately. If you set PasswordAuthentication no and your key isn’t correct, you’ll get locked out. That’s why we validated and tested. Reality occasionally disagrees, so be ready with Azure console access if needed.

5) Firewall: Control Inbound Access Properly

In Azure, the NSG is the first gate. On the VM, you’ll often run firewalld or use iptables defaults. You should configure both appropriately, because relying on only one layer is how misconfigurations evolve into “learning experiences.”

5.1 Check firewall status

sudo systemctl status firewalld
sudo firewall-cmd --state

5.2 Allow SSH and block the rest

Assuming SSH on port 22:

sudo firewall-cmd --permanent --add-service=ssh
sudo firewall-cmd --reload

To see what’s currently allowed:

sudo firewall-cmd --list-all

If you changed SSH port in sshd_config, use that port in firewalld instead of the service name.

6) Install Useful Tools (Because You’re Going to Need Them)

Next, install common tools for administration and troubleshooting. A server without basic utilities is like a toolbox missing the screwdriver: you can still work, but it’s slower and your life becomes a scavenger hunt.

6.1 Suggested packages

Depending on your CentOS version, package manager will be yum or dnf. Typical installs:

sudo yum -y install vim wget curl git net-tools bind-utils traceroute

If you prefer nano instead of vim, you can. If you prefer neither, you can use the Azure portal console and write your config using pure optimism. But I assume you have standards.

6.2 Network troubleshooting commands

Install:

sudo yum -y install tcpdump

Optional but helpful:

sudo yum -y install mtr

7) Configure Timezone and Locale

Your logs should make sense. If timezone is wrong, you’ll spend extra time performing detective work later. Let’s prevent that.

7.1 Set timezone

timedatectl

List timezones if needed:

timedatectl list-timezones | grep -i

Set timezone (example):

sudo timedatectl set-timezone America/New_York

7.2 Confirm NTP sync

timedatectl status

Microsoft Azure Verified Account Look for something like “NTP synchronized: yes.” Azure VMs typically sync time, but verify anyway.

8) Storage: Check Disks and Partitions

Azure provides a root disk and optionally additional data disks. Before you install serious workloads, check your disk situation.

8.1 Identify disks

lsblk
sudo fdisk -l

If you see /dev/sda for root and something like /dev/sdc for data, great. If you only have root, you’ll probably stick to default behavior for now.

8.2 Create a filesystem for data disks (if present)

Only do this if you have an unformatted data disk and you intend to use it. Example: assume /dev/sdc.

Be very careful: choosing the wrong device is an “oops” with a capital O. Double-check with lsblk before formatting.

sudo mkfs.xfs /dev/sdc
sudo mkdir -p /data
sudo mount /dev/sdc /data

Confirm mount:

df -h | grep /data

8.3 Make it persistent via /etc/fstab

Use UUIDs for stability. Get UUID:

sudo blkid /dev/sdc

Edit fstab:

sudo vi /etc/fstab

Add a line (example):

UUID=xxxxxxxx-xxxx-xxxx-xxxx-xxxxxxxxxxxx  /data  xfs  defaults,nofail  0  2

Test fstab without reboot:

sudo mount -a

If that’s quiet, you did well. If it complains, stop and fix before rebooting.

9) Swap: Optional, But Don’t Ignore It

Swap isn’t mandatory, but on small instances it can prevent out-of-memory situations from turning into service outages. If your workload is memory-heavy, swap can also slow things down, but it’s often better than the alternative.

9.1 Check current swap

free -h
swapon --show

9.2 Create swap file (if needed)

Microsoft Azure Verified Account Example creates 2GB swap file. Adjust size based on your instance memory and needs.

sudo fallocate -l 2G /swapfile
sudo chmod 600 /swapfile
sudo mkswap /swapfile
sudo swapon /swapfile

Make it persistent in fstab:

echo '/swapfile swap swap defaults 0 0' | sudo tee -a /etc/fstab

Verify:

free -h

10) Create a Practical Admin User (If You Don’t Have One)

If you’re logging in as a standard user (like clouduser) that’s great. If you’re using root directly (not recommended), create an admin user and switch to it.

10.1 Create user

sudo adduser adminuser

10.2 Give sudo privileges

On many CentOS systems, membership in the wheel group grants sudo access. Add the user:

sudo usermod -aG wheel adminuser

10.3 Confirm sudo works

su - adminuser
sudo -v

Microsoft Azure Verified Account If sudo prompts for a password, decide whether you want passwordless sudo via sudoers (usually not ideal) or to stick to key-based SSH without password login.

11) SELinux and System Security Basics

CentOS systems typically have SELinux enabled by default. Disabling it entirely is like removing your smoke detector because it occasionally chirps. If you need to change SELinux mode for an application, do it intentionally and understand why.

11.1 Check current SELinux state

sestatus

Common values:

• Enforcing: security is active.
• Permissive: logs but doesn’t enforce.
• Disabled: SELinux isn’t protecting you.

11.2 Keep SELinux on unless you truly must change it

If you’re deploying software that fails due to SELinux contexts, prefer creating correct policy/context changes. Later in the article, you’ll see how to validate services and troubleshoot. SELinux issues often show up in logs with helpful hints.

12) Enable and Harden Logging

Logs are your server’s memory. When something breaks at 2 a.m., you don’t want the log file to be empty because logging was never configured. Azure provides baseline logging, but local logs still matter for debugging.

12.1 Confirm journald is working

sudo journalctl --since '1 hour ago' | tail -n 50

12.2 Check disk space for logs

df -h

Make sure /var isn’t filling up unexpectedly. If you run heavy workloads, you might eventually need log rotation tuning, but that’s usually later—not on day one.

13) Install and Configure NTP (Time Is Serious Business)

Microsoft Azure Verified Account Most systems already have time sync, especially in cloud environments. Still, confirm you’re using systemd-timesyncd or chrony.

13.1 Check timesync service

systemctl status chronyd 2>/dev/null || systemctl status systemd-timesyncd

13.2 If needed, install chrony

sudo yum -y install chrony

Then:

sudo systemctl enable --now chronyd

14) Validate Services: “Is This Thing Alive?”

Before you move on to installing your actual applications, validate core services. The goal is to confirm the server boots correctly, network is functional, and your remote access is reliable.

14.1 Check SSH service status

sudo systemctl status sshd

14.2 Verify network connectivity

ip a
ip route
ping -c 3 8.8.8.8

Ping is a blunt tool, but it helps quickly identify if you have networking problems.

14.3 Confirm DNS resolution

dig +short example.com
curl -I https://example.com

If DNS is broken, your package installs and external calls later will be miserable. Fix it now by checking /etc/resolv.conf and your Azure DNS settings if needed.

15) Basic Performance Sanity Checks

Your server might be correct but underperforming due to configuration or instance limits. Do a quick look at CPU, memory, and disk latency.

15.1 Quick overview

top
vmstat 1 5
iostat -xz 1 5

If iostat isn’t installed:

sudo yum -y install sysstat

15.2 Watch for obvious issues

• CPU pegged at 100% constantly (unless you’re currently doing a heavy operation).
• Disk I/O ridiculously high with no explanation.
• Memory low and swap constantly churning.

Microsoft Azure Verified Account Don’t overthink it. This is a sanity check, not a medical diagnosis.

16) Troubleshooting: Common “Day One” Problems

Let’s talk about the classic problems people face during initial setup. Some of them are cloud-specific, others are just Linux being Linux.

16.1 Locked out after changing SSH settings

If you disable password login and your key isn’t working, you’ll lose SSH. Fix it using the Azure console and update /etc/ssh/sshd_config back to a workable state. Then verify authorized_keys for your user.

Prevent it next time by testing from a separate terminal before restarting sshd, or by changing one setting at a time.

16.2 Yum/dnf update fails due to repository issues

CentOS ecosystem repository endpoints can change over time. If you see errors about metadata or mirrors:

• Confirm DNS works.
• Check system time (TLS errors often mean time drift).
• Inspect /etc/yum.repos.d/ for broken entries.

If you’re on an end-of-life CentOS version, you might need vault repositories. That’s not unique to your VM, but your specific fix depends on the exact CentOS release.

16.3 Firewall rules conflict with NSG

Sometimes everything is correct inside the VM, but the NSG blocks traffic anyway. Or the reverse: NSG allows, but firewalld blocks. Always check both. When in doubt, test from an external machine.

16.4 Swap created but not used

If you created swap but it doesn’t appear to be used, check swappiness and swap activation.

swapon --show
sysctl vm.swappiness

Also confirm the swapfile permissions and fstab entry are correct.

17) A Simple “Checklist” Version (For When You’re In a Hurry)

If you want a compact list you can follow while you work, here you go:

• Login and verify OS: /etc/os-release
• Update packages: yum/dnf update
• Secure SSH: key-based auth, disable root login, disable password auth (after validating keys)
• Update Azure NSG: allow only what you need (typically SSH)
• Configure firewalld: allow SSH, deny everything else
• Microsoft Azure Verified Account Set timezone and confirm NTP sync
• Check disks: lsblk, mount data disks if present, update fstab
• Optionally create swap file
• Install basic tools (vim, curl, wget, etc.)
• Validate network and DNS: ping, dig, curl
• Confirm sshd status and core services

18) Your Next Steps (After Initial Setup)

Once your CentOS VM is ready, you can move on to your actual mission. For example:

• Install a web server (nginx or Apache) and TLS via Let’s Encrypt.
• Set up a database (PostgreSQL, MariaDB, etc.).
• Deploy an application runtime (Python/Node/Java) and configure systemd services.
• Set up monitoring and alerting (node_exporter, log shipping, etc.).
• Automate with Ansible or cloud-init (so you never repeat setup manually).

And when you do, keep in mind that initial setup is a foundation, not a destination. You don’t just want a server that boots—you want one that behaves predictably when you’re under pressure.

Final Thoughts: Make It Boring (In a Good Way)

When someone asks, “Is the VM set up?” the best answer is “Yes. It’s secure, it updates, it logs, and I can reach it.” Boring servers are reliable servers. Fancy configurations are fun, but boring configurations are what keep your pager quiet.

Follow the steps above, and your Azure CentOS VM will be a solid starting point rather than a mystery novel titled “Why Is Everything on Fire?”

If you want, tell me your CentOS version and whether you’re using additional data disks, and I can tailor the storage and swap recommendations. Also, if you plan to host a specific service (like nginx + app + database), I can suggest a sensible security and package baseline for that workload.