Once your Oracle Cloud instance is created and you can log in over SSH, the real work begins. What determines whether that machine will stay usable over the long run is usually not how fast you install Docker or deploy your app, but whether you take the time to build a clean and safe baseline first.

If you have not finished the earlier setup yet, you can start with [[2026-03-27-oracle-account-machine-application-en]].

An Oracle Cloud server is like any other VPS in one important way: the fact that it boots and accepts SSH does not mean it is ready for long-term public exposure. Many problems do not appear on day one. They show up later, when the server has already become useful: the default user is still doing everything, SSH is too permissive, firewall rules are messy, no one checks logs, and there is no recovery path when something breaks.

This guide focuses on the practical baseline, not flashy configuration. The goal is simple: take a fresh Oracle Cloud machine and turn it into a safer, cleaner server for long-term use, whether that means hosting a blog, a small service, a jump box, or a personal lab.

Why Initialization and Hardening Matter on a Fresh Oracle Server

A lot of people treat “I can SSH into it” as the finish line. In reality, that is just the beginning.

If you plan to use the machine for a blog, a small web service, an experiment environment, or remote administration, the initialization stage should answer at least four questions:

• Who is allowed to log in?
• Which ports are actually exposed?
• How will the system stay updated?
• How will you troubleshoot or roll back when something goes wrong?

If those basics are left unclear, later deployment work may still succeed, but the server will carry unnecessary risk and maintenance debt from the start.

First Login: Check the Machine Before You Build on Top of It

After your first SSH login, do not rush to install services immediately. First, verify what kind of machine you are actually working with.

A simple baseline check looks like this:

uname -a
cat /etc/os-release
free -h
df -h
ip a
ip route

You are mainly confirming the following:

• The operating system is the one you expected, such as Ubuntu or Oracle Linux
• Memory and disk sizes match what you selected in the console
• Network interfaces and IP addresses look normal
• A default route exists

This step feels basic, but it saves time later. Network issues, image mismatches, and compatibility problems involving Docker, IPv6, proxies, or panels often become easier to diagnose if you catch them here instead of halfway through deployment.

Create an Admin User Instead of Living on the Default Account

The default account such as ubuntu or opc is fine for the first login, but it is not ideal as your long-term working identity. A more maintainable setup is to create your own admin user and grant it sudo access.

On Ubuntu, for example:

sudo adduser admin
sudo usermod -aG sudo admin

Then copy your existing authorized key into that user’s home directory:

sudo mkdir -p /home/admin/.ssh
sudo cp ~/.ssh/authorized_keys /home/admin/.ssh/authorized_keys
sudo chown -R admin:admin /home/admin/.ssh
sudo chmod 700 /home/admin/.ssh
sudo chmod 600 /home/admin/.ssh/authorized_keys

Do not remove the default user right away. Open a new SSH session first, confirm that admin can log in correctly, and verify that sudo works as expected. Only then should you decide whether the original account remains as a backup or gets restricted later.

SSH Hardening: Stay Connected First, Tighten Second

SSH is your main management entry point, so the first rule of hardening is simple: do not lock yourself out.

A safe order looks like this:

1. Confirm key-based login works first
2. Edit the SSH configuration
3. Keep one existing session open before restarting the service

A practical baseline usually includes:

• Disable password login
• Disable direct root login
• Keep public key authentication enabled

Edit the configuration file:

sudo nano /etc/ssh/sshd_config

Common settings look like this:

PermitRootLogin no
PasswordAuthentication no
PubkeyAuthentication yes

Before restarting SSH, validate the configuration:

sudo sshd -t

If there are no errors, restart the service:

sudo systemctl restart ssh

If this is your only remote access path, keep one old session alive during the whole process. That single habit can save you from turning a small SSH tweak into a full recovery task.

UFW and Oracle Security Rules Must Be Checked Together

This is one of the most common sources of confusion on Oracle Cloud.

Whether a public connection can reach your service usually depends on at least two layers:

1. The cloud-side security list or NSG must allow the port
2. The instance-side firewall must also allow it

