SSH Keys Explained: Safer Access to Your VPS

Laptop connected through an Ethernet adapter on a desk, with network equipment in the background. Beginner Guides

Your VPS provider asks for an SSH public key. Which file should you upload, where does the other file belong, and will you still need a password? Understanding that distinction is the first step toward managing remote server access confidently.

SSH provides an encrypted connection to a server. It supports several login methods, including passwords and cryptographic keys. Both use an encrypted connection; the difference is how you prove that you are allowed to log in.

One Key Pair, Two Different Jobs

An SSH key pair contains a public key and a private key. The server uses the public key to verify a signature created with your private key. The private key itself is not sent to the server.

  • Public key: install it on the server for the account you want to access. Its filename normally ends in .pub.
  • Private key: keep it on your own computer. Do not paste it into a hosting dashboard, support ticket or shared document.

A key identifies an allowed credential, not a permission level. Logging in with a key does not automatically make an ordinary user an administrator.

Create a Key on Your Own Computer

The following example assumes a Linux or macOS terminal with OpenSSH installed and a Linux VPS. Ubuntu recommends Ed25519 for ordinary SSH key generation.

ssh-keygen -t ed25519

Run this locally, not inside your VPS session. The tool asks where to save the key and whether to protect it with a passphrase. If it warns that a file already exists, do not overwrite a key you still use; choose another filename.

With the default filename, the pair is ~/.ssh/id_ed25519 and ~/.ssh/id_ed25519.pub. A passphrase protects the private key file at rest. It is separate from the remote account password, and losing it can make that key unusable.

Install Only the Public Key

When creating a VPS, your provider may offer a field for an SSH public key. For an existing server, you can use ssh-copy-id if it is installed locally and you already have a working login method:

ssh-copy-id -i ~/.ssh/id_ed25519.pub username@server-address

Replace username and server-address with the account and address supplied for your server. If you chose a different key filename, update the path too. This command normally appends the public key to that remote user’s ~/.ssh/authorized_keys.

On the first connection, verify the server’s host-key fingerprint through a trusted provider console or administrator. Your user key proves your identity; the host key helps establish that you are connecting to the intended server.

Test Without Falling Back to a Password

Keep your existing server session open. In a second local terminal, test a fresh connection with password fallback disabled for this attempt:

ssh -i ~/.ssh/id_ed25519 \
  -o IdentitiesOnly=yes \
  -o PreferredAuthentications=publickey \
  -o ControlPath=none \
  username@server-address

A request for your key’s passphrase is normal. If the server requires an additional authentication factor, this key-only test may not complete; follow that server’s access policy.

Adding a Key Does Not Disable Passwords

Installing a public key adds a login method. It does not automatically remove existing password-based access. Treat changes to the server’s authentication policy as a separate task using your operating system’s documentation.

Keys also need maintenance. Give each administrator their own credential, remove access when it is no longer needed, and replace any private key suspected of exposure. A working recovery route matters just as much as a successful first login.