Creating an SSH key pair
Quick answer
Run ssh-keygen -t ed25519 to generate a key pair, then copy the public key to the server's ~/.ssh/authorized_keys file. Use ssh-keygen -t rsa -b 4096 instead if the system doesn't support ed25519.
An SSH key pair consists of a private key, which stays on your own machine and is never shared, and a public key, which you place on the server. Logging in with a key pair is both more convenient and more secure than a password: there's nothing to brute-force, and combined with a passphrase on the private key, it works like a form of two-factor authentication.
Generate a key pair
Run ssh-keygen
On Linux, macOS, or Windows with the built-in OpenSSH client (or WSL), open a terminal on your own machine and run:
ssh-keygen -t ed25519Ed25519 is the current recommended key type: it's fast, and the keys are short and secure at a fixed size, so there's no bit-length to choose. If you're connecting to an older system that doesn't support ed25519, generate an RSA key with a 4096-bit length instead:
ssh-keygen -t rsa -b 4096Accept the default file location, and set a passphrase when prompted. The passphrase protects the private key itself; you'll still need it each time you use the key, unless your system caches it in an agent.
Add the public key to your server
Copy the key with ssh-copy-id
If ssh-copy-id is available on your machine, this is the simplest way to install your public key on the server:
ssh-copy-id user@your-server-ipOr add it manually
If ssh-copy-id isn't available, create the .ssh directory and authorized_keys file on the server yourself, then paste in the contents of your public key file (the .pub file, never the private key):
mkdir -p ~/.ssh
chmod 700 ~/.ssh
touch ~/.ssh/authorized_keys
chmod 600 ~/.ssh/authorized_keys
nano ~/.ssh/authorized_keysFor Flexible VPS, you can also add a public key under Flexible VPS → Settings in Portal, manually or imported from GitHub or GitLab, so it's already on the server when it's created.
Harden SSH once your key works
Disable password authentication and root login
Edit /etc/ssh/sshd_config and set:
PasswordAuthentication no
PermitRootLogin noThen restart the SSH service:
sudo systemctl restart sshdTest before you disconnect
Open a new terminal window and log in with the key before closing your existing session:
ssh user@your-server-ipOnly close the original session once the new one connects successfully. If something's wrong, the existing session lets you fix it without being locked out.
Use one key pair per person rather than sharing a single key across your team, so access can be revoked for one person without affecting everyone else. See also How to improve your SSH security and How to change the SSH port for further hardening steps.