Prepare the approved key
Give only the SSH public key to its authorised installer. Test the intended account and host identity while retaining the old access route.
User keys authenticate an account, not the server; verify host identity separately. Confirm SSH entitlement, the named account and the approved public-key installation route with the operator. Do not infer root, shared-hosting shell or panel key controls from generic documentation.
Keep an existing authorised session or recovery route available during the change. If your organisation already manages keys centrally, follow that process rather than creating an unmanaged extra identity.
Generate and protect the user key pair
On a trusted computer, an authorised user can generate an Ed25519 key pair using ssh-keygen -t ed25519, choosing a recognisable filename and a passphrase. Ubuntu’s OpenSSH guide distinguishes the public .pub file from the private key without that suffix. Provide only the public key to the operator or approved account-control interface. Keep the private key on the authorised device or approved secure key store; do not attach it to a ticket or copy it into a website directory.
Record the intended account and public-key fingerprint with the access request. A key is not an account by itself: the operator must associate the public half with the correct account and set permissions so unauthorised users cannot modify its authorisation file.
Apply the public key through the agreed control
The managed operator or approved provisioning workflow places the public key in the account’s authorized_keys file, or an equivalent managed mechanism. Ubuntu documents ssh-copy-id for an account that already has authorised login, but it is not an instruction to bypass the operator’s process. Ask the operator to confirm the target account, server and effective key after installation. Avoid replacing all existing keys when adding one: other authorised users or deployment jobs may depend on them.
Prove the new login without losing the old one
From a new local terminal, connect to the agreed hostname as the exact account and choose the intended private key. Confirm both the expected server host key and the resulting account identity before touching application files. Test one harmless read within the authorised application scope. If the server requests a password unexpectedly or refuses the key, leave the old session open and give the operator the timestamp, account name and public-key fingerprint; they can check permissions and logs. Do not disable password authentication or remove an old key until the owner has tested every needed access path.
Illustrative result: the new key logs into the approved application account and can read its test path, while the existing session still works. Record the public-key fingerprint and revoke obsolete access only after handover.
A successful key login does not verify server identity unless the host key was checked through the approved trust route.
Frequently asked questions
May I share one private key with the whole agency? Use separately accountable identities or keys where the service supports them. Shared private keys make revocation and audit difficult.
Does an SSH key give me administrator rights? No. The account’s permissions determine what it can do.
Sources and technical references
Related guides
Was this guide helpful?
If you accepted optional analytics, your Yes/No answer and this guide’s page address are sent to Google Analytics. No written feedback is collected. Read our privacy statement or change your choice in .
Need help with your service?
Open your client area or contact Novasean. Describe the symptom and checks you have performed. Keep passwords, recovery codes and private keys out of your message.