Set up SSH keys without losing access

Generate and identify the key locally

On a current OpenSSH client, create a dedicated key with ssh-keygen -t ed25519 -a 100 -f ~/.ssh/vpseverywhere_admin. Enter a strong passphrase when prompted. The command creates a private file named vpseverywhere_admin and a public file named vpseverywhere_admin.pub. If Ed25519 is unavailable because of a specific compatibility or policy constraint, choose an approved RSA configuration for that environment rather than copying an old key.

Display the public-key fingerprint with ssh-keygen -lf ~/.ssh/vpseverywhere_admin.pub. Save the fingerprint in a trusted record. Do not print or transmit the private file, and do not paste it into a dashboard field labelled SSH key—the field should accept the one-line public key beginning with ssh-ed25519.

• Use a separate key for administration rather than a shared team key.
• Protect the local device with disk encryption and updates.
• Back up the private key only in an encrypted, access-controlled store.

Install the public key

When password access is temporarily available, install the public key with ssh-copy-id -i ~/.ssh/vpseverywhere_admin.pub USER@SERVER_IP, replacing both placeholders. Alternatively, add the exact public-key line through the provider's provisioning control. If you edit manually on the VPS, the target user's ~/.ssh directory should be owned by that user and normally mode 700; authorized_keys should normally be mode 600.

Connect explicitly with ssh -i ~/.ssh/vpseverywhere_admin USER@SERVER_IP. On the first connection, verify the server host-key fingerprint through an independent trusted source before accepting it. A changed host key can be legitimate after reinstalling, but it can also indicate interception or that the address now belongs to another server.

• Never resolve a host-key warning by blindly deleting the old record.
• Use a named non-root administrator where possible.
• Keep each person's key on its own line for clean revocation.

Make daily use reliable

Create a local SSH client alias in ~/.ssh/config with a Host name, HostName address, User account, and IdentityFile ~/.ssh/vpseverywhere_admin. Set the config file to be readable only by your account where the operating system requires it. An SSH agent can reduce repeated passphrase entry, but unlock keys only on trusted devices and avoid forwarding the agent to untrusted hosts.

For teams, provision individual public keys through configuration management and remove them promptly when access ends. Do not circulate one private key through chat or ticket systems. Hardware-backed keys can strengthen high-value administration when client and server support the chosen type.

• Name keys by role and environment without embedding a secret.
• Review authorized keys after personnel or automation changes.
• Use short, controlled agent lifetimes on shared workstations.

Disable weaker paths only after testing

Keep the current session open, start a second terminal, and confirm the new key can log in and run the intended administrative command. Then validate any SSH server change with sudo sshd -t before sudo systemctl reload ssh. Password authentication and direct root login can be disabled when no required user or automation depends on them.

Maintain a recovery method through the provider console and document how to restore access. Removing a lost key is urgent; losing the only working key without console access is an outage.