We manage more than 200 cPanel servers and currently use a bastion or jumpbox as the main access point. I'm looking for practical architecture ideas for auditing staff activity and controlling privileged, especially root, access at this scale. I've considered tools such as Vauban, FreeIPA, LDAP-based systems, PAM platforms, and similar solutions, but I'm not looking for a simple drop-in product recommendation. I'd especially appreciate real-world lessons about ephemeral credentials, session recording, centralized logging, MFA, and Zero Trust approaches. Because administrators still need to troubleshoot hosting accounts, inspect root-owned logs and paths, and repair services directly, fully replacing server access with deployment automation is not realistic for us.
4 Answers
We require all administrative access to go through a PAM layer. It started with SSH and RDP, but we’re also bringing web applications and administrative executables under the same access controls. The main benefit is having one place for approvals, MFA, RBAC, session auditing, and access reviews instead of managing separate controls for every tool.
At this size, the biggest improvement is usually eliminating standing root access rather than finding a perfect directory integration. Broker each privileged session, require MFA, issue a short-lived credential or checked-out key, and rotate or invalidate it afterward. Since cPanel and CloudLinux may not integrate cleanly with centralized identity systems, keep the audit trail outside the hosts: forward authentication, sudo, and relevant system logs to a collector administrators cannot modify, and record the brokered sessions separately. That gives you a reliable record of who accessed which server and what they did, even if an individual machine is compromised.
For implementation, I’d separate the design into a bastion or PAM gateway, a vault for short-lived credentials, centralized immutable logging, and regular access reviews. Start with a small group of servers and verify that emergency access and internal-only networking still work before expanding it.
A privileged access management platform can broker SSH and other protocols, require MFA or SSO, record sessions, and retrieve SSH keys from a protected vault. Some products can also rotate those keys automatically. Browser-based SSH is common, but you’ll want to confirm whether the platform supports native terminal clients and whether it can reach servers that are restricted to an internal network. A self-hosted connector or gateway may be needed if cloud infrastructure cannot tunnel into your private network.
The internal-network restriction is exactly what I’m concerned about, so support for a terminal client and a self-hosted connector would be important requirements.
Long term, try to reduce direct server interaction by putting repeatable changes and common fixes behind audited orchestration with RBAC. That won’t replace hands-on troubleshooting for hosting accounts or service failures, but it can reduce the number of situations where someone needs unrestricted root access and make routine work easier to review.
We still need direct access for troubleshooting, root logs, and service paths, so orchestration would complement the access model rather than replace it.
That sounds useful. I’m particularly interested in whether your PAM system is custom-built or assembled from existing components.