Azure Pay-As-You-Go Account Azure CentOS VM Initial Server Setup

Azure Account / 2026-05-16 21:55:28

Azure and CentOS can get along famously, but only after a bit of “let’s untangle this mess” work. The first time you spin up a fresh CentOS VM on Azure, you’re usually greeted with a machine that boots, responds, and technically exists—kind of like a teenager who has moved out but left all the tools in the driveway. This article is your tidy-up checklist, your bedtime story, and your “do it once so you don’t curse later” guide for the initial server setup.

1) The Goal: A Working, Secure Baseline

The purpose of an initial setup isn’t to show off; it’s to create a reliable foundation. After you finish, you should have:

Updated packages and a predictable system state
Correct timezone and time sync
Secure access (especially SSH) for you and only you-ish
A sensible user and permissions model
Networking sanity checks
Firewall choices that don’t sabotage your future self
Useful tools installed
Disk layout, swap, and storage behavior you understand
Monitoring hooks or at least log visibility

Think of it as giving your VM a healthy breakfast, a seatbelt, and a small checklist taped to the inside of the cover. Future-you will appreciate the effort and never admit it out loud.

2) Before You Touch the Server: Azure-Prep Stuff

Before logging in, confirm the basics in the Azure portal (or your Infrastructure-as-Code setup):

VM size: Enough CPU/RAM for your workload. For initial setup, you can start smaller, but avoid “totally free” sizes if you plan heavy tasks.
Region: Same region as other dependencies you’ll use, such as databases or storage accounts.
Networking: Make sure your VM is in the right Virtual Network and Subnet. If you plan to lock down access, know what your IP ranges are.
Public inbound ports: Decide what you actually need. Usually SSH (22) and maybe HTTP/HTTPS if hosting something.
Authentication method: Azure supports keys and passwords depending on your configuration. Keys are the adult option.

Also, if you’ll use managed identity or cloud integrations, think ahead. Initial setup is when you should install anything required for those integrations, not three weeks later when an alert starts screaming.

3) Logging In: Don’t Assume the Keys Know You

Once the VM is running, you’ll connect using SSH. The “initial” login usually involves either the default user (common in cloud images) or the user you specified. If you’re using an SSH key, ensure your local SSH client is configured to use the right key for the VM.

At this point, your first tasks are simple but important:

Confirm you can log in reliably
Check OS info and kernel version
Verify you have working DNS/resolution

3.1 Check system identity

On the VM:

cat /etc/centos-release
uname -r
hostnamectl

If hostnamectl exists (often it does), it’ll show you hostname and related info. If it doesn’t, don’t panic. Some systems arrive wearing minimal outfits.

3.2 Check networking sanity

Verify you have an IP address and that name resolution works:

ip addr
ip route
getent hosts google.com

If name resolution fails, you might need to check /etc/resolv.conf. In cloud environments, resolv.conf is sometimes managed by cloud-init or network services. If it’s weird, fix it properly rather than just hacking it with random lines and prayers.

4) Update Packages: The “Fresh Boot, Still Needs Work” Step

Even if your CentOS image looks complete, it’s not truly fresh until you update. Do it early so later installations use modern dependencies instead of whatever stale surprises the image shipped with.

4.1 Clean and update with DNF or YUM

CentOS versions differ in package manager, so you’ll see either dnf or yum. For many CentOS 7 systems, yum is common. For newer, you may see dnf.

Try the one that exists:

command -v dnf || command -v yum

Then run:

# If using yum
sudo yum clean all
sudo yum -y update

# If using dnf
sudo dnf clean all
sudo dnf -y update

After updates, reboot only if a kernel or critical libraries changed. You can decide based on output, but if in doubt, reboot. Uptime can be “too fresh to trust” sometimes.

4.2 Reboot when needed

sudo reboot

SSH will drop during the reboot, so just wait a bit and reconnect.

5) Timezone and Time Sync: Make Logs Behave

Time is one of those boring things that becomes exciting only when you need to diagnose an incident. If your VM clock is off, log timestamps won’t line up with Azure events or your other systems.

5.1 Set timezone

Check your current timezone:

date
timedatectl

If timedatectl exists, set it:

# Example: set to UTC
sudo timedatectl set-timezone UTC

Or use your preferred timezone. UTC is a popular choice because it’s less “fun” and more “consistent.”

5.2 Enable time synchronization

Many CentOS systems use chrony. Confirm and enable:

sudo systemctl status chronyd
sudo systemctl enable --now chronyd

If chrony isn’t installed or you’re using ntpd instead, install or enable the correct service. The key is: ensure time sync is active.

