Quick answer
Keep the private key in your local SSH directory or a trusted credential agent, outside public_html and outside the Git repository. The public key can be authorized on the server. The private key and its passphrase should never be pasted into a chatbot or committed with website code.
Before you start
Identify which computer runs the actual SSH client. A local agent uses that computer's identity; a remote execution environment would need its own deliberately provisioned access. Do not copy your main personal key to every tool or server.
What to do
- Use a dedicated key for the device or workflow where practical, with an identifiable public-key comment and a passphrase.
- Restrict the private file so other local users cannot read it. On Windows, use appropriate file ACLs; on Unix-like systems, owner-only access is the normal starting point.
- Use a supported SSH agent or credential manager when you want to avoid repeatedly entering the passphrase. Confirm which keys it is offering.
- Exclude the private key, .env files, credentials, and backup archives from version control and from files uploaded for AI review.
Check the result
Check the repository's tracked files and the local key permissions. Confirm that only the .pub key was imported into cPanel and that login uses the intended identity.
If something does not work
If a private key was exposed, stop using it, remove its authorized public key, and replace the identity. Deleting the chat or Git file alone does not revoke an already copied key.
Related help
- Import and authorize a public SSH key in cPanel
- Revoke an AI tool or contractor's SSH access
- Share website errors with an AI assistant without exposing secrets
Official references
Reviewed October 31, 2026. Interfaces, vendor availability, and account features can change. Check your current account before making changes.
