Skip to main content
Updated May 8, 2026 A fresh Raff Linux VM ships ready-to-run, but you should harden it before exposing services. This guide takes a brand-new VM from create to a state safe for production, in about 10 minutes. Steps are written for Ubuntu / Debian; equivalents for RHEL family (CentOS / AlmaLinux / Rocky) are noted inline. For Windows VMs, the equivalent hardening is built into Windows Server defaults; the work is in the dashboard side (Reset password, Firewall).

Before you start

  • VM is active — see Create a VM
  • You can SSH in as root (or you’ve added an SSH key in the create flow)
  • An SSH public key on your local machine for the new user

1. Connect as root

If this is your first time on the VM, accept the host key fingerprint.

2. Update the system

Get the latest security patches before doing anything else. Ubuntu / Debian:
RHEL family:
If the kernel updated, plan a reboot at the end of the steps.

3. Create a non-root user with sudo

Running as root over SSH is a known-bad practice. Create a real user and give it sudo. Ubuntu / Debian:
RHEL family:

4. Copy your SSH public key to the new user

From your local machine (not the VM):
If ssh-copy-id isn’t available, do it manually on the VM:
Test the key login from a new terminal:
Don’t close the original root session until the test succeeds.

5. Lock down SSH

Edit /etc/ssh/sshd_config:
Set or change:
Reload SSH (use systemctl restart if reload doesn’t pick up changes):
Confirm the new user can still log in before closing your existing session. If you mis-edit sshd_config and lock yourself out, recover with the VNC console — you can log in there as root with the password from the Credentials panel.

6. Set up a firewall

Define a default-deny inbound policy and explicitly allow what you need. Ubuntu / Debian — UFW:
RHEL family — firewalld:
The Raff Firewall Group on the network interface and the inside-the-VM firewall stack independently — you need both to allow a port for traffic to reach the service. Most users keep the SG broad and use the OS firewall for fine-grained control, or the reverse. Don’t open ports in both layers without thinking through what’s exposed.

7. Enable automatic security updates

Set the VM to apply security patches without you remembering to. Ubuntu / Debian:
Confirm /etc/apt/apt.conf.d/50unattended-upgrades includes the security source. RHEL family:
Edit /etc/dnf/automatic.conf to set apply_updates = yes if you want full installs (default is download-only).

8. (Optional) fail2ban

fail2ban watches auth logs and bans IPs that fail repeatedly — cheap insurance for any VM with public SSH. Ubuntu / Debian:
RHEL family:
Defaults are sensible. Tune /etc/fail2ban/jail.local if you want longer ban times.

9. Set the timezone (optional)

UTC is the safe default for servers. Pick a local zone only if you really need it for cron schedules or log readability.

10. Reboot

If the kernel updated in step 2 (or if you’re paranoid about pending changes):
After reboot, reconnect as raff and confirm everything’s still working.

You’re done — checklist

  • System fully patched
  • Non-root user with sudo and SSH key login
  • Root SSH login disabled
  • Password SSH login disabled
  • Firewall enabled with default-deny inbound
  • Automatic security updates running
  • (Optional) fail2ban running
  • (Optional) sensible timezone
Your VM is now in roughly the same shape as a freshly-provisioned production host at any cloud you’d come from.

Next steps

Firewall

Tighten the platform-level firewall to match your OS firewall.

Enable backups

Schedule daily or weekly backups before going live.

Monitoring & metrics

Read your VM’s CPU/RAM/network from the dashboard.

Recover a locked-out VM

What to do if the firewall or SSH config locks you out.
Last modified on May 8, 2026