6) Create a Proper User and Clean Up Default Credentials

Using the default cloud user for everything is like using a Swiss Army knife as a hammer: it will work, but you’re going to regret it later. Instead:

Create a dedicated admin user
Use SSH keys for authentication
Grant sudo privileges carefully
Optionally disable password login

6.1 Add a new user

Azure Pay-As-You-Go Account Pick a username (for humans, not for spreadsheets). Then:

sudo useradd -m -s /bin/bash yourusername
sudo passwd yourusername

You can set a password, but if you use SSH keys, the password might become optional. Still, having a password set can provide a fallback path in emergencies.

6.2 Add the user to sudoers

On CentOS, use wheel group for sudo:

sudo usermod -aG wheel yourusername

Then ensure wheel group is allowed in sudoers:

sudo visudo

Azure Pay-As-You-Go Account Look for a line like:

%wheel  ALL=(ALL)       ALL

If it’s commented out, enable it. Save and exit.

7) SSH Hardening: Because “Waving at the Internet” Is Not a Strategy

Now we switch to the part that prevents your server from becoming a hobby for bots. SSH should be locked down. The exact configuration depends on your environment, but here’s a solid baseline.

7.1 Ensure SSH service is running

sudo systemctl status sshd
sudo systemctl enable --now sshd

7.2 Use SSH keys and restrict authentication

On your local machine, generate a key if needed:

ssh-keygen -t ed25519 -C "your-email"

Then copy the public key to the server:

ssh-copy-id yourusername@<VM_IP>

If ssh-copy-id isn’t available, you can manually append your key to ~/.ssh/authorized_keys. The goal is the same: key-based login.

7.3 Update SSH daemon configuration

Edit /etc/ssh/sshd_config:

sudo vi /etc/ssh/sshd_config

Recommended options (adjust carefully):

Disable password authentication
Disable root login
Restrict allowed users
Prefer keys

Example configuration snippet:

PasswordAuthentication no
PermitRootLogin no
PubkeyAuthentication yes
ChallengeResponseAuthentication no
UsePAM yes
AllowUsers yourusername

Note: AllowUsers is powerful. If you set it and forget your own username, you can lock yourself out. Test carefully, ideally with an existing session open before restarting sshd.

7.4 Restart SSH safely

sudo sshd -t
sudo systemctl restart sshd

The sshd -t test command checks for syntax errors. It’s the difference between “secure” and “oops.”

8) Firewall: Choose Your Weapon (But Learn How to Aim It)

Most Azure setups rely on Network Security Groups (NSGs) at the platform layer. Still, enabling a host firewall prevents accidental exposure from misconfiguration and helps limit lateral traffic.

CentOS commonly uses firewalld.

8.1 Check firewalld status

sudo systemctl status firewalld

If it’s not running, you can enable it:

sudo systemctl enable --now firewalld

8.2 Allow SSH and other required ports

Allow SSH (port 22) at minimum:

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

If you’ll run a web server later, you’ll open 80/443 then. For now, keep it minimal unless you have a good reason not to.

8.3 Verify firewall rules

sudo firewall-cmd --list-all

Confirm ssh is present, and nothing unexpected is open.

9) Install Useful Tools: The “I’ll Need This Later” Package Party

Your initial setup is a great time to install common utilities. Don’t go overboard with everything under the sun, but do install what you’ll likely need for administration, diagnostics, and future automation.

9.1 Common basics

Install tools like:

curl
wget
vim or nano (choose one)
htop
tmux
git
rsync
policycoreutils-python-utils (often useful for SELinux troubleshooting)

Install them with yum/dnf:

sudo yum -y install curl wget vim-enhanced htop tmux git rsync

On systems using dnf:

sudo dnf -y install curl wget vim-enhanced htop tmux git rsync

9.2 Enable useful terminal habits

Install tmux and use it. You’ll thank yourself later when you accidentally close your SSH session during an upgrade and pretend it never happened.

10) Disk Layout and Swap: Make Performance Less “Mystical”

Cloud VMs can come with different disk configurations. Azure often attaches OS disks and optionally data disks. Your job is to understand what’s mounted, how much space you have, and whether swap exists and behaves.

10.1 Check disk usage

lsblk
df -hT

Look for:

Root filesystem size and free space
Any additional attached disks
Whether /var is on the root partition (common, but not always ideal)

10.2 Check swap

free -h
swapon --show

If swap is missing and you expect memory pressure, consider adding it. For servers that will run databases or memory-heavy services, swap strategy depends on the workload. But at least know what you’re running with.