If you check only one side, you can easily reach the wrong conclusion. A service may be listening correctly on the machine and still be unreachable from the internet because one of those layers is blocking it.

If you only need SSH for now, a minimal UFW setup looks like this:

sudo ufw allow 22/tcp
sudo ufw enable
sudo ufw status verbose

If you later deploy web services, open only what you need:

sudo ufw allow 80/tcp
sudo ufw allow 443/tcp

Then go back to the Oracle console and confirm the same ports are allowed in the relevant subnet, security list, or NSG. The practical rule is simple: cloud-side allowance and instance-side allowance must both exist, or public access will still fail.

System Updates, Time Zone, and Automatic Security Patches

Updating a fresh machine should be one of the first standard actions:

sudo apt update && sudo apt upgrade -y

Then check the time and time zone so logs stay meaningful:

timedatectl
sudo timedatectl set-timezone Asia/Shanghai

If the server is meant to stay online for a long time, automatic security updates are worth enabling as well. On Ubuntu, a common setup is:

sudo apt install unattended-upgrades -y
sudo dpkg-reconfigure --priority=low unattended-upgrades

This does not replace regular maintenance, but it does reduce the chance that important security fixes sit uninstalled for too long.

fail2ban: Useful, but Not Magic

If SSH or web services are exposed to the public internet, fail2ban is still a low-cost layer worth having. It is not a replacement for key-based login, firewall rules, or the principle of minimal exposure, but it does help reduce the noise from brute-force attempts and common scanning activity.

Installation is straightforward:

sudo apt install fail2ban -y
sudo systemctl enable --now fail2ban
sudo systemctl status fail2ban

For a personal server, you usually do not need to spend much time tuning jails on day one. In practice, the biggest early win comes from stacking a few simple protections together:

• Key-based login
• Password login disabled
• Only necessary ports exposed
• fail2ban enabled

The goal is not to obsess over one tool. The goal is to keep your total attack surface as small as possible.

Logs, Backups, and Snapshots: Leave Yourself a Way Back

If the machine has any long-term value, plan for recovery before you need recovery.

At a minimum, that usually means three things.

1. Know How to Check Basic Logs

journalctl -p 3 -xb
sudo systemctl --failed

These commands help you quickly spot serious system errors and services that are already failing.

2. Keep Copies of Important Configuration

At a minimum, back up these items:

• /etc/ssh/sshd_config
• Your firewall rules
• Configuration files for the services you deploy later
• Notes about data directories and mount locations

Those details feel small until you need to rebuild, migrate, or roll back. Then they become some of the most valuable information you have.

3. Use Cloud Snapshots or Boot Volume Backups

If Oracle Cloud gives you snapshot or backup options, it is a good idea to create a clean baseline snapshot after initialization and first-round hardening are complete. If a later change breaks the server, recovery becomes much faster and much less painful.

A Practical Pre-Deployment Checklist

Before deploying real workloads, run through this checklist once:

• OS version, disk, memory, and networking have been verified
• An admin user has been created and tested with sudo
• SSH is using key-based login
• Password login and direct root login are disabled
• UFW is enabled and only necessary ports are open
• Oracle security list or NSG rules match the required ports
• The system has been updated
• The time zone is correct
• fail2ban is running
• Backups or snapshots are prepared

Once these basics are done, deploying Docker, a blog, a management panel, a proxy, or other services becomes much safer and easier to maintain.

Final Thoughts

Oracle Cloud server initialization and hardening is not about showing off complicated tricks. It is about handling the simplest and most failure-prone parts first. For most individual users and technical builders, the real priorities are clear: keep access stable, keep maintenance manageable, keep exposure limited, and keep a rollback path available.

If you get user permissions, SSH, firewall rules, system updates, logging, and backups into a solid state, then your Oracle machine is already in good shape for long-term use. From there, whether you want to run a blog, host a small service, deploy Docker, or turn it into a personal operations node, everything becomes easier.

If you want to continue the series, the next article writes itself: something like “Deploying Docker and Common Services on Oracle Cloud,” or “How to Turn an Oracle Cloud Server into a Reliable Personal Operations Node.”