Protect hosting access with separate identities, strong secrets and an access audit

A hosting account often controls a website, databases, email and DNS from one place. Reusing its password in a mailbox or deployment tool turns a minor credential leak into a much larger incident. The useful starting point is an inventory of identities, what each identity can change and how its access can be revoked.

Map access by role and blast radius

• Domain registrar and authoritative DNS accounts can redirect web and email traffic.
• The customer portal and hosting panel can expose billing, files, databases and service controls.
• Mailbox and application accounts have separate sessions, recovery settings and permissions.
• SSH keys, API tokens and deployment credentials can outlive a password change.

Record the owner, purpose, scope, last review and revocation procedure for each identity. A shared administrator login hides who performed a change and makes staff departures harder to handle. Use individual accounts and delegated roles where the service supports them.

Separate automation from interactive administration. A deployment job usually needs a constrained path or action, not unrestricted portal credentials. Do not place a personal panel password into a repository, build log or command argument simply because it is convenient to automate.

Generate unique secrets and store them in a password manager

Use a reputable password manager to generate and store a distinct, sufficiently long password for every service. Prefer the manager's generator and autofill on a verified hostname. Password complexity rules alone do not compensate for reuse or for entering a password into a convincing phishing page.

Avoid examples that print a real password into a terminal transcript, shell history or CI output. When a tool supports a password prompt, protected credential file or scoped token, choose the documented mechanism appropriate to the job. Even an environment variable can leak through diagnostics or privileged process inspection; it is not automatically a secret vault.

Plan access for authorized colleagues through the manager's sharing controls rather than sending credentials in chat. Keep the manager's own recovery process and MFA protected independently from the hosting account it secures.

Inspect SSH identities without exposing private keys

ls -ld "$HOME/.ssh"
find "$HOME/.ssh" -maxdepth 1 -type f \
  -printf '%m %u %g %f\n'
ssh-keygen -lf "$HOME/.ssh/id_ed25519.pub"

The fingerprint identifies a public key without displaying private-key material. A missing default filename may simply mean you use a differently named key. Verify the actual key paths and authorized_keys entries rather than creating a second identity by accident.

Private keys should have tightly restricted local access. Review permissions, ownership, backup locations and agent forwarding according to your environment. Do not copy a private key into a website folder or attach it to a support ticket. Server-side authorized_keys can also contain restrictions; removing an entry should follow an access review with an independent recovery path.

Enable MFA and test the recovery route

Prefer phishing-resistant authentication where supported; otherwise use the strongest available MFA method. Enable it separately on the registrar, portal, panel, email provider and application accounts that offer it. A cPanel MFA setting is not a universal second factor for every protocol associated with the account.

curl --silent --show-error --location --max-redirs 5 \
  --output /dev/null \
  --write-out 'final=%{url_effective} status=%{http_code}\n' \
  https://panel.example.com/

This checks the network destination and redirects, not whether a page is safe to trust. Obtain the starting hostname from your existing provider records, not a renewal email. Store recovery codes securely and test a documented recovery procedure before relying on an account that has only one available factor.

Revoke access in every system it exists

When someone leaves or a device is lost, remove delegated access, API tokens, SSH keys and remembered sessions as well as changing affected passwords. Review forwarding rules and recovery contacts for mailbox accounts. A surviving application token can keep working after the interactive password changes.

For a suspected compromise, use a trusted device and prioritize accounts that can reset others, especially the registrar and primary recovery mailbox. Preserve relevant evidence and involve support through a known route. Avoid rotating a password on a device that may immediately capture the replacement.

Make access review a repeatable maintenance task

Set a review schedule and an event-driven review for staff changes, new integrations and incidents. Ask whether each identity is still needed, whether its scope is excessive and whether the named owner can perform recovery. Remove abandoned access instead of keeping it indefinitely for convenience.

Keep a record of the checks and the revocation results, without storing the secrets themselves. A practical access inventory reduces the time needed to investigate an incident and makes ordinary administration easier to delegate safely.

Primary documentation

• cPanel two-factor authentication
• Ubuntu OpenSSH server
• OpenSSH client configuration
• CISA phishing-resistant multifactor authentication