How to set up SSH keys for your hosting
Generate a key pair, add the public half to your hosting account, and connect over SSH without a password from then on.
SSH keys let you connect to your hosting account without typing a password every time, and they are also more secure than a password on its own — a key pair cannot be guessed or brute-forced the way a password can. Deployment tools such as Git and rsync, and Composer running over SSH, all rely on the same key-based connection, so setting this up once tends to unlock several other things at the same time.
How the pair works
A key pair is two mathematically related files: a private key, which never leaves your own computer, and a public key, which you can share freely — its whole purpose is to be given to servers you want to connect to. The server checks that whoever is connecting holds the matching private key, and if the match is correct, lets the connection through without asking for a password at all.
Step 1: generate the key pair
On macOS, Linux, or Windows using a recent OpenSSH client, run:
ssh-keygen -t ed25519 -C "your-email@example.com"
ed25519 is a modern key type that is both smaller and faster to compute than the older RSA default, and is the recommended choice unless something specific you connect to has not caught up and still requires RSA. The -C comment is just a label to help you tell keys apart later; it has no effect on how the key works.
Accept the default file location unless you already have a reason to choose another, and set a passphrase when prompted. The passphrase encrypts the private key file itself, so if that file is ever copied by someone else, it is still useless to them without also knowing the passphrase.
This creates two files, typically:
~/.ssh/id_ed25519 (private — never shared)
~/.ssh/id_ed25519.pub (public — this is the one you copy elsewhere)
Step 2: add the public key to your hosting account
Display the public key's contents:
cat ~/.ssh/id_ed25519.pub
Copy the entire output — it is one long line starting with ssh-ed25519 — and paste it into the SSH keys area of your control panel. Do not edit or wrap the line; a key pasted with a line break in the middle of it will not match and the connection will be refused.
The private key file has no extension, or no .pub, and must never be pasted anywhere, emailed, or committed to a repository. If a private key is ever exposed this way, generate a new pair and remove the old public key from every account it was added to — treat exposure of a private key the same way you would treat a leaked password.
Step 3: connect
ssh youraccount@yourserver.example.com
If you generated the key in a non-default location, or you are managing several keys for different accounts, point the connection at the specific one explicitly:
ssh -i ~/.ssh/id_ed25519_hosting youraccount@yourserver.example.com
A successful connection using a key skips the password prompt entirely, other than asking for your key's passphrase if you set one — which your system's SSH agent will typically remember for the rest of your session so you are not retyping it constantly.
Using the same key with Git, rsync and Composer
Once a key is set up and working for a plain SSH connection, the same key is what Git uses for a Git-based remote over SSH, what rsync uses when copying files with -e ssh, and what lets Composer run smoothly if a private package repository also requires SSH authentication. See deploying from Git and deploying with rsync for how each builds on exactly this setup.
If the connection still asks for a password
- Check the public key was pasted correctly — no missing characters, no accidental line break, and confirm it saved in the control panel.
- Check file permissions on your own machine. SSH refuses to use a private key file that is readable by other users on the system; run
chmod 600 ~/.ssh/id_ed25519to correct this. - Confirm you are connecting to the right account and hostname — a key added to one hosting account will not authenticate a connection to a different one.
Once key-based access is working reliably, it is worth disabling password authentication for SSH entirely wherever your platform allows it, removing an entire category of brute-force attempt against the account. On shared hosting that setting is usually controlled by your host rather than something you toggle yourself, but the key pair itself is entirely yours to manage, reuse across every tool that supports it, and revoke by simply removing the public key from your account if it is ever no longer needed.
Related reading
The rsync flags that matter, a dry run before the real one, and how to stop it overwriting files it should have left alone.
How to deploy your website from GitAdding SSH keys, connecting a remote and choosing pull-based or push-to-deploy — what a Git deployment setup needs on hosting.
How to use Composer on shared hostingComposer runs fine on shared hosting over SSH — here is how to install it, run it, and keep dependencies out of the public folder.
How to call an external API from PHPcURL, an authentication header and a decoded JSON response — the three parts of calling any external API from a PHP script.