Public key and private key
An SSH key has two parts. The public key can be added to the server to grant access. The private key must remain secret and should never be sent in chat, email, or support tickets.
Important: a serious agent or developer does not need server passwords or private SSH keys. Access should be granted by authorizing a public key on the server.
Recommended process
- Clarify which server and project the agent will work on.
- Create or use a dedicated server user with only the needed permissions.
- Add the public key to the server.
- Test that login works before larger work starts.
- Remove the key when the project is finished or access is no longer needed.
Good access hygiene
- Grant access only to the environment the agent needs.
- Use separate keys for different people or projects.
- Avoid shared passwords.
- Document who has access and when it was granted.
What can the agent do after access is granted?
With approved SSH access, the agent can inspect the project, install dependencies, read safe logs, configure services, build the application, and verify that it runs. Production changes should still be approved before they run.
Useful prompts
- "Verify that SSH access works and tell me which user and directory you landed in."
- "Check what permissions this server user has, but do not change permissions yet."
- "Confirm whether you can reach the project directory and Git repository."
- "List the setup checks you can perform safely before installing anything."
- "When the work is done, remind me which public key or server user should be removed if access is temporary."