10.3 Create swap file (only if appropriate)

If you truly want a basic swap file, a common approach is:

# Example: 2G swap file
sudo fallocate -l 2G /swapfile
sudo chmod 600 /swapfile
sudo mkswap /swapfile
sudo swapon /swapfile

Azure Pay-As-You-Go Account To make it persistent:

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

Then verify:

free -h
swapon --show

Note: On some systems, fallocate might not be available; you can use dd as an alternative. Also, swap performance can affect workloads, so treat this as a baseline, not a universal rule.

11) Storage: Mount Data Disks (If You Have Them)

Most “serious” VMs use data disks for logs, application storage, or caches. Azure data disks appear as block devices. You need to partition (sometimes), format, and mount them.

11.1 Identify unattached disks

Run:

lsblk -f

You’ll see devices with no filesystem. If there’s data already, be cautious. If the disk is brand new, it may show no filesystem type.

11.2 Format and mount (example workflow)

Let’s say you want to mount a new disk at /data. A typical approach:

# WARNING: replace /dev/sdc with your actual device
sudo mkfs.ext4 /dev/sdc
sudo mkdir -p /data
sudo mount /dev/sdc /data

Make persistent using UUID:

sudo blkid /dev/sdc

Copy the UUID, then edit /etc/fstab:

sudo vi /etc/fstab

Add a line like:

UUID=your-uuid-here  /data  ext4  defaults,nofail  0  2

Then test:

sudo mount -a
df -hT

If the disk fails to mount, nofail prevents the system from panicking on boot, which is often what you want in early experiments.

12) SELinux: Know Your Mode Before You “Fix” It

SELinux can be enabled or disabled depending on the image. Many administrators either ignore it until things break, then flip it off and declare victory. That’s a valid coping mechanism in emergencies, but it’s better to understand what’s happening.

12.1 Check SELinux status

sestatus

Look for “enforcing,” “permissive,” or “disabled.”

12.2 Typical approach

For initial setup, you usually don’t need to change SELinux settings. If later your application complains, you can:

Check audit logs
Create proper policies
Use audit2allow where appropriate

If you must change mode, do it thoughtfully. Disabling SELinux permanently is the IT equivalent of removing the smoke detector because it keeps chirping.

13) Configure Repos and Package Sources (So Updates Don’t Become a Hobby)

CentOS lifecycle history is… complicated. Depending on the version and image, you might need to confirm repositories are configured correctly for updates.

Azure Pay-As-You-Go Account Check enabled repos:

sudo yum repolist enabled

Or for dnf:

sudo dnf repolist enabled

If updates fail, you may see errors about missing repos, expired metadata, or connectivity issues. Fix those early while your sanity is still intact.

14) Install Azure VM Extensions (Optional but Often Helpful)

Depending on what you want to do, you might need Azure-related agents or extensions. Azure provides monitoring and management capabilities that can be installed as extensions. In many real deployments, these are beneficial.

Common reasons to add extensions:

Enable metrics/log collection
Install monitoring agents
Azure Pay-As-You-Go Account Enable identity integrations
Support for specific platform features

If your organization uses them, install early. If you’re running a standalone VM for learning purposes, you can skip until you’re ready.

15) Cloud-Init and First-Boot Behaviors: Don’t Get Surprised

Many Azure Linux images rely on cloud-init for first-boot configuration. That’s helpful, but it also means some files might be generated dynamically (including network and SSH settings). If you modify something cloud-init also touches, it could revert on reboot.

Azure Pay-As-You-Go Account 15.1 Check cloud-init status

sudo cloud-init status --long

If cloud-init is active, it may re-run modules. You can usually see what modules executed by reading logs:

sudo tail -n 200 /var/log/cloud-init-output.log

And:

sudo ls -1 /var/log/cloud-init*

Azure Pay-As-You-Go Account If you’re creating your own initialization logic, coordinate with cloud-init instead of fighting it. That way lies fewer tears.

16) Basic System Security: Limits, Updates, and Fail2ban (Optional)

Security doesn’t mean “paranoid.” It means “sensible defaults plus fewer surprises.” Here are common additions to consider.

16.1 Ensure automatic security updates (optional)

Many organizations prefer patch management via automation. But if you’re doing a smaller setup, consider installing a service to auto-update. Exact choices vary by policy.

At minimum, schedule regular updates and keep track of reboots.

16.2 Fail2ban for SSH (optional)

Fail2ban can reduce brute-force attempts by temporarily banning IPs with repeated failed login attempts. If you already rely on NSGs restricting inbound traffic and use key-based authentication, you may not need it. But it’s a nice extra layer.

