- Use a trusted local SSH client.
- Give every device its own key.
- Keep a recovery route independent of the VPS.
Generate a dedicated key
Create an Ed25519 key with a device label and a strong passphrase. If the destination file already exists, stop and choose another filename instead of overwriting a working key.
ssh-keygen -t ed25519 -C "astra-workstation"Recognise the two halves
The .pub file is the public key. Its contents begin with a key type such as ssh-ed25519, followed by the public value and an optional comment. Add this value during configuration. The file without .pub is private.
Support never needs a private SSH key. Do not attach it to a ticket, store it in a source repository, include it in a migration note or share a screenshot of it. Replace an exposed key and remove its public half from every affected host.
Verify the machine
Compare the host-key fingerprint displayed by SSH with the one in the server overview before accepting it. A reinstall can legitimately create a new host key. A changed fingerprint without a corresponding action should be investigated, not bypassed.
ssh -o StrictHostKeyChecking=ask [email protected]Test new access before closing the old path
Create a named administrative account, install its public key and test a new connection before closing the first session. For a team, keep each operator’s key separate. Remove access individually when someone leaves.
Do not disable a working access method until its replacement has been verified. Keep the client-area console available while changing SSH or firewall settings.
Rotate with a short inventory
Add the replacement public key, open a fresh session with it and verify the expected permissions. Only then remove the old key. Record the device label, public fingerprint and systems it can access. Keep private material outside that inventory.