[DEV]

Protect aaPanel Free Edition management access with HTTPS, a carefully tested panel-port change and SSH keys. This guide records our Ubuntu 22.04 lab results from 10 October 2026. It follows panel installation and web stack setup.

1. Keep a recovery route and back up configuration
Before changing access settings, keep your provider's recovery console available and an existing SSH session open. Save configuration backups off the server. Our lab has no snapshots, so we saved an off-server copy of the SSH, firewall, Nginx and panel configuration.

A configuration archive is not a complete website/database backup. aaPanel's Auto Backup Panel setting also states that it excludes website and MySQL data. A separate backup-and-restore exercise is required for those.

2. Check panel HTTPS
Open Settings → Panel SSL. The numbered screenshot shows HTTPS enabled, a trusted certificate and its expiry information:



Our panel already had a certificate that validated without bypassing browser warnings. Check your own hostname/IP, certificate status and expiry. The lab's IP certificate has a short lifetime; renewal still needs verification. Panel HTTPS and your website's HTTPS certificate are separate settings.

If your browser reports a certificate error, investigate it before sending login credentials. Enabling a switch alone is not proof that the certificate is valid for the address you use.

3. Change the panel port without locking yourself out
Changing the port can reduce routine scanning noise, but it does not replace strong authentication or access restrictions. We used 18443 as an example; choose an unused port appropriate for your setup.

1. Note the current panel port and keep the current SSH session open.
   
2. Allow the new TCP port in the server firewall and any provider security group first. Restrict management access to trusted sources when practical.
   
3. In Settings → Panel port → Modify, enter the new port.
   
4. Read the dialog, acknowledge that the new port is allowed, then confirm. The panel restarts.
   
5. Open the new HTTPS URL with the same private entrance path. Sign in through a fresh connection.
   
6. Only after the new connection works, remove the old management-port firewall rule.
   

Our new panel login succeeded before we removed the old firewall opening. Preserve the private entrance path and credentials in secure notes, not public screenshots. If access fails, use the still-open SSH session or provider console to restore the previous port/firewall configuration.

4. Test SSH key access
Generate a dedicated key on your own computer. An interactive key can use a passphrase:

Code:Copy

ssh-keygen -t ed25519 -f ~/.ssh/aapanel_lab

Copy the public key to the correct server account. On a workstation with ssh-copy-id:

Code:Copy

ssh-copy-id -i ~/.ssh/aapanel_lab.pub YOUR_USER@YOUR_SERVER_IP

Windows OpenSSH users can add the public key through their existing authenticated session. Keep the private key on your computer; only the .pub key belongs in the server's authorized_keys file. Verify the server host fingerprint through a trusted route.

Open a fresh connection with the key:

Code:Copy

ssh -i ~/.ssh/aapanel_lab YOUR_USER@YOUR_SERVER_IP

We tested fresh Ed25519 sessions before and after reboot. We retained password access during the disposable lab exercises. For production, plan a separate tested move to a sudo account and key-only authentication; do not disable a working recovery route before verifying its replacement.

5. Review the remaining protections
Our aaPanel Free 8.0.6 interface includes Google Authenticator and Authorized IP controls. We have not enabled them in this lab: authenticator enrollment needs the owner's device, and an allowlist needs a stable management address or VPN. Configure and test these for your environment without blocking legitimate access or certificate renewal.

Review optional phpMyAdmin and FTP exposure. MariaDB does not need a public database-port opening for a website running on the same server. Use encrypted file transfer and allow only the services you actually need.

Verified results and remaining checks
Our Ubuntu updates and reboot completed. Fresh SSH key access, panel login, Nginx, MariaDB and PHP-FPM recovered successfully. The local default website returned HTTP 200. The panel-port change and current certificate validation passed.

We also disabled phpMyAdmin’s separate public-access service and verified that the setting remained off. Its authenticated panel launch still needs troubleshooting; see the phpMyAdmin installation guide.

Certificate renewal, two-factor enrollment, a stable management allowlist and full website/database restore testing remain separate checks. This guide does not claim that every production-hardening task is complete.

Next: Add a website, connect its domain, issue its own HTTPS certificate and create its database.

References: aaPanel Settings documentation and Ubuntu OpenSSH documentation.