Use this guide to open my-console, run commands, manage password-based root SSH access, and recover from connection problems. Part 2 records the platform security tests and explains the console's access controls.
Part 1: Console Access
Try my-console
Try the console controls below. Type help at the prompt to see the demo commands. The faint Paste button beneath the prompt brightens when hovered over.
The demo runs in your browser using sample output. It does not connect to a PBX or execute server commands. Paste works only when the browser permits clipboard access; pasted line breaks trigger simulated commands in the demo.
Console Buttons
clear and Enter to the terminal. Use it at a shell prompt. The red Cleared! message lasts 1.5 seconds and confirms that the command was sent.Console Features
- 1.3.0: added a discreet, cursor-following Paste button with clipboard access on click, hover highlighting and dedicated room beneath the terminal.
- 1.2.1: added the red Cleared! confirmation and improved the Disconnect button border and hover colour.
- 1.2.0: added the Clear All button beside Copy All.
- 1.1.0: added connection health checks, automatic reconnection, Copy All, longer scrollback, and input buffering.
Opening the Console
- Access
- Sign in to my.freepbx.uk, open your instance under My Products, and click Console.Your browser connects to my-console.freepbxhosting.uk. The console server connects to your PBX on SSH port 22. Your own IP address does not need direct SSH access.
- Root Access
- The console opens a root shell. Commands can change settings, delete data, or interrupt calls. Check them before running them.
- Launch Links
- Launch links are signed for your instance and remain valid for five minutes. Keep them private: anyone holding a valid link may be able to open the console. Links are not single-use.The five-minute limit applies to opening a connection. Expiry does not close an existing session.
- Firewall
- Provisioning adds my-console.freepbxhosting.uk to the internal zone of the FreePBX firewall. Keep that entry in place.my-console needs SSH running on the PBX and port 22 reachable from the console server.
- Sessions
- Use one console session per service. Opening another can disconnect the existing session.Disconnecting or closing the page closes SSH once the server detects it. Commands started independently of the shell may continue running.
- Idle Timeout
- After the first terminal input, the session closes if no further input is received for 30 minutes. Typing resets the timer; command output and connection health checks do not.
- Reconnection
- Automatic reconnection attempts to open a new shell using the original launch link. It does not resume the previous shell or command.If the link is more than five minutes old, open Console again from your product page.
Working in the Console
- Typing
- Click inside the terminal to type. Resizing the browser also resizes the remote terminal.
- Pasting
- Click the faint Paste button beneath the active shell prompt to read your clipboard and paste its contents. It brightens on hover and never reads the clipboard until clicked. You can still paste using your browser's usual keyboard or context-menu controls. Read commands before pasting them: line breaks can submit commands immediately, and large pastes are buffered in order and run with root privileges. If the browser blocks clipboard access, use the keyboard or context menu instead.
- Saving Output
- Use Copy All before closing or refreshing the page. Scrollback is held in the browser and is not a permanent session log.
Connection Messages
- Session expired. Reopen my-console.
- Open Console again from your product page. Refreshing an expired link does not renew it.
- Session replaced by another my-console session.
- Another connection has opened for the same service. This tab stops reconnecting. If you opened the other session, continue there.
- SSH session closed.
- The remote shell has ended and automatic reconnection has stopped. Use Reconnect if the launch link is still valid, or open Console again from your product page.
- Connection failed. Use Reconnect to try again.
- The five automatic reconnection attempts have finished. Try Reconnect or open Console again for a fresh link. If it still fails, give support the error message and the time it occurred. Do not send the launch link.
Password-Based Root SSH Access
Password-based root SSH access is disabled by default. SSH remains running for authorised keys, including the key used by my-console.
Run these commands as root on your PBX through my-console, not on the console proxy server. They apply to the standard FreePBX UK snapshot running FreePBX 17 on Debian 12. If your SSH files or settings differ, contact support before changing them.
Enable Password-Based Root SSH
sed -i 's/PermitRootLogin prohibit-password/PermitRootLogin yes/' /etc/ssh/sshd_config sed -i 's/PasswordAuthentication no/PasswordAuthentication yes/' /etc/ssh/sshd_config.d/50-cloud-init.conf passwd root systemctl restart sshd
- Changes
PermitRootLogintoyesin/etc/ssh/sshd_config. - Enables password authentication in
/etc/ssh/sshd_config.d/50-cloud-init.conf. - Sets the root password. Choose a strong password.
- Restarts SSH to apply the settings.
Disable Password-Based Root SSH
sed -i 's/PermitRootLogin yes/PermitRootLogin prohibit-password/' /etc/ssh/sshd_config sed -i 's/PasswordAuthentication yes/PasswordAuthentication no/' /etc/ssh/sshd_config.d/50-cloud-init.conf passwd -l root systemctl restart sshd
- Restores
PermitRootLogin prohibit-password, allowing root to authenticate with an authorised key. - Disables password authentication in the cloud-init SSH configuration file.
- Locks the root password. This does not disable the account; authorised SSH keys continue to work with this configuration.
- Restarts SSH to apply the settings.
The main SSH configuration includes the drop-in files before its own authentication settings. The value in 50-cloud-init.conf therefore takes precedence over the later PasswordAuthentication line in sshd_config. On this snapshot, sshd.service is an alias for ssh.service.
Fail2Ban Lockout
- Bans
- Fail2Ban is active on the snapshot and can ban an IP after repeated failed SSH logins. A ban on your own IP can block direct SSH. my-console connects from the console server's IP, so a ban on that address can block the browser console too.
- Recovery
- If direct SSH is blocked, try my-console. If both are unavailable, raise a support ticket at my.freepbx.uk. FreePBX UK can investigate through the infrastructure console, which customers cannot access.
- SSH Jails
- The SSH jails are
sshdandssh-iptables. An IP can be banned in both. If unbanning it from one does not restore access, check the other.
Restoring Console Access
If the console stopped working after firewall changes, check that my-console.freepbxhosting.uk is still in the FreePBX firewall's internal zone. Removing its access can prevent the console from connecting.
Restore the entry in the FreePBX firewall interface. If you have another root shell on the PBX, you can use this command instead. Run it on your PBX.
fwconsole firewall add internal my-console.freepbxhosting.uk
Your Responsibilities
- SSH
- If you enable password-based root SSH access, you are responsible for securing it. Clause 8 of the FreePBX UK Hosting Agreement describes your security responsibilities.
- Console Access
- Keep the authorised key-based access used by my-console. Removing, disabling, or bypassing the FreePBX UK console access mechanism constitutes a material breach of your hosting agreement.
- Support Access
- FreePBX UK retains infrastructure console access for maintenance and support, as described in your hosting agreement. This does not constitute monitoring of your PBX activity.
Part 2: Platform Security Assessment
On 15 April 2026, security tests were performed between two instances provisioned from the standard FreePBX UK snapshot. They assessed access over public IPv4, IPv6, the DigitalOcean private range, and the test VPC, with the FreePBX firewall enabled and disabled.
The findings below record the completed tests. Test 7 also explains the my-console architecture.
Network Isolation
- Method
- ICMP and TCP ping across public IP, DigitalOcean private range, VPC range, and IPv6.
- Result
- Public IP: Reachable via internet routing as expected.
DO Private Range: The tested connection returned Destination Host Unreachable on the DigitalOcean private range.
VPC Range: Reachable between instances in the same infrastructure VPC. Customer instances are not placed into shared VPCs with other customer instances.
IPv6: Fully reachable, 0% packet loss, correct addressing confirmed on both instances. - Finding
- The tested instances could not communicate over the private range, while instances in the same test VPC were reachable. Isolation depends on the provisioned topology and firewall rules; a private IP address alone does not establish isolation.
SSH Access
- Method
- SSH connection attempted across public IP, VPC IP, and IPv6 with password authentication explicitly disabled.
- Result
- All three attempts returned "Permission denied (publickey)". No access was granted on any interface or protocol stack.
- Finding
- The tested snapshot enforced key-only SSH authentication. The three connection attempts did not authenticate without an authorised key.
Web Interface Credential Testing
- Method
- Automated POST requests to the FreePBX admin interface using a dictionary of common default credentials including admin, password, freepbx, sangoma, 1234, root, toor, changeme, and others.
- Result
- All attempts returned an Invalid response and were redirected back to the login page. No credentials produced a successful login.
- Finding
- None of the credentials in the test dictionary produced a successful login. This test did not assess an unfinished initial administrator setup.
SIP Exposure
- Method
- SIP device scanning using SIPVicious svmap and svwar across public IP, VPC IP, and IPv6, with the FreePBX firewall both active and disabled. Extension enumeration attempted across the range 100 to 300.
- Result
- Firewall Disabled: SIP device identified as FPBX-17.0.28(22.8.2) on both public IP and VPC IP.
IPv6 (Firewall Off): Ports were reported open, but the test did not identify a SIP service over IPv6. This observation does not establish the binding settings on every instance.
Firewall Active: SIPVicious returned "found nothing" across all interfaces and protocol stacks. The tested SIP scans did not identify the instance from their source. - Finding
- With the firewall active, the tested scans did not discover SIP on the tested interfaces. The firewall-off tests did identify SIP over IPv4. Access from trusted sources and other permitted traffic depends on the configured rules.
Full Port Scan
- Method
- Full TCP port scan across all 65,535 ports against the public IP of an instance with the FreePBX firewall active.
- Result
- All 65,535 ports reported as filtered with no response. Scan completed in 131 seconds with zero open or closed ports identified.
- Finding
- The TCP scan identified no reachable ports from the test source with the firewall active. This result does not establish UDP exposure or access from sources permitted by different firewall rules.
IPv6 Security Parity
- Method
- Full repeat of port scanning, SSH access attempts, and SIP enumeration over IPv6, with firewall both active and disabled.
- Result
- With firewall active: all ports filtered, SIP not visible, SSH denied. DNS resolution verified for internal hostnames and external domains. End-to-end IPv6 connectivity confirmed with 0% packet loss.
- Finding
- The recorded IPv6 checks did not identify a bypass of the tested firewall rules. DNS resolution and IPv6 connectivity also worked in the tested configuration.
Console Proxy Isolation
- Method
- Attempted SSH access from a customer instance to the console proxy. The architecture is described below.
- Result
- SSH to the console proxy from a customer instance returned "Permission denied (publickey)". The customer instance holds no key authorised on the console proxy. That connection attempt did not gain access to the console proxy.
- Architecture
- my-console runs as a Node.js WebSocket-to-SSH service on a dedicated server at my-console.freepbxhosting.uk. The browser connects over HTTPS and a secure WebSocket. The server opens SSH to the PBX using its private key.The private key stays on the console server. The corresponding public key is authorised on the PBX.
- Authorisation
- my.freepbx.uk checks that the requested service belongs to the signed-in customer, is active, and has an assigned PBX IP. It takes the destination IP from the service record and signs it with the service ID, customer ID, and issue time using HMAC.
- Token Validation
- The console validates the signed target before serving the terminal page and before opening SSH. Changing the IP invalidates the signature. The launch token expires after five minutes; connecting to another target requires a valid token for that target.
- Cloud Firewall
- The managed DigitalOcean Cloud Firewall on my-console permits outbound SSH on TCP port 22 only to approved PBX IPv4 addresses. Inbound TCP ports 80 and 443 accept web connections. Outbound web traffic and DNS are also permitted.FreePBX UK manages these cloud rules. Customers manage the separate FreePBX firewall on their PBX.
- SSH Server Identity
- The SSH client does not verify the PBX's host key. The token authorises the destination IP and the cloud firewall restricts SSH destinations; neither verifies the identity of the responding server. Impersonation would require interception or redirection of the connection, or control of the server answering at an approved IP. No practical impersonation path has been established for this deployment.
- Finding
- The console validates the signed target before serving the terminal page and again before opening its SSH connection. The browser receives terminal input and output, not the private SSH key. Access to another target requires a token with a valid signature for that target.
Recorded Results
| Test | Method | FreePBX Firewall | Recorded Result |
|---|---|---|---|
| Network isolation | ICMP / TCP ping | N/A | Pass |
| SSH access IPv4 | Direct SSH attempt | Disabled | Pass |
| SSH access IPv6 | Direct SSH attempt | Disabled | Pass |
| Web credentials | Dictionary attack | Disabled | Pass |
| SIP exposure | SIPVicious svmap | Disabled | Exposed (expected) |
| SIP exposure | SIPVicious svmap | Enabled | Pass |
| Full port scan | nmap 65535 ports | Enabled | Pass |
| IPv6 parity | Full repeat over IPv6 | Both states | Pass |
| Console proxy | Architectural review and connection attempt | N/A | Pass |
Operating Your PBX
- FreePBX Firewall
- The FreePBX firewall is disabled by default. Enable it and configure trusted sources for access to your PBX.
- Administrator Setup
- Complete the initial administrator setup promptly. Restrict access to the setup page: if it is publicly accessible before an administrator exists, another visitor may be able to create the first account.
- SSH
- Leave password-based root SSH access disabled unless you need it. If enabled, restrict access to trusted IPs and disable it again afterwards.
- Console
- Keep my-console.freepbxhosting.uk in the internal zone and preserve its authorised SSH key. If access fails, use the recovery instructions in Part 1.