SSH keys for a Linux VPS: create, install and test access

Confirm the real account, host and recovery method

Use this checklist for a Linux VPS you own or are authorised to administer. Begin with the host, account name and SSH port actually assigned to your service. Do not guess a username from a distribution name. Confirm how you would recover access if an authentication change fails, using a method your operator has really made available.

Keep an existing authenticated session open while testing a new login method. If you have no working access yet, resolve the initial connection details first. A public hosting plan or a paid order is not itself a working shell account; wait for the actual service details before applying server instructions.

Review Linux VPS software and resources

Create the key on the device used to connect

Run ssh-keygen on your own client device, not inside the remote VPS. For an OpenSSH client that supports it, ssh-keygen -t ed25519 creates an Ed25519 key pair and prompts for a file location and passphrase. Choose a new filename if an existing key is already present; do not overwrite a key that another server still uses.

Protect the private key with a passphrase and secure device storage. Use the interactive prompt rather than putting a passphrase into a command that may be saved in shell history. Keep track of the key purpose and the public-key fingerprint so you can later identify the right entry when reviewing or revoking access.

Install the public half for the intended server account

The public key normally has the same filename with .pub appended. Add that public key to the authorised-key location for the account you will use on the VPS. Many OpenSSH installations use ~/.ssh/authorized_keys for the remote account, but the effective server configuration can specify a different location. Verify the location instead of assuming every system uses the same policy.

Where available, ssh-copy-id can install a public key through an existing authorised connection. A manual installation must preserve existing keys and keep each public key on one line. Do not replace the whole file with a single new entry unless you have deliberately reviewed every access holder. The private key stays on your own device.

Scroll the table horizontally if needed.

Verify the host and test a fresh connection

Compare the server host-key fingerprint with a trusted value obtained through your operator or another verified channel before accepting a new host identity. If a previously known fingerprint unexpectedly changes, investigate the change. Deleting the client known-hosts entry and accepting whatever appears does not establish that you reached the correct server.

Open a second terminal and connect with your actual account, host and chosen private-key path. The OpenSSH -i option selects an identity file, and -p selects a non-default port when one was assigned. Confirm the expected account after login. A private-key passphrase prompt unlocks your local key; it is different from a remote account password prompt.

Diagnose rejection before changing the login policy

If the key is rejected, check that you used the right account and that its public key matches the private identity selected by the client. Review the authorised-key file location, ownership and permissions. On a typical OpenSSH account, restrictive permissions such as 700 on .ssh and 600 on authorized_keys prevent other users from modifying authentication files; the correct account must own them.

Inspect client diagnostics and the server authentication logs available to you. Server policy can restrict users, key types or authentication combinations. Do not broaden permissions to make a rejected key work. Share a redacted error message when seeking help, rather than a private key, passphrase or complete sensitive diagnostic log.

Change authentication settings only after access is proven

A working key does not automatically change the server password policy. If you intend to change authentication settings, inspect the main OpenSSH configuration and any included files that affect the account. PasswordAuthentication and keyboard-interactive authentication are separate settings, and an operator policy or Match block can change the effective result.

Back up the relevant configuration and validate it with the installed daemon before applying changes; sudo sshd -t is the OpenSSH syntax check on systems where that command and privilege apply. Use the service-management method documented for your distribution. Keep the original session open and prove another fresh key connection after the change before closing it.

Continue with the Linux VPS security checklist

Rotate access and keep recovery independent of one laptop

Give each administrator their own key so an access change does not require sharing a private file. When replacing a device, install and test the new public key first, then remove the old public-key entry after identifying it. A lost passphrase is not recoverable from the encrypted private key; create a replacement through a working authorised access method.

Review keys when a team member leaves or a device is lost. Removing a public-key entry prevents future key logins through that entry, but also review active sessions and other access methods. Keep an approved recovery procedure with your service records so access does not depend entirely on the device you are replacing.

• The private key has never been uploaded or sent to support.
• A second connection works with the intended account and identity.
• The host fingerprint has been checked through a trusted channel.
• Recovery and key revocation are documented before policy changes.

Plan independent backups and recovery · Validate an Nginx website after establishing access