Safe WordPress Server Access Without Sharing Private Keys

A WordPress service provider should not ask a customer to submit both an SSH public key and private key through an intake form. A private key is the secret half of the credential and should not travel through an ordinary project brief.

The safer access pattern depends on the host, but every option should be limited, revocable, auditable, and separate from the website-building brief.

Preferred access patterns

For a VPS, a controlled pattern is:

1. the service creates a project-specific key pair in its protected environment;
2. only the public key is given to the customer;
3. the customer or host adds that public key to a dedicated, restricted server account;
4. the service keeps the private key in its secret store and never exposes it in project files, chat, logs, or previews;
5. access is tested without changing production;
6. the key is removed when the approved window ends.

Where possible, a hosting-platform team invitation, deployment token, or short-lived credential is better than unrestricted server access. WordPress administrator access and server access should also be separated; many content and configuration tasks do not require a shell account.

Least privilege is more than a slogan

The account should have only the permissions needed for the agreed deployment or maintenance task. Root login, shared personal accounts, permanent broad tokens, and credentials reused across customers create unnecessary exposure.

A production access record should identify:

• who approved access;
• which environment and account were used;
• the permitted actions and time window;
• the backup or restore point created before change;
• commands or deployment events that materially changed the site;
• the verification and rollback result;
• when access was revoked or rotated.

Why this is not part of the current public pilot

WPbyAI currently stops at C-verified source handoff. Assisted production deployment and Managed Care require additional access controls, backup and restore tests, incident boundaries, and support-cost evidence. Until those gates pass, the public form accepts a URL and project description—not production secrets.

If you need a build or existing-site change, request a fit review without including passwords, private keys, database exports, or customer data.