Secure SSH access

No passwordless SSH needed for normal operation

cPFence v4+ does not require passwordless SSH for normal cluster communication or the WebUI. Only remote WordPress backups and MultiRun need passwordless SSH setup.

Use this guide to secure root SSH for administration. On Enhance, normal secondary-server communication uses TCP 9096 and browser access uses TCP 9095.

Make changes locally on each intended server with root or sudo access. You need a working authorized key and a provider console or another recovery route. Preserve the current SSH port and existing administrator configuration.

Keep a working way back in

Before reloading SSH, confirm key login from every trusted source you need, including the main control panel server if it uses SSH tools. Check its public IPv4 and IPv6 addresses. Keep your current session open and test a second session after reloading; incorrect addresses or conflicting rules can lock you out.

1. Choose your SSH policy

Open an administrator-owned drop-in, for example:

sudo nano /etc/ssh/sshd_config.d/01-cpfence-hardening.conf

Keep a private copy if the file already exists. Choose one option below and preserve unrelated settings.

Option 1: Restrict root SSH to trusted IPs

PubkeyAuthentication yes
PermitRootLogin no

Match User root Address 192.0.2.10,2001:db8::10
    PermitRootLogin prohibit-password
Match all

Use the actual SSH source addresses

Replace both example addresses with trusted public IPv4/IPv6 sources, including your administrator connection. Include the main control panel server’s addresses when it initiates SSH operations. These are SSH permissions; browser approved IPs are managed separately.

Option 2: Allow root key login without an IP restriction

PermitRootLogin prohibit-password
PubkeyAuthentication yes

This permits root key login from any address allowed by the firewall and other SSH rules. Root password and keyboard-interactive authentication are disabled by prohibit-password. Other SSH authentication requirements still apply. Ubuntu SSH configuration reference

2. Validate before reloading

sudo sshd -t

Continue only if it exits successfully without errors. Check the effective settings for an allowed source:

sudo sshd -T -C user=root,addr=192.0.2.10 | grep -E 'permitrootlogin|pubkeyauthentication'

Expect pubkeyauthentication yes and permitrootlogin prohibit-password or without-password. For Option 1, repeat with a source outside your trusted list:

sudo sshd -T -C user=root,addr=192.0.2.30 | grep -i permitrootlogin

Expect permitrootlogin no. Repeat the allowed check with your IPv6 source when used. If your existing rules match a hostname, local address, or local port, supply the corresponding host, laddr, or lport connection fields too. OpenSSH test options

Check the effective configuration

Included files are read in name order, and earlier values or matching rules can affect the result. A 01- filename alone does not guarantee precedence. without-password is an older alias of prohibit-password; either output is normal.

3. Reload and test a new connection

After the syntax and effective-rule checks pass:

sudo systemctl reload ssh

Open a second SSH connection using your existing port and key. Confirm the intended trusted source works before closing the original session. With Option 1, sources outside the list must remain denied root login.

Repeated root-login alerts

Several SSH connections can produce several successful root-session records. On the server named in the alert:

1. Check the source IP’s current policy. For verified administrator or cluster addresses, use the IPDB whitelist controls. A whitelist bypasses IPDB blocking and suppresses newly detected root-login alerts from that address; approve only trusted sources.

2. Review SSH clients and administration tools that open parallel connections.

3. Inspect recent SSH logins with this read-only check:

   sudo journalctl --unit=ssh --since='15 minutes ago' --lines=100 --no-pager

4. Compare the dates, PIDs, usernames, and IPs with the notification. cPFence can group several logins in one notification. If the same record continues to arrive, share the relevant details privately with support.

If an approved IP still appears

Browser approved IPs and the IPDB whitelist are separate. An IPDB whitelist prevents new matching alerts; notifications already queued can still arrive. Check the actual list and login records before changing policy again.

Keep scheduled work intact

Do not remove all queued system jobs to clear root-login alerts. They can include unrelated administrator work. Use the supported whitelist controls and contact support if delivery remains unclear.

Rollback and troubleshooting

• Unexpected effective rule: review /etc/ssh/sshd_config and its included files before reloading.
• Key login fails: check authorized keys, their permissions, other authentication requirements, and provider/local firewall rules.
• Undo this change: restore your saved drop-in. If you created a new file, remove only that file. Run sudo sshd -t, then reload SSH after it succeeds. Use the provider console if remote access is lost.
• Browser or secondary-server access fails: follow browser access or secondary-server connection; changing SSH rules does not repair those listeners.