openSUSE Leap Cloud Instance Setup for Production VPS

Start with the right production shape

This tutorial shows you how to turn a fresh openSUSE Leap cloud instance into a production-ready VPS with a non-root admin account, SSH key access, a working firewall, and a basic rollback path. It is a good fit if you need a stable Linux server for agency handovers, small-business launches, or a clean test-to-production move on Hostperl VPS hosting.

We use openSUSE Leap because it fits long-lived server builds well in 2026. The steps here are specific to openSUSE Leap and rely on zypper, systemd, firewalld, and AppArmor. If your workload outgrows a single VPS, Hostperl’s dedicated server hosting is the natural next step for more storage, traffic, or isolation.

Before you begin, keep one root SSH session open until the new account is confirmed. That gives you a recovery path if a firewall rule or SSH setting goes wrong.

Connect to the VPS and detect the OS

On your local computer, connect to the server with the reserved documentation IP first. Replace 203.0.113.10 with the real public IP assigned to your VPS by Hostperl.

ssh root@203.0.113.10

If your provider gives you a default non-root login, use that same IP with the provider’s account name instead. For a custom SSH port, the form is:

ssh -p 2222 root@203.0.113.10

On the VPS as root, confirm the operating system before you change anything:

cat /etc/os-release

You should see openSUSE Leap details in the output. This check matters because package names, firewall behavior, and service paths differ from Ubuntu or RHEL-compatible systems.

Create a non-root administrator account

Use a separate admin account for routine work. For Hostperl support handovers, this keeps root access limited while still leaving you a clear rescue path.

On the VPS as root, create the account, set its password, and add it to the sudo-capable group:

useradd -m -s /bin/bash -G wheel deploy
passwd deploy

On the VPS as root, create the SSH directory and copy your public key. Replace the key text with your actual public key.

install -d -m 700 -o deploy -g deploy /home/deploy/.ssh
cat > /home/deploy/.ssh/authorized_keys <<'EOF'
ssh-ed25519 AAAAC3NzaC1lZDI1NTE5AAAAIExampleKeyHereDeployLoginOnly
EOF
chown deploy:deploy /home/deploy/.ssh/authorized_keys
chmod 600 /home/deploy/.ssh/authorized_keys

These permissions keep SSH from ignoring the key file. If they are too open, login usually fails with a public-key error.

Now open a second terminal and test the new login before you change anything else.

On your local computer, connect as the new user:

ssh deploy@203.0.113.10

Then verify sudo works:

sudo -l

You should see sudo rights for the account. If that fails, go back to the root session and check group membership with id deploy.

Update packages and set the server baseline

On the VPS as the non-root sudo user, refresh package metadata and install the packages needed for administration and firewall control:

sudo zypper refresh
sudo zypper update -y
sudo zypper install -y vim curl firewalld sudo

This brings the VPS current and makes sure the tools used later in the tutorial are installed. openSUSE Leap uses zypper as its native package manager, so do not swap in apt or dnf here.

Check your hostname, then set one if the provider left it generic. Replace the example hostname with your own internal naming standard.

hostnamectl status
sudo hostnamectl set-hostname server.example.com

Time sync should be healthy before you rely on logs, TLS, or cron jobs.

timedatectl status

If NTP is off, enable it:

sudo timedatectl set-ntp true

For more background on early VPS planning, Hostperl’s 2026 VPS and cloud buyer checklist is a useful companion, especially if you are still deciding whether this instance belongs in production or staging.

Enable firewalld safely before tightening SSH

Because you still have the original root session open, you can tighten the network in a safe order. Allow SSH first, then activate the firewall.

On the VPS as the non-root sudo user, start and enable firewalld:

sudo systemctl enable --now firewalld
sudo systemctl status firewalld --no-pager

Open the SSH service so you do not lock yourself out:

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

You should see ssh in the allowed services list. Only after that should you test whether the new user can reconnect cleanly.

On your local computer, open a fresh terminal and reconnect as deploy:

ssh deploy@203.0.113.10

If this works, your firewall is not blocking SSH. Keep the root session open until you finish the remaining checks.

Harden SSH without breaking access

Now tighten SSH. On openSUSE Leap, the main SSH daemon config is usually /etc/ssh/sshd_config. Make small changes and test the syntax before you restart anything.

On the VPS as the non-root sudo user, open the SSH config file:

sudo vi /etc/ssh/sshd_config

Use these settings, or confirm they are already present. Keep password authentication enabled only until you have proven key login from a second terminal.

PermitRootLogin no
PasswordAuthentication no
PubkeyAuthentication yes
KbdInteractiveAuthentication no
X11Forwarding no
AllowUsers deploy

Save and exit vi with :wq. Then test the syntax before touching the running service:

sudo sshd -t

If the command returns no output, the file parsed correctly. Now reload SSH instead of forcing a full restart:

