Home / Blog / VPS and Infrastructure / SSH Keys and Secure Server Access
SSH (Secure Shell) is how you administer a Linux server remotely. Every login, every file transfer and every command runs through it. If SSH is protected only by a password, an attacker anywhere in the world can try to guess that password thousands of times a day — and automated bots do exactly that, within minutes of a new server going online.
SSH keys solve this. Instead of a password, you prove your identity with cryptography: a private key that never leaves your computer, and a public key stored on the server. The server challenges your computer, your computer answers using the private key, and the mathematics makes guessing infeasible. This guide explains how keys work, how to set them up correctly, and how to manage them safely.
A key pair has two parts:
~/.ssh/id_ed25519) stays on your computer. It is secret. Anyone who has it can log in as you. It should be protected with a passphrase and never shared, emailed or uploaded anywhere.~/.ssh/id_ed25519.pub) goes on the server, in the file ~/.ssh/authorized_keys. It is not secret — it is designed to be shared. It can only be used to verify that someone holds the matching private key; it cannot be used to log in by itself.When you connect, the server checks whether your public key is in authorized_keys. If it is, the server sends a challenge that only the holder of the private key can answer. Your SSH client answers it automatically. No password crosses the network, and there is nothing for a brute-force attack to guess.
On your own computer (not on the server), generate an Ed25519 key. Ed25519 is the modern standard: it is faster and more secure than RSA, and it is the recommended default in current OpenSSH versions. RSA with 4096 bits is the fallback if Ed25519 is not supported by an older system.
ssh-keygen -t ed25519 -C "[email protected]"
You will be asked where to save the key — accept the default (~/.ssh/id_ed25519) unless you have a reason to use a different name — and then asked for a passphrase. Set a passphrase. It encrypts the private key on your disk, so that even if someone steals the file, they cannot use it without the passphrase. Use a strong passphrase and store it in a password manager. (For automated scripts that must log in without a human present, a passphrase-less key is sometimes necessary — but that key should be restricted to a single purpose and a single command, and kept on a secured machine.)
The command creates two files:
ls -l ~/.ssh/
# -rw------- id_ed25519 (private key — 600 permissions, only you can read it)
# -rw-r--r-- id_ed25519.pub (public key — safe to share)
If the private key’s permissions are ever more open than 600, SSH will refuse to use it. Fix it with chmod 600 ~/.ssh/id_ed25519.
The simplest method is ssh-copy-id, which appends your public key to the server’s authorized_keys file and sets the permissions correctly:
ssh-copy-id -i ~/.ssh/id_ed25519.pub user@your-server-ip
You will be asked for your password one last time. After that, the key is installed.
If ssh-copy-id is not available, you can do it manually:
cat ~/.ssh/id_ed25519.pub | ssh user@your-server-ip \
"mkdir -p ~/.ssh && chmod 700 ~/.ssh && \
cat >> ~/.ssh/authorized_keys && chmod 600 ~/.ssh/authorized_keys"
The permissions matter: ~/.ssh must be 700 (only you can access it) and authorized_keys must be 600. If they are looser, the SSH server will ignore the key file and fall back to asking for a password — a common cause of “key not working” problems.
Test the key now, in a new terminal window, while your existing session is still open:
ssh -i ~/.ssh/id_ed25519 user@your-server-ip
If you set a passphrase, you will be asked for it — that is the key’s passphrase, not the server password. If you log in without a password prompt, key authentication is working.
If it does not work, check in order: the key file permissions on your computer, the ~/.ssh and authorized_keys permissions on the server, and whether the public key in authorized_keys is complete and on a single line. Running the client with ssh -v shows verbose output that usually identifies the problem.
Do not proceed to the next step until key login works. The next step removes password login, and if the key does not work, you will be locked out.
Once key login is confirmed, disable password authentication on the server. Edit /etc/ssh/sshd_config (with sudo) and set:
PasswordAuthentication no
ChallengeResponseAuthentication no
PubkeyAuthentication yes
PermitRootLogin no
Then validate the configuration and restart SSH:
sudo sshd -t
sudo systemctl restart ssh
sshd -t checks the configuration for syntax errors before you restart — a mistyped directive could otherwise prevent SSH from starting at all.
Warning: from this point on, losing your private key means losing access to the server. Keep a secure backup of the private key (for example, in a password manager or an encrypted drive), and make sure you know how to reach your hosting provider’s console access, which is the recovery path if all else fails. If your provider offers console access, test that you can reach it before you need it.
Key-only authentication removes the biggest risk. These additional steps reduce the rest:
AllowUsers deploy (or your username) to sshd_config so that only named accounts can connect, even with a valid key.sudo ufw allow from 203.0.113.10 to any port 22 proto tcp (replace the example address with your own).ssh-agent holds your decrypted key in memory so you enter the passphrase once per session instead of once per connection. Start it with eval "$(ssh-agent -s)" and add your key with ssh-add ~/.ssh/id_ed25519. Be cautious with agent forwarding (-A): it exposes your agent to the remote server, and should only be used with servers you fully trust.ssh-keygen -t ed25519-sk), which store the private key on a physical device such as a YubiKey. The key cannot be copied off the device at all.Keys are credentials, and they need lifecycle management:
authorized_keys — that is the entire revocation process.authorized_keys regularly. Know whose keys are on each server. An unknown key is a security incident until proven otherwise.~/.ssh/config for convenience. Instead of typing the full command each time, define a host entry:Host myserver
HostName 203.0.113.10
User deploy
IdentityFile ~/.ssh/id_ed25519
IdentitiesOnly yes
Then ssh myserver is all you need.
It happens — a lost key, a bad configuration change, a forgotten passphrase. The recovery path is your hosting provider’s console or rescue mode, which gives you direct access to the server without SSH. [TO BE CONFIRMED: Offshore Hosting’s console access method for VPS plans and whether it is available on all plans.] From the console you can restore sshd_config, add a new public key, or reset access. Knowing how to reach the console before an emergency is part of the setup, not an afterthought.
Containers package an application with everything it needs, so it runs the same way on any server. This guide explains what Docker containers are, when they help on a VPS, and the basics of running them well.
GPU hosting rents you a server whose graphics processor does the heavy lifting — for AI models, rendering and other parallel work. This guide explains who actually needs it, who does not, and what to check before buying.
A dedicated server gives you the whole machine — and the whole responsibility for it. Know exactly which jobs are yours before you sign, or pay for a managed plan.