Install and configure:

sudo yum -y install fail2ban
sudo systemctl enable --now fail2ban

Then configure /etc/fail2ban/jail.local for SSH settings. Keep your configuration conservative so you don’t ban your own office IP like an overenthusiastic bouncer.

17) Verify Everything Works (The Part Everyone Skips—Until It Hurts)

After configuration, you want to verify the basics:

Azure Pay-As-You-Go Account You can SSH in (with your key and intended user)
SSH service is running
Firewall allows only needed ports
Time sync is active
Disk mounts are correct and persistent
DNS works

17.1 Quick verification commands

# SSH service
sudo systemctl status sshd

# Firewall
sudo firewall-cmd --list-all

# Time sync
chronyc tracking 2>/dev/null || true

# DNS resolution
getent hosts example.com

# Disk mounts
findmnt -no TARGET,SOURCE,FSTYPE / /data 2>/dev/null || df -hT

If any check fails, fix it now. It’s far easier to debug while the environment is still simple.

18) Snapshot Your Happiness

Azure Pay-As-You-Go Account Once your VM is in the “good state,” consider creating a snapshot (or using a managed image approach) so you can reproduce the setup quickly later. This is the infrastructure equivalent of writing down your recipe so you don’t have to reinvent the cake after forgetting what you did last time.

In Azure, snapshot options depend on how your VM disks are configured. If you’re building multiple similar VMs, capturing this baseline is extremely useful.

19) Common Azure CentOS Setup Gotchas (So You Can Avoid Facepalms)

Here are the classic pitfalls people hit during initial setup:

19.1 Losing SSH access after hardening

This happens when you change sshd_config and then restart without verifying allowed users, authentication methods, or firewall/NSG rules. Solution: keep a working SSH session open and test sshd -t before restart. Also confirm your Azure NSG still allows port 22 from your IP.

19.2 Time drift causing confusing logs

If time sync isn’t active, you can end up with logs that don’t match Azure alerts. Solution: ensure chrony or the time service is enabled.

19.3 Disk mounts that don’t persist

Usually due to missing fstab entries or wrong device names (/dev/sdc might change across boots). Solution: use UUIDs in /etc/fstab and test with mount -a.

19.4 Updates failing due to repos

If you can’t update packages, your later installations may break due to missing dependencies. Solution: check enabled repos and networking, then fix repository configuration early.

19.5 SELinux surprises

If an application fails later, SELinux might be blocking it. Don’t disable SELinux reflexively. First check audit logs.

20) A Simple “Initial Setup” Checklist You Can Reuse

Here’s a condensed checklist you can keep on a sticky note (digitally or physically, depending on your chaos tolerance):

Log in and confirm OS info (centos release, kernel, hostname)
Verify networking and DNS resolution
Update packages (yum/dnf) and reboot if required
Set timezone and enable chrony
Create admin user, add to wheel group
Install SSH keys and harden sshd_config
Restart sshd safely (sshd -t, then restart)
Enable and configure host firewall (allow ssh only)
Install essential tools (curl, git, tmux, etc.)
Check disks and swap; create swap only if appropriate
Format and mount any data disks; use UUIDs in fstab
Validate everything: SSH, firewall, time, mounts, DNS
Snapshot the VM or save an image for repeatability

If you do these steps consistently, your VM goes from “random machine in a box” to “reliable server with manners.”

21) Next Steps: What to Do After Initial Setup

Once your baseline is solid, your next moves depend on your workload. Common paths include:

Install a web server or application runtime (NGINX/Apache, Node.js, Python, Java)
Set up a database (MySQL/PostgreSQL) with secure configuration
Configure containers with Docker or Podman
Set up CI/CD deployment scripts
Implement monitoring and log aggregation
Harden further: automatic updates, audit rules, least privilege, secret management

But don’t rush. Most production problems start when someone skips the boring initial groundwork and then tries to build a skyscraper on a trampoline.

Final Thoughts: Congratulations, You Built a Server That Behaves

Azure CentOS VM initial setup is not glamorous, but it’s incredibly satisfying in the way that organizing your cables is satisfying. You might not brag about it at parties, but you’ll be thankful when things stop failing randomly.

By following this guide, you now have a stable, secure baseline with predictable system behavior. And if you ever need to create another VM, you can repeat the process quickly—or better yet, automate it so the next deployment doesn’t require human memory, brute force, and a prayer.

May your SSH sessions stay connected, your disks mount correctly, and your logs line up with the timeline of events like synchronized swimmers who don’t panic when the lifeguard looks away.