Recommended Free Tools
iTechGuides is reader-supported. When you buy through links on our site, we may earn an affiliate commission. As an Amazon Associate I earn from qualifying purchases. Learn more
Need a server to try this on? Antihost offers Linux VPS plans with NVMe storage, full root access and a 14-day free trial.
On a new Rocky Linux or AlmaLinux VPS, the safest first hour is deliberate rather than complicated: preserve console recovery access, update the system, confirm a privileged non-root account, prove key-based SSH in a second session, configure firewalld without removing SSH, keep SELinux enforcing, and verify a usable snapshot or backup. Do not disable your only login path while changing sshd or firewall settings.
What to do first on a Rocky Linux or AlmaLinux VPS
Use this order for a newly provisioned server:
- Record the VPS address and keep the provider’s web console or rescue channel open.
- Apply package updates with DNF.
- Confirm or create a normal administrative user with
sudoor wheel privileges. - Install and test an SSH public key from a second session.
- Validate the SSH daemon configuration, then disable password authentication and root SSH access if appropriate.
- Inspect firewalld’s active zone, permit only required services, make changes permanent, reload, and verify.
- Check that SELinux is enforcing and investigate policy denials rather than turning it off.
- Confirm a tested snapshot or backup before doing production work.
Rocky Linux and AlmaLinux share the RHEL-family administration model used here: DNF manages packages, firewalld manages the host firewall, and SELinux supplies mandatory access controls. The exact image, account state, enabled repositories, service names, and available console features still depend on the VPS provider and major release.
Free tools Windows power users keep installed
One-click scans. No signup required.
Prepare a recovery path before changing anything
Record the network and image details
Write down the public IPv4 or IPv6 address, hostname, operating-system release, provisioned username, and the provider image name. Rocky Linux installation guidance emphasizes that the IP address is especially important when you do not have easy physical or console access. Save these details in your password manager or infrastructure notes rather than relying on a browser session.
Keep the provider’s out-of-band console, serial console, rescue environment, or equivalent recovery mechanism available throughout the initial setup. It is the fallback if a firewall rule, SSH syntax error, or account permission change cuts off normal access.
Take a snapshot at the right time
If the provider offers a VPS snapshot, create one after the operating system is reachable and before major hardening. A snapshot is a rollback point, not a substitute for an independent backup: it may be stored in the same account or region as the VPS and may not protect against account loss. Confirm where snapshots are stored, how long they are retained, whether they are crash-consistent, and how restoration works.
Before production work, verify that your backup plan includes the data and configuration you actually need. A backup that has never been restored is an assumption, not a tested recovery plan.
Do these 3 things before closing this tab:
1Scan for outdated or missing drivers - takes under a minute2Clear out junk files and repair common Windows errors3Fix the driver behind crashes, sound loss and screen glitchesUpdate packages with DNF
Choose a full update or security-only update
Run the update from the provider console or from your initial SSH session:
sudo dnf updatednf upgrade is also documented for AlmaLinux and is commonly used for the same broad package-update operation:
sudo dnf upgradeIf you deliberately need only advisories classified as security updates, AlmaLinux documentation gives:
sudo dnf --security updateA security-only transaction can leave non-security bug fixes and dependency changes unapplied. For a new server, a complete update is usually the clearer baseline unless your change policy requires a narrower transaction.
Quick wins for a faster PC:
Fix the driver behind crashes, sound loss and screen glitchesFind Drivers →Clear out junk files and repair common Windows errorsFree Scan →Scan for outdated or missing drivers - takes under a minuteDriver Scan →Review the transaction before accepting it
Read the package list, repository names, replacement packages, and proposed reboot notice. Do not assume a clean-looking command means every repository is correctly configured. If you changed repositories or enabled a new one, update again afterward as AlmaLinux guidance recommends.
Major releases and provider images can change package names and available modules. Check the documentation for the release actually installed before copying a command intended for another image. If the transaction installs a new kernel or core libraries, plan a controlled reboot and retain the console session until you have confirmed the server returns.
Confirm a privileged, non-root administration account
Understand the Rocky Linux 10 default
Rocky Linux 10 installation documentation states that the root account is disabled by default, so the user created during installation must have administrative privileges. That documented installer behavior does not guarantee the same state for every cloud image. A provider may pre-create a different user, enable a temporary root login, or apply its own provisioning scripts.
Check who you are and which groups grant administration:
whoami
groups
idUse the provider’s documented username if one already exists. Confirm that it can run a harmless command through sudo:
sudo -v
sudo idThe second command should show an effective user ID of 0 while your interactive account remains non-root.
Create an account when the image did not provide one
From the console or an existing administrative session, create a named user and grant wheel membership:
sudo useradd --create-home --shell /bin/bash adminuser
sudo passwd adminuser
sudo usermod --append --groups wheel adminuserReplace adminuser with your own account name. Verify the group assignment with id adminuser, then open a separate login and run sudo -v before changing SSH policy. If your organization’s policy uses a dedicated sudoers file instead of the wheel group, follow that policy and validate the file with the platform’s sudoers tooling.
Do not remove your last working administrator
Keep the original provider account until the replacement account has successfully logged in, used sudo, and been tested through the recovery console. Only then should you consider locking or removing an unused account. Record the account change so another administrator knows which identity is intended for emergency access.
Set up SSH keys before tightening SSH access
Install a public key
Generate a key on your workstation if you do not already have one, then copy only the public half to the server. The exact local command depends on your operating system and key-management policy; never copy a private key to the VPS. You can use your provider’s key-import feature or place the public key in the target user’s ~/.ssh/authorized_keys with ownership and permissions appropriate to that user.
After installation, open a second terminal and prove that the key works while the first session remains connected. This is the critical safety test: the original session is your immediate fallback, and the second session demonstrates that the new authentication path is independent.
ssh adminuser@SERVER_IPUse the server’s actual address and account name. Test a fresh connection rather than assuming that an agent-cached session proves the key was installed correctly.
The Tool Desk
Outbyte Driver Updater FREEFix the driver behind crashes, sound loss and screen glitchesFind Drivers →Outbyte PC Repair FREERepair Windows errors before they cause bigger problemsFix Now →Validate the daemon configuration before reloading it
Inspect the effective SSH configuration and validate syntax:
sudo sshd -tNo output normally indicates that the syntax check passed. If it reports an error, correct the file and run the test again; do not reload a configuration that has not passed validation.
Apply restrictive settings only after the second session works
Once key authentication has been proven, review the SSH daemon settings. Common hardening choices are:
PasswordAuthentication noto prevent password-based SSH logins after every required user has a working key.PermitRootLogin noto prevent direct root SSH login, while administration continues through the named account andsudo.
Whether to use these exact values depends on your recovery process, automation, and provider image. A service account, break-glass procedure, or out-of-band console may require a different policy. Make the change in the configuration location used by your release, validate it again, and reload rather than abruptly stopping the daemon:
What’s actually slowing this PC down?
Pick the symptom - the matching free tool is one click away.
sudo sshd -t
sudo systemctl reload sshdKeep both sessions open and start a third fresh connection to verify the resulting policy. Only close the original session after the new policy has been tested.
Recover from a failed SSH change
If all normal sessions fail, use the provider console or rescue environment, revert the last SSH change, run sshd -t, and reload the service. If the account itself is the problem, restore its home-directory ownership, .ssh permissions, and authorized_keys contents from the console. Do not repeatedly guess at firewall rules while an authentication or syntax error remains unresolved.
Configure firewalld without locking yourself out
Inspect the active zone first
Firewalld is the default firewall application in Rocky Linux guidance. Before adding or removing anything, see which zones are active and what each one currently permits:
sudo firewall-cmd --get-active-zones
sudo firewall-cmd --get-default-zone
sudo firewall-cmd --list-allIf more than one zone is active, query the specific interface or zone shown by the first command. A rule added to an inactive zone will not protect the interface you think it does.
Allow SSH before making other changes
Rocky Linux documentation gives an explicit warning: “Never remove the SSH service from a remote server’s firewall!” Treat that as a sequencing rule. Ensure the SSH service is allowed in the active zone before you reload or remove any broad rule:
sudo firewall-cmd --zone=public --add-service=ssh --permanent
sudo firewall-cmd --reload
sudo firewall-cmd --zone=public --list-servicesReplace public with the active zone reported on your server. The --permanent option writes the intended configuration; --reload applies permanent settings to the running firewall. When you are experimenting, a runtime-only rule can be useful, but it disappears on reload and should not be mistaken for a durable policy.
Add only services the workload needs
For a web workload, that may mean HTTP and HTTPS; for a database, the preferred design is often to keep its port private and permit access only from an application network. Do not open a port merely because a package is installed. Use firewalld’s service definitions where available, or a precisely scoped port rule when the application requires a custom port.
sudo firewall-cmd --zone=public --add-service=http --permanent
sudo firewall-cmd --zone=public --add-service=https --permanent
sudo firewall-cmd --reload
sudo firewall-cmd --zone=public --list-allThese example rules are appropriate only when the server is actually intended to serve HTTP or HTTPS. Remove services that are not required, but never remove SSH from a remote server until you have a different, tested management path.
Verify from outside the VPS
Check the final zone and test the intended services from a separate network or monitoring host. A local listing proves that firewalld accepted the rule; it does not prove that the provider’s network firewall, security group, IPv6 path, or application is reachable. Keep the provider console available until both the rule set and remote connectivity are confirmed.
Keep SELinux enforcing
Check the current mode
The baseline recommendation is to leave SELinux enforcing and solve application policy problems directly. Check the mode and status:
getenforce
sestatusEnforcing means SELinux is actively applying policy. Permissive logs violations without blocking them, while Disabled removes the policy engine and changes the security baseline.
PC Slower Than It Used to Be?
A free scan shows the junk files, broken settings and background clutter dragging Windows down - then fixes them in one click.Free scan · Windows 10 & 11Outdated Drivers Are Slowing You Down
One free scan finds every outdated or missing driver and matches the right update for your exact hardware.Free scan · exact hardware matchDiagnose policy denials instead of disabling protection
If an application stops working after deployment, first identify the denied operation, file label, service account, and intended access. Correct ownership and labels where appropriate, restore expected labels after moving web or service content, and use the application’s documented SELinux integration. Treat a denial as evidence that a policy decision is needed, not as a reason to set SELinux to disabled.
Changing SELinux mode can also hide a real deployment mistake and make later troubleshooting harder. If a temporary permissive test is required by a controlled change procedure, document it, limit its duration, and return to enforcing after collecting the evidence needed to create a correct policy.
Rocky Linux versus AlmaLinux for VPS initialization
The first-hour workflow is substantially the same, but the provisioning experience is not identical. The following comparison separates facts established by shared administration guidance from differences that must be checked in the selected VPS control panel.
| Decision area | Rocky Linux | AlmaLinux | What to verify before deployment |
|---|---|---|---|
| Package administration | Uses DNF in the cited setup guidance. | Uses DNF; AlmaLinux documents dnf update, dnf upgrade, and dnf --security update. |
Installed major release, enabled repositories, kernel update policy, and reboot requirements. |
| Firewall administration | Rocky guidance treats firewalld as the default firewall application. | The same RHEL-family firewalld workflow applies in the cited checklist. | Active zone, provider-level firewall, IPv4/IPv6 behavior, and console recovery. |
| SELinux | Keep enforcing and address policy requirements. | Keep enforcing and address policy requirements. | Application labels, service accounts, and any vendor-supported policy modules. |
| Account defaults | Rocky Linux 10 installer documentation says root is disabled by default and the created user must be an administrator. | Cloud-image provisioning can supply a different initial user and privilege model. | Actual username, root state, wheel membership, sudo configuration, and key injection. |
| Provider image availability | Varies by provider, region, and release. | Varies by provider, region, and release. | Image version, architecture, support lifetime, cloud-init behavior, and upgrade path. |
| Snapshots and backups | Depends on the VPS provider’s console and storage tooling. | Depends on the VPS provider’s console and storage tooling. | Snapshot location, retention, restore process, and independent backup destination. |
| Documentation and support | Use current Rocky documentation for the installed release and provider notes for image-specific behavior. | Use current AlmaLinux documentation for the installed release and provider notes for image-specific behavior. | Whether a support answer applies to the exact major release and image, not merely the distribution name. |
A checklist published by KDE Red Hat was tested on AlmaLinux 10.2 with DNF 4.20.0 and OpenSSH 9.9p1 on July 17, 2026. Those versions describe that test context; they are not a promise that every VPS currently runs those versions.
Use a verification pass before deploying workloads
Identity and access checks
- Can the named administrator log in with a key from a new terminal?
- Does
sudo -vsucceed without relying on a root SSH session? - Has
sudo sshd -tpassed after the final SSH edits? - Have you tested the actual password and root-login policy from a fresh connection?
Network and firewall checks
- Does
firewall-cmd --get-active-zonesshow the interface and zone you intended? - Does
firewall-cmd --zone=ZONE --list-allshow SSH and only the workload’s required services? - Did you reload permanent changes and then verify them?
- Can you still reach the server through the provider console if the external test fails?
Platform and recovery checks
- Did DNF complete without unresolved dependency or repository errors?
- Is SELinux still enforcing?
- Do you know whether the update requires a reboot?
- Can you identify the latest snapshot and explain how to restore it?
- Has at least one backup or snapshot restoration path been tested before production data arrives?
Common failure modes and safe fixes
“I lost SSH access immediately after a firewall reload”
Do not keep changing rules from a disconnected client. Open the provider console, inspect the active zone, restore the SSH service in that zone, reload firewalld, and test a new connection. Then determine whether the outage was caused by the wrong zone, an interface assignment, a provider firewall, or an SSH daemon problem.
“The key is installed but authentication is denied”
Use the console to verify that the public key is in the intended user’s authorized_keys, that the home directory and SSH files belong to that user, and that permissions are not excessively open. Confirm that you are connecting as the same username whose key you installed. Check the daemon configuration only after the account and file path are correct.
“The SSH configuration test fails”
Leave the existing session open, read the line number in the sshd -t error, correct the syntax or unsupported directive, and run the test again. Do not restart or reload until it returns successfully. If the daemon was already stopped, use the console to restore a known-good configuration.
“An application works only when SELinux is disabled”
Return to enforcing mode through a controlled console session and investigate the denial, labels, service account, and file locations. Moving content without restoring its expected SELinux context is a common cause of an otherwise confusing failure. Build the smallest policy or labeling correction that permits the intended operation.
Recommended Free Tools
“The update changed the server unexpectedly”
Review the transaction output, enabled repositories, and release documentation. If a kernel or core component changed, schedule the required reboot and use the console during the restart. A pre-update snapshot gives you a rollback option, but validate the restoration procedure rather than assuming it will be instantaneous.
What not to do during initial setup
- Do not close your only SSH session while editing
sshd_configor firewalld. - Do not disable root login or passwords before a key-based administrator session has been tested.
- Do not remove SSH from a remote firewall zone as part of “cleaning up” default services.
- Do not disable SELinux to make an application start without identifying the denied operation.
- Do not treat a provider snapshot as a complete, independently tested backup.
- Do not assume Rocky Linux 10 installer defaults apply to a Rocky cloud image, or that an AlmaLinux image provisions accounts the same way.
- Do not copy commands between major releases without checking current release and provider documentation.
A practical first-hour sequence
For a repeatable deployment, keep two terminal windows open: one connected to the current session and one reserved for a fresh-login test. Keep the provider console tab available. Work through the sequence below without advancing when a verification step fails:
- Record the address, image, release, initial username, and recovery method; take or schedule a snapshot.
- Run a full DNF update, or the documented security-only transaction when that is an explicit requirement.
- Confirm a named wheel or sudo administrator and test
sudo. - Install the administrator’s public key and log in from a second session.
- Run
sudo sshd -t; only after success, apply the selected root and password-login policy and reloadsshd. - Inspect firewalld’s active zone, ensure SSH is allowed, add only required workload services as permanent rules, reload, and verify externally.
- Check
getenforce; investigate policy issues while keeping SELinux enforcing. - Confirm backup or snapshot recovery details, then document the final access, firewall, and release state for the next administrator.
This sequence leaves you with a reachable, updated, least-privilege administration path and a known recovery route before you expose an application or store important data.
Quick Recap
Product prices and availability are accurate as of the date/time indicated and are subject to change. Any price and availability information displayed on Amazon at the time of purchase will apply.
Free tools Windows power users keep installed
One-click scans. No signup required.