sudo systemctl reload sshd

Try a fresh login from your local computer before you close the old session.

ssh deploy@203.0.113.10

If the login fails, use the still-open root shell to restore the previous config, run sshd -t again, and reload. That is the safest rollback for SSH changes.

Lock in AppArmor awareness and basic server hygiene

openSUSE Leap ships with AppArmor enabled by default on many installations. Check its status instead of assuming it is active.

sudo aa-status

You should see loaded profiles if AppArmor is active. If you later deploy Nginx, PostgreSQL, or Docker, this check helps explain access denials that are not really package bugs.

Review current login and service health in one pass:

who
uptime
systemctl --failed

This gives you a clean baseline after the first hardening steps.

Confirm network reachability and listening services

Production VPS work is not finished until the machine answers on the expected ports and the firewall matches that state. From the server, confirm SSH is listening:

sudo ss -tulpn | grep -E ':(22|2222)\b'

You should see sshd bound to port 22 unless you changed it. From your local computer, run a simple reachability check:

ssh deploy@203.0.113.10 'hostnamectl; uptime'

This verifies both SSH access and the shell environment in one command. If it prints the hostname and uptime, the VPS is ready for application work.

Build a safe rollback path before you add applications

Every production VPS needs a clear way back. On a fresh openSUSE Leap instance, the rollback plan is simple: keep the original root session until the new account, firewall, and SSH settings are proven; save a copy of the working SSH config; and note the firewall rules you added.

On the VPS as the non-root sudo user, back up the current SSH and firewall state:

sudo cp /etc/ssh/sshd_config /etc/ssh/sshd_config.bak
sudo firewall-cmd --list-all > ~/firewalld-current.txt
sudo cp ~/firewalld-current.txt ~/firewalld-current.txt.bak

If you later break access, restore the SSH config backup, check syntax, and reload sshd. For firewall problems, use the saved rule list to remove or re-add services in the right order.

What to do next on a production openSUSE Leap VPS

At this point you have the essentials in place: SSH key access, a non-root admin, a working firewall, updated packages, and a tested rollback path. That is enough to start deploying web apps, databases, or control-panel-managed sites without beginning from a risky default state.

If you are planning a migration, compare the instance size against your real workload, not guesswork. Hostperl’s resource planning guide is useful even if your target OS is different, because the sizing logic stays the same: CPU, RAM, disk IOPS, and transfer headroom all need to match the application profile. For launch-ready production boxes, Hostperl VPS hosting keeps the path simple; if you outgrow the virtual machine, move to dedicated server hosting for stronger isolation and more predictable hardware.

Troubleshooting the most common failures

SSH key login fails

sudo ls -ld /home/deploy /home/deploy/.ssh /home/deploy/.ssh/authorized_keys
sudo tail -n 50 /var/log/messages

Expected clue: the permissions should be 700 on .ssh and 600 on authorized_keys. If they are wrong, fix ownership and permissions again with chown and chmod.

sshd will not reload

sudo sshd -t
sudo systemctl status sshd --no-pager

Expected clue: sshd -t prints the line and option that caused the failure. Correct the file in /etc/ssh/sshd_config, then rerun the syntax check before reloading.

Firewall blocks access after a change

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

Expected clue: ssh should appear in the allowed services list. If it does not, add it first and reload the zone before testing from a second terminal.

AppArmor or policy denies a service later

sudo aa-status
sudo journalctl -p warning -xb

Expected clue: the denial will usually show in the journal or AppArmor output. That tells you whether the fix belongs in the service profile, file permissions, or the application config.

Final verification checklist

On the VPS as the non-root sudo user, confirm the machine is in the expected state after a reboot-safe setup:

systemctl is-enabled sshd
systemctl is-enabled firewalld
systemctl status sshd --no-pager
systemctl status firewalld --no-pager
ss -tulpn
sudo reboot

After the reboot, reconnect from your local computer and confirm the same account still works:

ssh deploy@203.0.113.10

Then run one last smoke test from the server:

hostnamectl
uptime
sudo firewall-cmd --list-all

If these checks pass, your openSUSE Leap cloud instance is ready for production deployment.

FAQ

Can I skip the root session after the new user works?
Wait until the SSH hardening and firewall checks pass from a second terminal. Then you can close the root session safely.

Why use openSUSE Leap for a VPS?
It gives you a stable release, modern packages, and predictable system administration with zypper, systemd, firewalld, and AppArmor.

Should I disable password authentication immediately?
Only after you confirm key-based login from a new terminal. The safer order is account creation, key setup, test login, then disable passwords.

What if I need more isolation later?
If your workload grows beyond what a single VPS should carry, move the application to a dedicated server or split services across separate instances.

Does this setup help with migrations?
Yes. A predictable login path, firewall baseline, and rollback file set make later migrations easier to support and easier to hand over to another admin.