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.
CentOS Linux 8 is not a supported operating system for a new VPS. The CentOS Project set its end of life (EOL) for December 31, 2021. Its repositories were archived rather than turned into a normal security-update stream, and the project said users would not be migrated automatically. CentOS Stream 8 builds also ended on May 31, 2024. If you have inherited or cannot immediately rebuild a CentOS 8 VPS, use the procedure below to establish controlled access, patch what remains available, restrict exposure, and prepare a migration to a currently supported distribution.
The sequence matters: verify console recovery before changing SSH, update before installing applications, create and test a named sudo account, enable firewalld, keep SELinux enforcing, and only then disable direct root or password-based SSH. Treat the VPS as a temporary migration project, not as a durable new deployment.
Free tools Windows power users keep installed
One-click scans. No signup required.
Decide whether this VPS should exist before you secure it
First identify exactly what the provider installed. “CentOS 8” can mean CentOS Linux 8 or CentOS Stream 8, and neither should be assumed current in 2026. CentOS Linux 8 ended on December 31, 2021, according to the CentOS Project’s 2021 EOL notice. The project stated that it would not automatically migrate users to the next version and that CentOS Linux 8 content would be archived. CentOS Stream 8 builds ended on May 31, 2024. Archived package trees are not equivalent to a supported security-update service.
Do not provision a fresh production service on this image merely because the provider still offers it. Ask the provider which supported images are available and check the destination distribution’s current lifecycle, repository availability, console access, snapshot support, and migration tooling. If an application must remain on the existing userland for a short period, document an end date for rebuilding or migrating it before you expose the workload to the Internet.
When these steps are appropriate
- An inherited VPS cannot yet be rebuilt because an application, data format, or vendor dependency needs a transition window.
- You need to collect configuration and data before moving to a supported operating system.
- You are working in a recovery window and have an out-of-band provider console and a restorable snapshot.
When to stop and rebuild instead
- The provider cannot offer console or rescue access and you have no tested recovery path.
- The VPS handles sensitive data but cannot receive a supported security update stream.
- The workload can be redeployed from code and backups without a compatibility blocker.
- You cannot identify who owns the existing SSH keys, sudo access, repositories, or application credentials.
Prepare provider access and a recovery path
Before the first SSH command, make sure you can reach the machine through both the normal network path and the provider’s management interface. A locked-out SSH daemon is recoverable only if the console, rescue environment, or a verified snapshot is usable.
- Confirm reachability. Record the public and private IP addresses, the provider region, the assigned hostname, and the console or rescue URL in your operations record.
- Confirm credentials. Obtain the initial password or verify that the provider injected the intended public key. Do not assume a key was installed simply because the order form included one.
- Take a snapshot. Use a provider snapshot if one is available, and record its identifier and creation time. A snapshot is a rollback point, not a substitute for an application-consistent backup.
- Verify the host key. Use the provider console or a trusted provisioning record to confirm the SSH host-key fingerprint. On the first connection, stop if the fingerprint differs from the value you expect.
- Keep a second session ready. Do not close the original root session while changing accounts, SSH settings, SELinux labels, firewall rules, or ports.
Record the starting state
Capture the image release, kernel, hostname, timezone, interfaces, and address assignments before making changes. These records let you distinguish an operating-system problem from a provider-network problem during a later migration.
Recommended Free Tools
cat /etc/centos-release
uname -r
hostnamectl
timedatectl
ip address
ip routeRemove the accidental leading space before timedatectl if you paste the block into a shell. The command is shown separately here to make the intended inventory clear.
Make the first SSH connection safely
Use the provider-supplied address and the account you were given. A first connection may display a host-key confirmation. Compare the fingerprint with the trusted provider record rather than accepting it blindly.
ssh root@203.0.113.10Replace the example address with the VPS address. If the provider supplied a non-root initial account, use that account and elevate only when required. A changed fingerprint can indicate a legitimate rebuild, but it can also indicate that you are connecting to the wrong address or an intercepted connection; verify it through the provider console before proceeding.
Check identity and privileges
whoami
id
sudo -lOn a root login, whoami should report root. On a provider-created administrator, confirm that the account has the intended sudo rights before you alter root access. Do not distribute the initial password to a team when individual SSH keys and named accounts can provide accountability.
Update the legacy system before installing applications
On a CentOS/RHEL 8 family installation, the documented post-install command is:
yum updateRun it before adding application packages. Because CentOS Linux 8 repositories were archived after EOL, the command may report unavailable mirrors, expired metadata, or no current security stream. Do not “fix” this by pointing blindly at an unrelated repository or by disabling signature checks. Record the error, determine whether the provider supplies an approved archive, and prioritize migration to a supported image.
When the update replaces the kernel or critical system libraries, reboot during an approved maintenance window:
rebootReconnect after the provider reports that the VPS is online and verify that the expected kernel and release are running:
What’s actually slowing this PC down?
Pick the symptom - the matching free tool is one click away.
uname -r
cat /etc/centos-releaseHow to interpret update results
- Packages update normally: continue hardening, but do not interpret a successful transaction as proof that the operating system is supported. CentOS Linux 8 remains EOL.
- Repositories fail: preserve the output for the migration record. Avoid random mirror lists and unsigned packages.
- A reboot does not return: use the provider console, snapshot, and rescue procedure. Do not repeatedly reboot without checking the console output.
Create a named administrator and test it
Keep one emergency recovery path, but perform routine administration through a named account. The account should use an SSH key and receive only the sudo rights necessary for its role.
- Create the account:
useradd --create-home --shell /bin/bash adminname
passwd adminnameUse a unique name for each administrator. If you temporarily set a password to bootstrap access, replace it with key-based access and remove the temporary secret from any notes or chat transcripts.
- Grant administrative rights through the CentOS 8 administrator group:
usermod --append --groups wheel adminnameVerify the account’s sudo policy while you still have the original session open:
su - adminname
sudo -l- Install the administrator’s public key. From the administrator account, create the SSH directory with restrictive permissions:
mkdir --parents ~/.ssh
chmod 700 ~/.ssh
printf '%s
' 'ssh-ed25519 AAAA... admin-key' >> ~/.ssh/authorized_keys
chmod 600 ~/.ssh/authorized_keysReplace the example key with the complete public key. Check ownership if you performed these commands as root:
Quick wins for a faster PC:
Scan for outdated or missing drivers - takes under a minuteDriver Scan →Repair Windows errors before they cause bigger problemsFix Now →chown --recursive adminname:adminname /home/adminname/.ssh- Open a new terminal and test key login before changing root or password settings:
ssh -i ~/.ssh/admin_key adminname@203.0.113.10
sudo idThe second command should show effective user ID 0 after sudo authentication. Keep the original session open until this test succeeds and you have confirmed that the provider console works.
Limit sudo deliberately
Do not copy a broad administrator policy to every user. Keep a written list of people who can use sudo, the key fingerprint assigned to each person, and the date each key was last reviewed. Remove departed users and rotate keys whose ownership is uncertain.
Enable firewalld and expose only required services
CentOS 8 uses firewalld as the host firewall. Start it, enable it at boot, and confirm its state:
systemctl start firewalld
systemctl enable firewalld
firewall-cmd --stateThe expected state is running. A provider-level network firewall and the guest firewall must agree: allowing TCP 22 at the provider while blocking it inside firewalld still prevents access, and allowing a port at both layers exposes it to the Internet.
Build the rule set from the workload
List the services the application genuinely needs. SSH is required for administration; a web service may need HTTP and HTTPS; a database normally should remain reachable only from an application network or approved management source. Do not open a port simply because a package installed a daemon.
firewall-cmd --get-active-zones
firewall-cmd --list-allFor a service that has a firewalld service definition, add it permanently and reload:
firewall-cmd --permanent --add-service=ssh
firewall-cmd --permanent --add-service=http
firewall-cmd --permanent --add-service=https
firewall-cmd --reloadOnly add the entries that the workload uses. If the application needs a specific TCP port rather than a predefined service, use an explicit port rule and document the reason:
firewall-cmd --permanent --add-port=8443/tcp
firewall-cmd --reloadCheck the effective configuration after every change:
firewall-cmd --list-all
firewall-cmd --list-ports
firewall-cmd --list-servicesRuntime versus permanent rules
A runtime rule affects the current firewall process; a permanent rule is stored for a restart. The safest workflow is to make the intended change permanent, reload, and verify. For the documented nonstandard SSH-port pattern, add the port at runtime first, test it, and then save the working state with firewall-cmd --runtime-to-permanent. Do not remove the old SSH rule until the replacement connection works from a second terminal.
Keep SELinux enforcing
Check the mode immediately:
getenforceThe desired result is Enforcing. CentOS infrastructure guidance calls for SELinux to remain enforcing rather than permissive or disabled. Disabling it to make an application start removes a major control and hides the policy or labeling problem that needs to be fixed.
Investigate denials instead of switching modes
- Confirm that files have the expected SELinux labels before changing application configuration.
- Review the denial details and determine whether the access is legitimate or indicates a misconfiguration.
- Correct the service’s path, labels, or narrowly scoped policy rather than applying a broad allow rule.
- Retest the application in enforcing mode.
If a service was moved from its packaged location, treat labeling as part of the move. Record the final path and the policy adjustment in the migration notes so a rebuild does not repeat the same failure.
Harden SSH only after the replacement path works
Do not begin by disabling root or password login. First prove that the named account can log in with its key and can use the provider console as a recovery path. Then edit /etc/ssh/sshd_config and set:
PermitRootLogin no
PasswordAuthentication noPermitRootLogin no blocks direct root SSH. PasswordAuthentication no requires key-based authentication for SSH users; it does not remove local console access or sudo authentication. Confirm that every administrator has a working key before applying the change.
Validate and reload without losing the session
- Check the configuration syntax:
sshd -t- If the command returns no error, reload the daemon:
systemctl reload sshd- From a second terminal, open a new connection as the named administrator:
ssh -i ~/.ssh/admin_key adminname@203.0.113.10- Run a sudo command and verify that the session is stable. Only then close the original root session.
If sshd -t reports an error, do not reload. Correct the file and validate again. If the new login fails after a reload, use the still-open session or provider console to restore the last known-good setting. CentOS infrastructure SSH guidance describes a secure default as disallowing root login and password authentication; apply that posture only after your own recovery path has been tested.
Changing the SSH port is optional, not a security strategy
A nonstandard port can reduce automated noise, but it does not replace key authentication, root-login restrictions, patching, SELinux, or firewall rules. If policy requires a different port, change all three relevant layers: the SSH daemon, SELinux’s SSH port label, and firewalld.
Do these 3 things before closing this tab:
1Repair Windows errors before they cause bigger problems2Scan for outdated or missing drivers - takes under a minute3Clear out junk files and repair common Windows errorsRed Hat documents this pattern, using a placeholder for the chosen port:
semanage port -a -t ssh_port_t -p tcp <port-number>
firewall-cmd --add-port=<port-number>/tcp
firewall-cmd --runtime-to-permanentConfigure the daemon to listen on the same port, validate with sshd -t, reload it, and test from a second terminal. Keep the original port enabled until the new path works and the provider console is available. If the port is already defined in SELinux, use the appropriate modification workflow rather than adding a duplicate entry; inspect the current definitions before changing them.
Minimize services, packages, and listening sockets
Once access is stable, identify what is listening and what starts automatically:
ss -tulpn
systemctl list-unit-files --state=enabled
systemctl --type=service --state=runningMap each listening socket to an intended workload. Remove packages that are not needed, and disable unused services. Red Hat’s guidance gives disabling an unnecessary printing service as an example:
Crashes, No Sound, or Screen Glitches?
Random freezes, missing sound and display glitches usually trace back to one bad driver. Find and replace yours safely.Free scan · under a minutePC 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 & 11systemctl disable cupsDo not disable a service solely because its name is unfamiliar. Check package dependencies, application documentation, and the provider’s management agents first. If a service is not required, stop it as well as disabling it, then verify that the port is no longer listening:
systemctl stop cups
ss -tulpnApply the same review to scheduled jobs, old deployment agents, temporary test daemons, and database listeners bound to public interfaces. A firewall rule is a boundary control; removing an unnecessary daemon reduces the number of components that can be exploited or misconfigured.
Document the system before deploying the application
Create a short, maintained record that another administrator can use during an outage or migration. Include:
- Provider, region, VPS identifier, public and private addresses, hostname, image release, kernel, and timezone.
- Provider-console and rescue instructions, snapshot identifiers, backup locations, and the last restore test.
- Named users, SSH key fingerprints, sudo access, and the owner of each key.
- Current SSH port, firewalld zone, allowed services and ports, and the provider-level firewall rules.
- SELinux mode, application paths, any approved labels or policy changes, and the reason for each exception.
- Enabled services, package repositories, update errors, and the date of the last successful update.
- Application dependencies, data locations, secrets-management references, and the planned rebuild or migration date.
Never put private keys or plaintext application passwords in this record. Store sensitive credentials in the approved secret system and reference their locations instead.
The Tool Desk
Outbyte PC Repair FREEClear out junk files and repair common Windows errorsFree Scan →Outbyte Driver Updater FREEFix the driver behind crashes, sound loss and screen glitchesFind Drivers →Use a validation checklist before production traffic
Run these checks from an independent terminal and from the provider console where applicable:
- The VPS is reachable over the expected network path and through the out-of-band console.
- The recorded host-key fingerprint matches the trusted provisioning record.
- The named administrator logs in with an SSH key and can run the required sudo commands.
- Direct root SSH is disabled when it is not required.
- Password-based SSH is disabled after all required keys were tested.
sshd -tpasses and the daemon reload completed without dropping the tested session.- Firewalld is running, enabled at boot, and contains only workload-required services and ports.
- Provider and guest firewall rules are consistent.
getenforcereportsEnforcing.- Listening sockets correspond to documented services; unused daemons are stopped and disabled.
- The latest snapshot or backup can be located, and the restore procedure has been exercised or scheduled.
- The migration target, owner, and deadline are recorded because the operating system is EOL.
Troubleshoot common lockouts and failures
The new administrator cannot log in
Use the original session or console to check the account’s home-directory ownership, ~/.ssh permissions, and authorized_keys content. Confirm that the client is using the intended private key and that the provider firewall and firewalld both allow the SSH port. Do not disable SELinux as a first response; inspect labels and denial details.
SSH stops accepting connections after a configuration change
Use the still-open session or provider console. Run sshd -t, restore the last known-good configuration if necessary, and reload only after validation. If you changed the port, check the daemon listener, the SELinux ssh_port_t assignment, and the firewalld rule as one change set.
The VPS is unreachable after enabling firewalld
Open the provider console, inspect firewall-cmd --list-all, and confirm that the active zone is attached to the expected interface. Restore the required SSH service or port, reload, and test from a second terminal. Review the provider-level firewall at the same time; either layer can block the connection.
Free tools Windows power users keep installed
One-click scans. No signup required.
Updates fail on archived repositories
Save the error output and stop installing application packages from random mirrors. Because CentOS Linux 8 is EOL, repository failure is an expected migration signal, not a reason to weaken signature verification. Determine whether the provider offers a supported replacement image or an approved temporary archive, then move the workload to a supported distribution.
An application fails with SELinux enforcing
Identify the denied operation, verify the path and labels, and make the smallest legitimate correction. Keep enforcing mode during the test. A successful start in permissive mode proves only that policy enforcement was bypassed; it does not produce a safe configuration.
Plan the migration instead of normalizing the risk
The secure-state checklist above reduces immediate exposure but cannot change CentOS Linux 8’s lifecycle. Select a destination by checking the dimensions that affect your workload:
| Decision area | What to verify before choosing |
|---|---|
| Support lifecycle | Published maintenance and security-update dates for the exact edition and release. |
| Compatibility | Whether the existing RHEL 8-family userland, libraries, kernel modules, and application dependencies are supported. |
| Migration tooling | Availability of an in-place conversion path, rebuild procedure, image import, or application-level migration. |
| Repositories | Normal signed package repositories and a predictable security-update cadence. |
| Provider availability | Supported image, console access, snapshot capability, networking, and documented restore process. |
| Operational cost | Any subscription, licensing, support, or managed-operations cost that applies to the destination. |
Do not present CentOS Stream 8 as a current replacement merely because it is historically related to CentOS Linux 8; its builds ended on May 31, 2024. Verify the destination’s lifecycle on the date you plan the migration.
Recommended Free Tools
Choose a migration pattern
- Rebuild and restore: provision a supported image, recreate users and firewall policy, deploy the application from source or automation, restore data, and switch traffic. This gives the cleanest result when the workload is reproducible.
- Parallel migration: run the new VPS beside the old one, replicate or export data, test the application, then change DNS or the upstream endpoint. Keep the old snapshot until the cutover is verified.
- In-place conversion: use only a documented, provider- and application-compatible procedure with a tested rollback. An in-place conversion is not the same as receiving ordinary CentOS Linux 8 updates.
Before cutover, reproduce the named sudo account, SSH keys, firewalld rules, SELinux expectations, monitoring, backups, and console recovery on the destination. Record the final data synchronization time and a rollback decision point.
A practical first-day sequence
- Confirm provider reachability, credentials, host-key fingerprint, console access, and a snapshot.
- Record release, kernel, hostname, timezone, addresses, and routes.
- Run
yum update; reboot if the kernel or critical libraries changed. - Create a named administrator, install its SSH key, and test a second session with sudo.
- Start and enable firewalld; allow only the required services.
- Check
getenforceand keep SELinux enforcing while correcting policy or labeling issues. - Validate and reload SSH after setting
PermitRootLogin noand, once key access is proven,PasswordAuthentication no. - If required, move SSH to a new port by updating sshd, SELinux, and firewalld together; test before removing the old path.
- Inventory sockets and enabled services; disable and remove unnecessary components.
- Write the recovery and migration record, then schedule the move to a supported operating system.
At the end of this sequence, the VPS should have controlled administrative access, a minimal network exposure, enforcing SELinux, and a documented recovery path. It is still an EOL CentOS Linux 8 system, so the final security action is to complete the migration rather than treating hardening as a permanent exemption.
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.
