What this guide helps you do
Safe examples for opening web ports and preserving SSH access on Ubuntu/Debian and AlmaLinux/Rocky Linux. A firewall should reduce exposed services, not become a remote lockout button. The safest workflow is to identify the active SSH port, keep an existing session open, allow that port first, then enable or reload the firewall and test a second login before closing your safety session. Provider network firewalls may also exist outside the operating system. This guide is written for production-minded administrators and site owners: make a backup before material changes, keep credentials private, and prefer the controls supplied by your own hosting provider when its environment differs from a generic example.
Before you begin
Record the domain, server or station you are changing and the current working state. If the task touches DNS, SSH, firewall rules, databases, stream credentials or application configuration, make sure you have a recovery path first. Screens and menu names can vary between cPanel, AzuraCast, VDO Panel and Linux releases, so follow the purpose of each step rather than forcing an old screenshot onto a newer version.
Step 1: List listening ports and understand which services need public access. Web servers usually need 80/443; databases generally should not be exposed to the entire internet without a specific architecture.
List listening ports and understand which services need public access. Web servers usually need 80/443; databases generally should not be exposed to the entire internet without a specific architecture.
Step 2: On Ubuntu or Debian with UFW, allow the exact SSH service or port before enabling UFW. Then allow HTTP/HTTPS as needed and inspect the numbered rules.
On Ubuntu or Debian with UFW, allow the exact SSH service or port before enabling UFW. Then allow HTTP/HTTPS as needed and inspect the numbered rules.
Step 3: On AlmaLinux or Rocky Linux with firewalld, add the SSH and web services to the active zone, make permanent changes deliberately, then reload and list the zone configuration.
On AlmaLinux or Rocky Linux with firewalld, add the SSH and web services to the active zone, make permanent changes deliberately, then reload and list the zone configuration.
Step 4: Test from another terminal and, where possible, another network. A local curl test does not prove the public firewall path is correct.
Test from another terminal and, where possible, another network. A local curl test does not prove the public firewall path is correct.
Step 5: If you lose access, use the hosting provider’s console/recovery facility rather than repeatedly rebooting or opening every port.
If you lose access, use the hosting provider’s console/recovery facility rather than repeatedly rebooting or opening every port.
Useful commands or examples
The following commands are examples for the context described in this guide. Read them before running them, substitute your real service names or hostnames, and keep a working administrative session open for network or SSH changes.
sudo ss -tulpn
# UFW example
sudo ufw allow OpenSSH
sudo ufw allow 'Nginx Full'
sudo ufw enable
sudo ufw status numbered
# firewalld example
sudo firewall-cmd --permanent --add-service=ssh
sudo firewall-cmd --permanent --add-service=http
sudo firewall-cmd --permanent --add-service=https
sudo firewall-cmd --reload
sudo firewall-cmd --list-allVerification checklist
Confirm SSH works in a new session, only intended public ports appear externally, the selected firewall tool is actually active, rules survive reboot, and provider-level security groups do not conflict with the operating-system firewall. Always test from the user side as well as the administrator side. A control panel saying “active” is useful evidence, but it is not the same as an external browser, player or SSH client proving that the full path works.
Troubleshooting method
When the result is not what you expected, avoid changing several unrelated settings at once. Identify the last known-good point, collect the exact error message and determine which layer is failing: DNS, network, authentication, service process, application configuration, web/stream delivery or browser/player. Check timestamps and logs around the failure. If you need to escalate to hosting support, include the affected hostname or station, the time of the test, what you expected, what happened instead and the checks you already completed. Do not include passwords, API keys or private stream keys in a public ticket or screenshot.
Keep the system maintainable
Document the final configuration after it works. Note the important URLs, service names, backup locations, renewal/expiry dependencies and any change that would surprise another administrator. Revisit the setup after major platform upgrades because defaults, supported runtimes and interface labels evolve. A reliable environment is not one that was configured once; it is one whose current state is understood, monitored and recoverable.
Where to go next
Use the related guides below to expand the setup rather than solving the same problem from scratch. If the platform has outgrown shared hosting or you need managed implementation, the service recommendation at the bottom of this guide links to the most relevant hosting, streaming, development or optimisation option on this site.
Interface labels and supported versions can change. Use the controls and documentation supplied with your current hosting environment, and keep a backup or recovery path before material changes.